[RuneLancer]

So how's everyone building their game? In today's world of modern programming, the top-down add-as-needed just-make-it-work approach of the late 70s/early 80s BASIC programmers no longer works for any maintainable project, so a little planning and consideration has to be put into building a game.

Personally, I have my main game singleton which manages everything: game states, the nitty-gritty mechanics behind data management, etc. Running directly under this (more or less parallel) is a multimedia singleton which is fully capable of independantly rendering a map, playing music, and displaying stuff. Each of the game's main states (world/town/dungeon map, battle, menu screen...) "connect" to this singleton depending on what state the game's in.

Graphic-wise, each "state" only sets things up (load the map file and send it to the multimedia engine, load the battlefield and send it to the multimedia engine, load the menu- y'get the picture.) Beyond the setup phase (and any additional loading that must be done in-game, such as when casting a spell and loading its graphics for instance) the game's "state" singletons do absolutely nothing graphic-related. They just sit there and wait for stuff to occure. Player attacks? Calculate the damage, send the animation data for the attack to the multimedia engine, decide wether NPCs on the map move, etc.

Of course, only one state singleton can run at once. The main engine is what switches them on or off, making sure you're not in any awkward situations.

Basically, it goes a little something like...

[DrunkenCoder]

Currently not working on anyting game related. But I usualy use TestDrivenDevelopment and Refactoring Im a strong beliver of that sort of 'agile methods'. It's funny that you should mention your high singleton usage as a design perk of your engine. I've had an idea for an article called "singleton (ab)uses" floating around inside my skull for quite some time. Need I say more than that I don't fully agree with your solution design wise? ;)

For a quick rundown have a look here:
http://www.c2.com/cgi/wiki?SingletonsAreEvil
et
_________________
If there's life after death there is no death, if there's no death we never live. | ENTP

[Rainer Deyke]

I'm currently working on scenegraph based engine which is totally different from everything I've done before. Basically everything on the screen and a lot of things off the screen are organized in a tree structure. For example, the playing field is one node in the tree, the player sprite is a child node of the playing field, and the weapon in the player's hand is a child node of the player sprite. Or one node could be the inventory menu, and the actual menu items would be child nodes below that. In other words, I have a single uniform system for handling gameplay sprites and user interface elements. The scene graph is responsible for updating the game state (through the update method of each node), rendering the game state (through the render method of node), collision detection between nodes, and even sound.

The neat thing about the system is that I can apply a transformation at one level, and it propagates downward automatically. For example, I can flip the entire screen by setting the horizontal flip bit at the top level node. Or I can fade a window to black by setting a color transform on the window, and everything in that window is automatically affected with no further programming effort.

[LeoDraco]

While, obviously, there are abuses of Singletons, I don't think they are, necessarily, wrong or evil; just abused. At the very least, they provide a mechanism for ensuring (moderate) resource control.

At the moment, as I'm still working on the specifications for the various games I have floating about the old gray matter, I don't have anything going; however, I do have a generic graphics framework set up, which I can utilize for any graphically based project I want to work on.

So, this framework is built on top of GLUT; essentially, I was looking for a mechanism to utilize GLUT in an object-oriented fashion. So! I came up with what was, at one point, relatively convoluted, but which has become a bit more rational. Like RuneLancer, the outer container in the program is a singleton; but, somewhat different to what he has, my singleton manages a set of flyweights, each of which is a moderate mixture of the state and strategy patterns. At any given moment, the context manager (the singleton) will have a current context (one of the flyweights) upon which all current operations work upon. Each of the GLUT events (such as glutMouseFunc) is tied to a static method of the context manager; in turn, each of those static methods are stubs, calling the appropriate method on the current flyweight. (In this case, the flyweight acts as a strategy.)

(I should also probably mention another good reason for the context-manager to be a singleton: it also manages the single GLUT window context; as I will only ever be working with a single window, it's nice to ensure that the environment will never duplicate it.)

The neat thing about this framework is that multiple contexts may be registered with the context manager, and may be swapped out at any point. As each context fully implements the event methods, the logic needed for different contexts is localized to the context in which the data is located, rather than in some more global area.

Now! What constitutes a "context"? Looking at the standard RPG, I can have a context for the game's title screen, for the world/town map, for the battle screen, for the menu (and for each sub menu), etc.

Hmm... what else? I also have a texture-manager which is a singleton; along with the textures that it manages, it keeps track of a set of strategy flyweights, each of which implements the logic to load and store a given image file. (Although, I've only taken the time to write the strategy for png files.)

In any case, that can all be down in other ways, but I like the set up; in each case, the specific logic to implement any particular component is localized. While this might cause some moderate redundancy in the system, it also helps make the system extendible.
_________________
"...LeoDraco is a pompus git..." -- Mandrake

[DeveloperX]

Honestly, never really thought about it.
But after spending about ten minutes thinking of what I typically do, I'd have to say that I use a mix of top-down, and structured methods to develop my software.

I usually will write an empty shell of code that will compile and run on the target platform, when writing with C, and Java.
I then proceed to create reusable modules (functions, or groups of functions) to handle the data, such as the audio, video, 2d/3d graphics rendering, input, etc.
Once I have that done, I then begin writing the game's core logic routines, in common functions, so that I can easily write another game, by simply changing the code in the common functions.

My approach when writing BASIC is similar, but a few things are different, whereas I tend to write the functionality of the game straight-through, without worrying about the game's data.
I use random arrays for testing map functions, and solid rectangles for tiles and sprites, I use the SOUND command in QB, and a windows API call in VB for playing wav files to handle audio needs.

Another thing I do is create blocks of pseudocode in an english-like readable form, then I rewrite it line for line in the language of choice.
_________________
Principal Software Architect
Rambling Indie Games, LLC

See my professional portfolio

[Nodtveidt]

For me, it depends on the project platform. I develop for three platforms right now (Windows, Unix, and TG16), so I have to approach each one in a different way. Naturally, I end up writing a bit of reusable code on all platforms, but I write a lot less reusable code for the TG16 console (I have to write very optimized, streamlined, and specific code most of the time, so generic functions are rarely used) and a lot more in Windows. Everything is planned out well in advance, and I take on things one block at a time. I never set an order to this though; things get boring that way for one, and for two, things might change midstream, so sometimes I hop around from section to section, making changes...a rigid pattern tends to stifle improvement.
_________________
If you play a Microsoft CD backwards you can hear demonic voices. The scary part is that if you play it forwards it installs Windows. - wallace

[Nephilim]

When I programmed "Sacraments," I used an interface stack metaphor for controlling and displaying the game state. Basically, I'd "stack" up interfaces that could render themselves to the screen, change the game state, and interact with the user. Only the topmost interface would be active, but all could be drawn.

That allowed me to have reusable and self-contained objects for controlling different parts of the game. For instance, the map drawing system was one interface stack object that could render the current map view. Another interface stack object would be the walkaround engine that accepted input from the user and changed the map state. Another interface stack object would be, say, a dialog box spawned by the walkaround engine when the player talks to an NPC. By stacking them up, it was a simple matter to render the map behind the dialog box. When one interface is done interacting with the user, it just pops itself off the stack, and the one below it takes over.

It was an experiment, and it was a bit rushed because I was trying to get the game done for the compo, but it worked even better than I thought it would. I'm sure the design has some flaws for certain types, but it's a pretty clean way to organize a project like an RPG if you don't require something that would break that model. Absolutely everything in the game was controlled by the interface stack, from the opening screen to the end credits - you just push and pop interfaces off of the stack to get the behavior you want. I'm using this model now in a non-RPG educational game I'm doing for work, and it's working really well in that context, too.

Although I was programming in Director, which has its own multimedia engine, I basically bypassed it and did my own screen drawing routines for the visual display. But the idea could easily have controlled Director's sprite engine or 3D engine instead of doing direct rendering to the screen buffer.

I was asked to write an article on how I made Sacraments by the good guys over at Director-Online - you can read more about the interface stack model I was using here.
_________________
Visit the Sacraments web site to play the game and read articles about its development.