Since we're talking about a training project here, I absolutely insist that you use UDT's for this problem. Learning how to operate with UDT's is just as essential for your core skills as learning how to operate with arrays.
Quote: "- Look at all the typing required for the UDT! And this isn't even a game yet, it's just me messing around. "
The extra code is only required once, when you load the array. 8 lines isn't a lot of code. My Tic Tac Toe game is 706 lines of code, and Starstrike (which you saw a while ago) is 14772 lines of code. You shouldn't fret over over a few lines of code any more than you should fret over 100% memory efficiency, especially when most of those extra lines are a cut and paste job, adjusting a property each time. Easy.
Quote: "- If the CSV file differs from this hardcoded UDT, things break. "
If you change the format of the CSV, any code you have written to read it will break, regardless of the technique you're using.
Quote: "- Toggling an incorrect 2D array dimension to the correct value is easy. But cutting and pasting UDT data then checking for typo's was very time consuming. "
Toggling an incorrect UDT is an identically simple matter. If you're using UDT's, the compiler will check for typo's for you by throwing an error if you use a property that hasn't been defined. If you use constants you won't get an error, so your point seems to argue the case for UDT's. Also I'm not sure why you're checking for typo's if the code was cut&paste, since you didn't type anything...
Quote: "- With the 2D Array only being able to hold string data, this meant that all calculations had to be processed using VAL(data). But with a UDT, I had to remember which items were strings, and which were integers. Then if the spreadsheet changes, again breakage! "
You already have to remember which are strings and which are ints. You seem to know when VAL() is required - that means you know it's an int. In practice you will not forget which properties are strings and integers and even if you do, the program will throw a type mismatch error when you use the wrong data type, even giving you the line in which the error transpired.
Moreover, given the memory-management freak that you are, you absolutely must not use strings at all unless there is no alternative - always use integers where possible, and floats where it's not and you're dealing only in numbers. Strings use far, far more memory than integers or floats. Relative to the amount of system memory available to your average computer we're talking about negligibly small amounts of memory here, but so we are when you "size up" your arrays, which is a total waste of time (there is no situation in which it's a good idea to do this). If you're insisting on doing so anyway, that position requires you to avoid using strings in every possible case (which is an equally ridiculous thing upon which to insist).
Back to the matter at hand: If you change the format of the spreadsheet, all code will break, whether you've used constants or UDT's (or any other possible technique, for that matter). This is why proper planning is required before you commence coding, and a perfect example of why "game design" is an entire field of expertise, entirely separate from the field of "game development".
Quote: "- When loading a lot of game data into my game engine via CSV Google Docs, anyone can log on, add their own stuff to the spreadsheet, then upon the next compile it's instantly in the game. Another, is that anyone can use spreadsheets but not everyone can code, and not to forget that Google Docs is collaborative. The other day, I had 3 friends all logged into the same spreadsheet, adding weird and wonderful game ideas which I could then directly feed into the game with out any further programming required!"
I'm struggling to find an argument for or against UDT's in this point. The type of read code you're using doesn't seem to affect whether or not people can collaborate on your spreadsheet. In all cases, your co-conspiritors will have to abide by the correct format in the spreadsheet, regardless of whether you're using constants or UDT's to read the data into your program.
Quote: "- Not everyone speaks English. Translating a CSV document to a different language would be easier than trawling through code. "
Ditto. Why would the language spoken by your users make any difference towards your decision between constants and UDT's? In commercial game development studios, entire departments are dedicated to a process called 'localisation' (I'm sure you've heard the term). Just in case you aren't familiar, their job is to translate all the strings used in the game to the local language (hence the naming of their job). This process takes place no matter what read code is used to access the data in question.
Even if it did make a difference, I strongly dispute your suggestion that localisation in a simpler matter than "trawling through lines of code" when you know exactly where the code in question lies in your program. Localisation for a commercial game takes months; adding a new property to a UDT takes somewhere in the general vicinity of four to five seconds, give or take a few milliseconds.
Quote: "Agent remind`s me with every discussion that I'm yet to even program tic-tac-toe."
It doesn't matter what game you make. The point is, making something practical will teach you far more than experimenting with purposeless practice projects. It's good to learn a few bare bones basics with practice projects, but by the time you've learned what an array even is (let alone advanced manipulation) you are ready to make your first game. It'll be far more productive to actually make something useful because you'll discover what skills you lack as you run into problems along the way, which will direct your learning along the most practical path. You are far beyond the stage where you should've started an actual project; I'd have a disciple commence work on their first actual game within a few days of learning basics.
