6
\$\begingroup\$

Although it isn't necessary to exclude things like graphics and audio packages, I'm most interested in the organization of the folders for classes that deal with AI and game state. I'm thinking something like this in Java using packages as the example:

import com.rpg.characters;
import com.rpg.characters.antagonist;
import com.rpg.characters.neutral;
import com.rpg.characters.protagonist;
import com.rpg.characters.state;
import com.rpg.gameplay;
import com.rpg.gameplay.engine;
import com.rpg.gameplay.maps;
import com.rpg.weapons;

Also, does it make a huge difference between 2d and 3d games?

Improve this question
\$\endgroup\$
10
  • \$\begingroup\$ Are you asking if separating out the different packages has a performance increase? \$\endgroup\$
    – Tetrad
    Sep 13, 2011 at 23:23
  • \$\begingroup\$ @Tetrad No, I want to know from someone who has designed a fully-featured 2d (or 3d) game how they organized the packages. Architecturally, I think it gives insights into the design without asking for the source of an entire game. \$\endgroup\$
    – user6214
    Sep 14, 2011 at 0:11
  • \$\begingroup\$ There was also a question I read recently regarding MVC in game architecture, and how it wasn't a good fit (based upon most comments). If that is a case, then there must be an organizational structure that is preferred as an alternative. Listing the package structure I think would help flush that out a bit, even if it isn't a commonly known design pattern. \$\endgroup\$
    – user6214
    Sep 15, 2011 at 18:35
  • 2
    \$\begingroup\$ Efficient in what sense? Could you use a better word to describe what exactly you're looking for? If you're just looking for code organisation tips, that's probably not AI or game-state specific (but neither is it language-agnostic). If you're specifically interested in how people handle AI, then the first thing I'd say is that we wouldnt normally have 1 class per type of character. \$\endgroup\$
    – Kylotan
    Sep 15, 2011 at 19:19
  • 4
    \$\begingroup\$ I'm not sure how "language agnostic" this question is, as there are many languages used for game development that do not have "packages". The bigger issue is that package organization does not give you any real insight into design. The important part of design is the interaction between classes, which package organization doesn't show. \$\endgroup\$
    – Nicol Bolas
    Sep 15, 2011 at 19:19

4 Answers 4

Reset to default
10
\$\begingroup\$

Usually, I start out with one file. Then, as time passes, I would eventually have:

  • Framework: Math, Random, Utility, Asset, Network, Window, Graphics, Audio, ...
  • Player: AbstractPlayer, Score, Input, Collision, Reaction, Skill, Inventory, ...
  • Map: AbstractMap, Area, Town, NPC, ...
  • Enemy: AbstractEnemy, Creep, Boss, BaseAI, FuzzyAI, ...
  • State: IntroScreen, MainMenu, LoginScreen, Game, PauseMenu, ...
  • Interface: Button, Text, InputBox, ...

This is only for the client-side of the game. XML, Lua, Javascript or SQL databases are useful for defining many different things especially different classes of players, maps, NPCs, enemies, items, quests, skills, etc. I like XML though, because of its simplicity, and its data can be parsed by any other language.

Game files are usually stored in a package file like ZIP or similar resource. I have a resource loader that looks for a file in the package, then if it can't be found, it locates the resource in a directory, or some other place. This allows me to develop quickly.

3D games are no different, but they are more complex. They need model loaders, instancing, and must use vertex buffers. They consequently make heavy use of shaders to provide other effects like lightning, bump maps, environment maps, etc.

Most 3D games have a game engine backend to do all this for them. For Java, try jMonkeyEngine. For C++, try Ogre3D. For Python, try Panda3D.

In my experience, it is better to hardcode everything whenever you can, unless the feature is specifically required. This allows you to develop the game faster, and refactor later.

Improve this answer
\$\endgroup\$
4
\$\begingroup\$

The truth is that you shouldn't be making this decision at the beginning of a project. My rules of thumb (and trust me, this is very fast and loose) are:

  • Things which are obviously different concepts can/should go in different packages
  • try to minimize the number of packages you have to reference in any one class ... if you find yourself referencing every single package, you probably have a problem with the way you're expressing your classes. Remember, Single Responsibility Principle.
  • Don't be afraid to refactor ... this is the key point here. I usually keep things simple at first and keep everything in a single namespace/package. As the project grows and I find more than a screenful of classes in a single package, it's usually an indication that I may have to refactor.
  • Try to avoid deciding on patterns at the outset of a project. Favor working code first, and then as the codebase evolves, refactoring (common theme) to patterns that may emerge from your use cases.

At the end of the day, the most important thing is getting the game working, testable (for early/often playtests), and moving forward towards shipping. Note that I'm not advocating messy, or thoughtless code ... quite the opposite, there are patterns and stuff for a reason. But rarely can one decide those things up front, you will find yourself kludging what you're trying to do into a box, when you need a circle.

Now get out there, and make that game!

Improve this answer
\$\endgroup\$
3
  • \$\begingroup\$ Do you do this with every project? I guess I'm somewhat surprised that there isn't a more repeatable process, or some acceptable patterns of organization, but I'm not a game programmer by trade so that could be the difference. \$\endgroup\$
    – user6214
    Sep 16, 2011 at 14:24
  • 1
    \$\begingroup\$ @Brian Reindel There really isn't any standard pattern for game development because every game is different. There's basic techniques that work in all games, usually found as part of a library, but usually AI and states are specific to a single game. Yes, there's exceptions (pathfinding libraries, for example), but there's nothing as strict as, say, the MVC pattern for games. \$\endgroup\$
    – thedaian
    Sep 16, 2011 at 15:32
  • 1
    \$\begingroup\$ @Brian Reindel, the answer to that is yes and no :-) in this context, there are two types of game development programming: Writing a Game, and Writing an Engine. You should almost never write an engine if your goal is to produce a game. Now, once you've produced and released that game, if you want to make a sequel, or another similar game, then it makes sense to start restructuring into something more reusable. Now obviously, game engines are useful, but a game team should almost never be the one building one. \$\endgroup\$
    – Joel Martinez
    Sep 16, 2011 at 16:03
4
+50
\$\begingroup\$

I believe is a bad idea to have antagonist and neutral and protagonist as different classes, unless your antagonists are multientity spaceships and your protagonists are mages, of course. I agree with Nicol that this is not really language agnostic, and I believe is a really bad idea to try to resume the game architecture like that. Just make a comment in the beginnig of the file or a companion .txt if you want to give insight.

Even so, I would do something like this (following the kiss rules):

 // I'm assuming java, this may not be possible if java doesn't like kiss rules
 import com.rpg.characters;
 import com.rpg.engine;
 import com.rpg.maps;
 import com.rpg.weapons;

I would recommend that if your language allows this, it probably gives the same insight and it's much easier to work with. Even if I don't have a clue about what language are you using (i'm guessing java from import com.), I would do it this way, and I could leave your approach if I were using a "characters" package that contains lots of character types and you just want 3 of them... but how would you do that? characters.antagonist, characters.neutral, characters.protagonist, characters.two_faced? or characters.mages? it makes no sense unless your characters package is full of garbage and/or your character objects do not follow some patterns, then you will want to import only the relevant characters and not the garbage code, but that would be sign of a bad design.

Also why a package for states? isn't the state just an integer? does it require a whole package? do you really need to give insight about "there are antagonists in my game" by listing the packages? given that most computer games have antagonists... did you already code all those packages or you are just assuming they would look nice and straighforward that way, if they existed at all?

UPDATE: From your comments and the question edit I wanted to add some things.

There are some coding patterns that are common in game engines but the truth is you can't anticipate by using those patterns if you are not used to them/have experience enough with them, that's also why it's easier to start with a game instead of a game engine. In the package list from your question it's easy to notice that you're overengineering already, but you don't really know how will you code things in there (your package design is overly complicated for no reason).

You can represent most characters with a single class or so, it makes no sense to have such package/namespace distinctions, think about them as if they were an image/texture class, often you don't have pngimage, gifimage, tiffimage, bmpimage etc you just have image.load(), characters could be thought as a resource. They will share most attributes such as position or direction or AI algorithms, you may even want the player to be controlled by the AI at some point, or be able to control an enemy. It makes no sense to have another object for just one function--unless you're using a component architecture for complex game entities, but then they would be components, not characters.

I also disagree with the advice of hardcoding from Roy, you should never hardcode, because it will be harder, specially for an rpg, you have to find a scripting solution that lets you modify game states during runtime for character and item design, or you will be running the whole application every time you want to balance the stats of anything (at the point you will be spending more time running/compiling the app than anything else).

Of course if you must ship fast just put everything in a single file and pray, but otherwise take your time for doing it well.

Improve this answer
\$\endgroup\$
-1
\$\begingroup\$

A single file to begin with, and split-out into separate files as/if required.

Improve this answer
\$\endgroup\$