Simple Game Design Questions

Game Play & Game Design
#1

Hello!

I’m working on the design document for an arcade clone I wish to create. Trying to implement the concept of “Think first, then code”.
Though, with lacking game design skills as well as quite a lot of experience in implementation of “ideas”/normal/good conventions I have a few questions I would like to get answered. If someone wouldn’t mind helping out I’d be very happy!

I have several books I intend to read but I can’t stop myself from wanting to know Now. :wink:

Questions:
How should I store level information? SQLite database with different tables for specific kinds of data?
Store the data in plain text or as XML inside the database?
Ex: High scores, levels, options etc.

What’s a good way to handle game objects?
Make a GameObject class and then extend it for PlayerObject, EnemyObject, ObstacleObject etc. or are there better ways to structure it? Are there game engines that handles this? If there are, would you suggest I use one of those or create the game from scratch (yes, there are pros and cons with both)?

What are the most common ways to store art/sound files?
Ex: save them raw in the game folder or use some encryption (Should I even bother with encryption?).

How should I handle collision, any “common ways” of doing it?
It’ll be a tile-based game where you only can move backwards, forwards, up and down. No physics involved.
Sprites are cubic and all are of the same size and locked to a tile based grid.
I’m not asking how to implement it, just to handle it. Ex: check a specific object with every other object on screen (which sounds very inefficient) etc.?

I suppose those are all I have on paper for now.
Google didn’t help much by the way. :confused:

Cheers,
Zolomon

#2

hold lvl info in XML files (atleast for tiled maps)
If you will have tons of objects, then make a base class. I call it Actor. all objects extend it. It will hold all of the basic things.
art/sound. art in any old image file. I think sound is stored in an ogg file(not sure though).
for collision in tiled based game. jsut run a check on the place oyu would be. basicly run a for loop on all the actors and if one will be there there will be a collision. if so, jsut dont move there.

you gotta find a good tutorial. I learned from here : http://www.planetalia.com/cursos/

Some would say to check out coke and code. but I never could qutie grasp the tutorial. cause it had things that wouldnt compile for me, so…

btw you know you got the concept down, when you have made 3 games, and have translated one into slick or other library:)

jsut remember you never stop learning in game design.

GL witht he arcade game.

#3

Collisions:

You can check every object with every other object on the screen. But, do first a broad check (like determine the maximum of the x and y distances and if that is to much, don’t examine this further) before really checking if there is a collision. So you have a simple cheap way of discarding as many of the expensive tests as possible.

In my game, I had an interface Blocking. Walls implemented this, as did the obstacles (crates and such) and creatures (everything “alive”). I put all this in a list. Every move a creature does is checked against the entire list of Blocking objects. It worked even when 10 soldiers where firing away with machineguns (each bullet had to check for collision every frame).

If you have many many Blocking objects and many moving objects you could easily make it more efficient. But there is a golden rule in optimization: Don’t do it (yet). Only do this if you have to. Have sectors where you place nonmoving blockers. Only check blocks in the sector you are in. Moving blocking objects can be kept in a global list and all of them are checked every time. Of course, you could program a little housekeeping that moves the blocks between sectors, but I find it extremely unlikely that you will need it.

#4

Oh yeah another way to do collision. is to make a rectangle around all the objects, and then check if any instersect eachother. wui9te easy actually.

#5

Hello again!

Thank you for your great input, got some more questions out of your answers.

The XML files, if I don’t want the users to be able to modify them too easily,
wouldn’t it be a good idea to place them in an encrypted database then?
Ex: Password protected SQLite database or something similar to that.
And wouldn’t data retrieval be better perfomancewise from a database than from
.txt-based files?

The art & sound files, how should I literally store them on the user’s computer? I don’t
really want to allow the user to modify any data that’s used ingame - so should I
encrypt them in some way or zip them and change the extension? What’s the usual way?

Ah, thank you for the suggestion on how to handle collision!

#6

umm, if you are jsut starting to make games you shouldnt worry about that kinda stuff. If anyone here will screw with your games files, then they are screewed up. but it wont affect it for any1 else so it wont matter.

short answer: unimportant for now.

#7

You do have a point there I suppose. Though, I really would want to start off and doing it the way that They™ do it. Mainly because I’ve learnt how hard it can be to move from one mindset to another and create a “complete” product in the process.

Thanks again!

#8

Don’t do it the way They™ do it. Do it your way! Do it quick! Do it dirty!! Do it OFTEN!!!

I am stuck in this “I’ll do it right or not at all” thing for ages and it led me nowhere… If you want to make games, make lots of them. Once you have 5 or 10 mini/arcade/retro games running, you can step up (and will be finished faster than trying the big thing first).

#9

I hate to cut oyu down, bu that is complete BS. I have switched minesets like 3 times, WITH THE SAME GAME. only one change worked.

you gotta get the basics down. change in mindset will be necessary.

if you really believed that you would right now be programming with LWJGL. but you are nto cause youa re new.

you understand. it has to do with your skill level. sure it may not be the best way, but it is the only way right now. It is better to slap your own crap together than write it a way some1 else did. be original, be creative.

#10

I understand what you mean, but I don’t agree with you at all to be honest. And I am by far creative and original, and that doesn’t really have anything to do with this. I study computer science and I know how to program. It’s mainly the design and implementation of standards that’s bothering me. Understand what I mean?

Anyway, thanks for your input. :slight_smile:

#11

His point is valid. I am a professional software engineer for over 8 years now, and be assured if you are on your own, you only change to finish something is to start quick and dirty…

#12

In my experience, it is much more easy to design a business system from scratch, compared to a game. I always develop my games on the fly (and I have completed 2 fairly big projects, some more unfinished). The big issue is that you never know where your game vision will take you. If you start out with a grand big plan you might end up with something completely unplayable. In each of my finished projects, I have started from scratch at least once. You want a working demo as fast as possible, then you discover that your vision have to change. You want to discover these things as fast as possible, so do not waste precious time and energy on the perfect design. Once you know that your core gameplay works, and have a fairly good idea how the rest of it work, you can take time to do the design. Take a break, think about the design and then start from scratch. Salvage what you can from the previous code. This is what works for me.

#13

The answer to your question about how to store level information is: it depends on what kind of game you’re making, and how much effort you want to put into a level editor. If it’s a tile-based game then it might make good sense to store levels as .pngs as then you can edit them in any half-decent graphics editor and it’s easy to add long straight lines of walls or to copy-paste-edit a room. It’s also easy to visualise the level as a whole.

In terms of performance of data retrieval from a database vs a text file: how much data do you expect to have?! Do you expect to need random access? I would have thought that in most cases you should be able to load all of the level data into memory at the start. Graphics and sound may want to be swapped in and out to keep the memory consumption to a reasonable size, but there there won’t be any performance gain from using a database (on the assumption that each item will be stored in its own file, so loading it is a straight read from disk).

I think you’re worrying too much about protecting the graphics and sound files: if the program can decrypt them then anyone who can be bothered to spend an hour or two on the task can break the encryption. The only attack that’s worth guarding against is the lazy person who doesn’t know much about programming, and that can easily be done with rot13.

#14

How to store/serialise/persist doesn’t matter much just make sure your ‘models’ are separate. If you get that down it would be straightforward to implement sterilisation/file-backed storage/xml-storage/database(ORM), the works.

There are reasons to to opt for all options.

I think the questions you should be asking is what criteria you should look at and what works for that criteria.

As for collision I usually look at trajectories and optimise around that.

#15

It’s not that bad to get it wrong. For example, if you would really store your levels in a database I guess you would soon realize that it’s far more logical to just use your own binary or XML-based file format, as the advantages of using a database are irrelevant if you want to store a few levels. These standards exist because they are the best way of doing things according to the majority of people. But that doesn’t mean they are the best way in every possible situation. Just experiment a bit with all options that seem good to you.