Need help with general game design

Newbie & Debugging Questions
#1

Hello all,

I am trying to write a simple real-time game that will can be played on a single computer, or with multiple computers over a LAN network. Because it could get messy very fast, I want to make sure that I have a good foundation before working on the details. Ideally, I would like to separate the logic and graphics, but I am having trouble figuring out how to do that.

Let me describe what I came up with: when the game is started, a UI is opened for the user to decide whether to start a local game, join a remote game, or start a dedicated server (and mess with settings etc.). Everything will be displayed on a single GamePanel (a JPanel inside a JFrame) which will use active rendering for everything. Different screens (main menu, running game, etc.) will be handled by using different GameState objects, which will handle their own rendering on the GamePanel.

When a game is started, a server will manage the game, and clients (which represent players) will connect. The clients may or may not have GUIs, depending on if they are AI or human. The server will handle the logic of the game, and send out each update to every client (perhaps 20-30 ticks per second). The clients will manage the UI (if present), listen for input, and send commands to the server.

My problem is that I do not know how all of these components will interact with each other. And this leads me to ask: Am I on the right track, or is there a better way of doing things? I have searched the forum, and own KGPJ, but still am confused about how to organize a game. Please, let me know what I am doing wrong, and show me how it can be done better.

Thanks :slight_smile:

#2

This isn’t really an answer to your question but if it is one of your first games, especially an RTS, you may consider just writing a single player first. There is so much to do and so many hurdles to overcome (AI, pathfinding, speed, balance, etc) that leaving out a hard one like networking might save you time. Pathfinding alone is probably one of the biggest bane of these games. Just a suggestion. We spent months developing network code that was stable and good and it turned out almost no one used it.

#3

Thanks for the response. Many of your points are quite true, but let me try to clarify where I am coming from.

[quote]…especially an RTS…
[/quote]
Well, what I meant is that I want real-time synchronisation of some sort between clients and the server. Not that I would be writing an RTS.

[quote]…you may consider just writing a single player first. There is so much to do and so many hurdles to overcome (AI, pathfinding…
[/quote]
If I write a singleplayer game, then I will have to worry about AI and possibly pathfinding, which is why I want to write a multiplayer game. Plus the fact that multiplayer is fun! Also, is it a bad idea to write a game so that even singleplayer will use the client/server model and use clients for AI players?

I realise that making any kind of RTS is a huge job, and I am not trying to accomplish that right away. What I want to do is make a framework that I can build on, and that will work for a very simple game or a fairly complex one.

I hope I clarified what I am trying to do, and I appreciate your comment.

#4

I have two bits of general advice. (1) you must have absolutely strict separation of GUIs from other
game components. Conceptually, consider that your game might have observers as well as players,
and that observers ought to see the same things as players. (2) everything that changes game state
has to go through a message. When you want to (for example) move from a to b, you send a message
that says move from a to b, then the recipient of the message actually does the move, then the observer
changes the GUI to show you that it happened.

#5

Ok, so I have read your comment, and read a few other articles on the forums as well. Also, I found this short paper on game design: http://www.devmaster.net/articles/oo-game-design/

I think that some of the methods mentioned in the article are good, such as using states and actions, and separating entity from form. However, I am having trouble imagining how some things would be implemented in Java.

Regarding your first point, ddyer, it seems like a good idea to have two different ‘Spaces’: a LogicalSpace and a VirtualSpace. That would help to separate logic from GUI. I am pretty green though, so I ask a general question: Is this how you separate the game from the graphics, or is there a better way?

If it is the way to go, how to you keep synchronization between the two planes?

As for your second piece of advice, by messages do you mean method calls, or something more specific? Would a system using State and Action objects fulfill the same goal? For those of you who use State(s)/Action(s), how do you implement them? With a different subclass for each State/Action, or something else?

Another question I have: is it a good idea to treat players as entities? That way, players could have their own states, perform actions, and be updated along with everything else.

I really have a lot of questions, but I want to get off on a right track, realizing at the same time that there is not one ‘best way’ for game programming. Thanks for your patience.

#6

hi,
If your new to game programming you might want to start with a game frame work that has simple game tutorials.
Thats how i learned how to organise my game structure all the other stuff comes later like networking.
Take a look at gtge or slick tutorials then once you understand more you can move over to swing, unless you can find a simple swing game tutorial. ;D

#7

I generally have a “board” class which encapsulates the game state, and which interacts
with other classes in a few, very restricted ways. Mainly, there is ONE “execute” method
where all changes to the game state are initiated, and there are a few information reporting
methods such as “get the contents of cell X,Y”.

The “viewer” class inspects the current state of the board and generates graphics, but it
never, ever changes anything in the board, and never, ever gets involved with the mouse
or keyboard activity.

Mouse, keyboard, and network activity is limited to making appropriate entries in event queues. They
never take any real actions, just make notes for the main game even loop to process. This discipline
also applies to the graphic portal’s requests to repaint display. Don’t do it locally, just queue a note
that the display needs to be refreshed. It’s really difficult to correctly manage 3 or 4 threads all demanding
that things be done to the game, so finesse the problem by forcing all the asynchconous events into
a single execution thread.

The main game thread cycles between evaluating and responding to input events, mainly through
the “execute” method of the board, and invoking the viewer to generate updated displays.

Conceptually, if you serialize everything going into the “execute” method, and transmit it to the
other players, everyone will remain in sync.