Why all the file based games?

Newbie & Debugging Questions
#1

When i’m looking for little tips and tricks on making games in Java people always seem to suggest to me making databases and using files to load in data for the game

WHY ???

Personally I’ve found writing things out in code is better because you can individually script certain items if you wanted and you can have lots of customization but when you use a database or load things in from a file you have less customization options.

I can understand certain things like a tile map should be done in a file but why things like item data, why cant that be done in code ???

#2

Why use file:

  • keep big thing to prematurely loaded to memory on start
  • update purpose (patch)
  • while on development, you can balance your game aspects (mostly on RPG and strategy game) which is almost stable without continuously compiling.
#3

Cant you just use debug mode to edit code as you go in eclipse?

#4

You mean hotswap? I think that will be useful on small variable change but not on multidimensional array for your tiles map.

#5

[quote=“DazKins,post:1,topic:39995”]
There isn’t anything preventing you from just writing it all in code and in most cases it comes down to personal preference. I prefer using external configuration files myself for a couple of reasons.

  1. I can more succinctly and naturally define item stats in a file than in code.
  2. You can do things like create a table with item stats as columns and items as rows. This makes it easier to compare items against one another to balance things.

Although it doesn’t affect me, if you are working on a team that includes non-programmers, it is easier (and safer!) for them to edit a configuration file than editing source code.

#6

I hate project with too many classes
I have 1 class for enemies, which is also used for the player, 1 class for items and so on and so on
Codes that have like a class for every enemy type are hideous and complicated in my eyes

Also I use one tool to create maps, ai logic, maybe items, scripts and stuff and the game is a different app

bottom line, I always try to have as few lines of code as possible

#7

Coders are the only species that tries to minimize the amount of work that they put into something that they actually like to do the most…code.

IMHO, it’s convinient to store simple things in simple formats and it’s all good if your external resource and configuration files don’t become a new kind of code just with other syntax (cough Spring cough).

#8

Sounds like words of wisdom, but unfortunately it’s not true. Everybody tries to be efficient, or the competition will take over. That includes coders, carpenters and bankers.

#9

File based is great for large games and games with a lot of features that people can customize. I think it loses value when you are coding small games and applications.

If you are dealing with users and have features in your program that may be edited, you might not want them to change your entire code base just to change one simple option. A great example of this is preferred options for the screen resolution, whether a user wants the sound on/off, or user name settings. Writing these in a file saves the user time by not having to redo options over and over, and it saves you time, because you don’t have users asking why they can’t save the settings.

Of course, if you have a small application, it is a lot easier just to change the code to add features. When your code gets large, having files store your data will be a much better option in the long run. Compiling large sections of code usually is prone to making plenty of errors. At least with the file system, you can find where errors are much quicker and without having to recompile.

So, in short…

Small apps: Re-factor code to make changes.
Large apps: Reduce compile time and errors by using a file based system.

#10

This isn’t specific to games. It’s a general software principle called «code/data separation».

I expected it would be easy to find an article on the subject to point you towards, but it wasn’t. I’m not going to try to write a full article on the subject myself, but basically it has two benefits.

  1. Code reuse. If you separate the data from the code, you can reuse the code with different data. I once met up with someone I vaguely knew for a coffee, and he offered me a job. He ran a research bureau, and they regularly contracted a certain other company to produce questionnaire software; they would install it on a dozen PDAs and send a dozen people out to the airport or the market to interview people. This guy reckoned that it would be cheaper to have an in-house programmer to produce these questionnaire programs. I explained code/data separation to him, and asked for requirements. It ended up with me working for three months on a program which read the questionnaire from a data file which provided an elementary (non-Turing-complete) language with control flow; I spent three days training one of his employees to use the software and write the data files; and the research bureau could prepare a new questionnaire in a day rather than paying this other company for two or three months’ work to produce a hard-coded one. (To forestall any accusations of stupidity or killing the goose which lays the golden eggs: this is the professional approach. And a couple of weeks after finishing that project, I landed a dream job at Jagex).

If you think that sounds completely unrelated to games, try this on: user-developed content. If you create a game which stores level designs in files, you can allow users to create more levels. It’s a cheap way of expanding the game, and it has the potential to provide your players with much more variety than if all the levels came from one or two minds. If the levels are hard-coded, this is almost impossible to implement.

  1. Data reuse. Cero has already talked about this. If your data is stored in a file, it can be used by different programs (in different ways). In particular, for games, you can write tools. Sometimes an in-game level editor is the best way to do things, but even in that case you need a way to save your changes.

To address your specific issue of detailed customisation: that’s still possible if you use files for data storage. The custom behaviour may need to be implemented in code, but the linking between behaviours and items can be stored in a config file. The key thing is to learn about ways of composing behaviour other than subclassing, and apply the OOP principle of favouring composition over inheritance. In particular, the Decorator pattern is one relevant approach (although possibly a bit heavyweight); the Observer pattern can be bastardised slightly to allow registering callbacks which affect behaviour; and the Strategy pattern specifically supports different behaviour for the same task.

#11

Have ever worked together with the" usual office worker" and are still thinking that this is true? If so, you are obviously much more of an optimist then i am…

#12

The level to which I disagree to the last part is immeasurable. In the old days effeciency was important so your showing your age with that statement Riven… (LOL) Very rarely do you see a dev think about efficiency these days, most devs these days don’t even think about efficieny and will happily introduce an entirely new (bloated) framework to avoid coding a class or two. And then after a few repeats of this cycle (when everything comes crashing down) they demand better computers.

:expressionless:

#13

There’s a difference between the efficiency with which a given set of code runs and the efficiency with which a programmer can work. Not to speak for Riven but I think he talking about the latter.

#14

Look are Red Alert 1 and 2. They have .ini (config) files that allow you to edit virtually every aspect of the game with notepad. No recompiling or any of that jazz. I also remember Arcanum which had almost everything loaded from .mes files which were basically .txt config files. Again, could change most of game with them.

For small projects or games hard coding I think is fine. But, for anything that has any form of robustness, you need to be loading things from files.

#15

if, say, in your game you are going to have multiple types of swords with different models, lengths, and damages, it would make sense to put all of these in a file so you wouldn’t have to write a class for each type. However, if you are only going to have one type of sword, it makes sense to hardcode values so you don’t have to go through the trouble of loading them from a file.