Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (533)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Why all the file based games?  (Read 1717 times)
0 Members and 1 Guest are viewing this topic.
Offline DazKins
« Posted 2012-10-27 15:05:19 »

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  Huh

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 Huh

DazKins

Check out my Dev Blog: http://dazkins.tumblr.com
Offline ReBirth
« Reply #1 - Posted 2012-10-27 15:08:35 »

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.

Offline DazKins
« Reply #2 - Posted 2012-10-27 15:10:41 »

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

DazKins

Check out my Dev Blog: http://dazkins.tumblr.com
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline ReBirth
« Reply #3 - Posted 2012-10-27 15:20:42 »

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

Offline actual

JGO Coder


Medals: 23



« Reply #4 - Posted 2012-10-27 19:11:46 »

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 Huh

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.
Offline Cero
« Reply #5 - Posted 2012-10-27 19:34:31 »

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

Offline EgonOlsen
« Reply #6 - Posted 2012-10-27 21:17:58 »

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*).

Online Riven
« League of Dukes »

JGO Overlord


Medals: 743
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #7 - Posted 2012-10-28 00:50:17 »

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.
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.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline ctomni231

JGO Wizard


Medals: 98
Projects: 1
Exp: 7 years


Not a glitch. Just have a lil' pixelexia...


« Reply #8 - Posted 2012-10-28 01:53:55 »

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.

Offline pjt33
« Reply #9 - Posted 2012-10-28 09:19:51 »

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.


2. 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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline EgonOlsen
« Reply #10 - Posted 2012-10-28 10:56:25 »

Everybody tries to be efficient, or the competition will take over. That includes coders, carpenters and bankers.
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...

Offline SwampChicken
« Reply #11 - Posted 2012-10-29 04:52:43 »

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.

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.

:|
Offline actual

JGO Coder


Medals: 23



« Reply #12 - Posted 2012-10-29 04:56:16 »

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.

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.

:|

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.
Offline StumpyStrust
« Reply #13 - Posted 2012-10-29 05:13:31 »

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.

Offline deepthought
« Reply #14 - Posted 2012-10-30 18:47:38 »

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.

jocks rule the highschools. GEEKS RULE THE WORLD MWAHAHAHA!!
captain failure test game
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

pw (26 views)
2014-07-24 01:59:36

Riven (25 views)
2014-07-23 21:16:32

Riven (20 views)
2014-07-23 21:07:15

Riven (22 views)
2014-07-23 20:56:16

ctomni231 (51 views)
2014-07-18 06:55:21

Zero Volt (46 views)
2014-07-17 23:47:54

danieldean (37 views)
2014-07-17 23:41:23

MustardPeter (40 views)
2014-07-16 23:30:00

Cero (56 views)
2014-07-16 00:42:17

Riven (55 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!