I used to sneer at such tools, considering them "not real gamedev". That was until, on one local edition of Global Game Jam, a designer in our team did in Construct in 15 minutes what took three of us coders a couple hours. This drove home the point that we were really overcomplicating things by coding a simple game from scratch (in XNA, back then).
--
[0] - https://www.scirra.com/construct2 is the one I played with, but they also seem to have a web version now, for better or worse, which is available at https://www.scirra.com/
For presentation, I toss the data on Excel. Bold the headers. Change the number type (pct, $, etc) to the correct one.
I would say that it has made my life a lot easier. There is one repository where the data is held. If I mess up, I go back to the master tables. In Excel, I would usually start over. Joins are easy. Excel can do some things better. When it can, then I use it. It's not a one or the other. It's ok to use both.
Impute (finance):
assign (a value) to something by inference from the value of the products or processes to which it contributes.
Or don't, since SCMs are much better at diffing plain text than either.
> Also Excel could have formulas which might be useful somewhere and supporting formulas in config file is another level of complexity and almost certainly it'll be worse than Excel.
You'll have an easier time reimplementing Excel's formula system than basic arithmetic? I find that hard to believe.
I'm not sure you understood what the parent was saying? This seems like a non sequitur.
In a spreadsheet, derived values can be updated instantly. Say you want to upgrade a bandit from leather armor to chainmail (6 or so equipment items changed), and then verify that his total defense and modified movement speed are still within reasonable ranges for the part of the game where he appears. With a text file, you've got some arithmetic to do. With a spreadsheet, it's there at a glance.
Or say your enemies are missing too much, and you want to give them +10% accuracy across the board, for all of 50+ enemies. In a text file, that's a lot of cursoring around. In a database, you could knock together a query to do it, but that still might take a couple of minutes, depending. In a spreadsheet, I could do it in 15 seconds. (And if I screw it up, a couple of Ctrl-Zs puts everything back where it started. That's not so easy in a database.)
And, y'know, a lot of programmers really underestimate the value of good formatting. A database can spit out nice columnar tables easily, but a spreadsheet can do things like put borders between stat clusters related to different categories; automatically color-code data so you can see at a glance what the highest and lowest values in a given column are, or spot out-of-range derived values; add alternate-row shading to make it easier to scan across a long row; and on and on. That is useful. It lets you find and correlate the data you want faster with fewer errors. Not everything has to be viewed in flat text.
[1] https://www.airpair.com/neo4j/posts/modelling-game-economy-w...
Both approaches have tradeoffs:
- TSV files can have so many columns that you can't really edit them in a text editor, you'll never find your place. Some of these in D2 have more than 256 columns.
- INI files don't give you a full list of configurable parameters, so you might not even know what flags the engine supports if they're mentioned only once in the entire file or not mentioned at all. Some object types in Red Alert 2 support over 700 flags, not all of them are actually used in the default config…
- two items described in a TSV file are easier to compare than two INI sections, with INI you need a second editor window and some ordering of the keys to make sense of things.
- on the other hand, diffing a TSV file for changes is a lot more challenging.
At the time, I remember thinking how a proper database would make this easier.
---
I have also seen a game where a \n was used as a record separator and \r was used to insert newlines into the text string within a record. Fun times when your text editor tries to "intelligently" handle and normalize line endings.
And non developer can easily write own formula to next cell whenever he feels like and don't need to wait for programmer, don't need to explain and don't need to fight if programmer happen to be stubborn.
Even seeing what depends on what is easier with right excel plugin then debugging scripting code.
Pardon my ignorance, but why aren't they using some sort of database for the data? Or at least storing the data in some sort of master database and exporting it to text files for the game to read? It would be lovely to hear the techniques and reasons from anyone in the know.
(IIRC it's for convenience in development. I doubt the game ships with an embedded Excel file.)
Any visual DB client?
> Where are the easy adhoc reports?
Isn't that just queries? Then throw it into a view to "save".
> Where are the forms?
No idea what you're looking for here, but this sounds a lot like your first question.
Forms are data entry views that save to the backing tables. Nowadays the most well-known forms are probably https://docs.google.com/forms/
If I were to learn it without any prior experience, I would just look through every template they have. See which industries I'm most familiar with. And look at how those databases are organized.
https://airtable.com/templates
They have a really good 12 minute overview though, hitting every major concept though. https://vimeo.com/165624533
I would also learn a little bit about relational database design. This 5 minute video is a good starting point https://www.youtube.com/watch?v=NvrpuBAMddw
I like using databaseanswers.org as a reference resource. This is a very nice 5 minute introduction to designing a database. http://www.databaseanswers.org/data_models/5_minute_tutorial...
Basically, if you come from an excel background, it would help if you knew a little bit about database design, and relational databases. Its not necessary, but Airtable is practically excel + microsoft-access.
Start with a template, and play around with it. I would get familiar with this page in particular though. Formula and lookups are something you'll use often in any airtable base. https://support.airtable.com/hc/en-us/articles/202576519-Gui.... This was perhaps the least obvious concept for me to pickup naturally.
If you need any help though feel free to reach out to me I have contact information on my username
That's where the "Power" suite enters the picture (Power Query, Power Pivot, etc.). Great way for non-technical people to get database data into Excel for reporting/analysis. I've trained plenty of people with only basic Excel skills to use it. The best part (for them) is that it's like a macro, so you can rerun it with new data any time.
You can even use those to pull an existing SSRS report directly into Excel.
"As a developer, you've probably, at some unfortunate point in your life (possibly several points, actually), been handed an Excel file that has been crammed full of 'data' by someone in marketing and told to 'do something with it.' " http://wyorock.com/excelasadatabase.htm
As for job titles; Software Engineer (or Developer) of Analytics, Data Analyst, Data Scientist, or something along those lines. Probably varies by company.
Recently I worked on a contract doing some data ingestion that the resident team didn't want to deal with.
They had been provided a JSON api to get what should have been a batch file. The owner/api creator said "this is good enough we won't accommodate you." So much for sensible data transmission and batch processing.
Because I have had to deal with these sorts of things before I have a fairly robust tool chain to hammer api's with requests to get the data in a reasonable time frame. In this case my client went full tilt - and simply hammered the API till its owner gave in and started sending batch files.
Instead the client was given an api to query and no batch processing of information was allowed.
I’ve encountered this idea somewhere, and fortunately have never had to deal with such a broken scenario. Getting piecemeal information is infuriating.
[0] probably an FTP server with no TLS and with the same weak username and password for everyone who connects, a setup which they won't change no matter how many times you ask
repeated variable names are bloat when getting lots of data, extra formatting is the same... CSV's are great for getting these things down.
As another poster pointed out (S)FTP is the way to go when sending CSV's, and they are compressed in most cases to save storage and data transmission on both ends.
I am old enough to remember when mailing a hard disc or a tape might be a faster way to move a LOT Of data. The practice is still alive and well, but the option is now by the "truckload"