Game Loop problem

Started by
4 comments, last by CoMaNdore 18 years, 6 months ago
I'm trying to write a small networked game, but I have very little knowledge or understanding of network programming. For some reason, my brain just shuts down when I try to understand it. But what I'm trying to do is write a windows forms app using c# to develop the client. I created a small GameLoop class that basically holds two queues, one for messages coming from the server, and one for messages going to the server. The app would drop messages in the TO queue, and this GameLoop class would read messages in the FROM queue in a while loop, and process any packets it finds in there. My problem, however, is how do I get the rest of the app to run when the while loop is going. All execution is tied up in the loop. Do I need to make multiple threads or is there a less complex way to do this? For example. I have a Form called frmGame. It's the starting point for the app. It runs, and creates the GameLoop object, which starts up the while loop to reads messages from the queues. But once the GameLoop object starts the while loop, it continues to run in that loop. I know this is a noob question, because once a loop starts it is by definition going to run the loop until it's done. I just don't see how to run the rest of the app outside of that, unless I put ALL of the game's functionality in that loop (or called from the loop). And if that's the case, how do I handle things like logging in, moving to new forms, etc., based on the user interaction? I think I'm having trouble reconciling event-driven programming with a game loop. I can provide any code if you need it, but really I'm mostly in the design stage here, trying to figure out how I'm going to write this.
Advertisement
At some point, the queues will run dry, and you will break to the main loop. Your game loop would look something like:

forever {  foreach( message in outgoing queue ) {    send( message to server );  }  clear outgoing queue();  while( incoming messages from network ) {    receive( message );    add( message to incoming queue );  }  foreach( message in incoming queue ) {    deliver( message to destination object );  }  clear incoming queue(); /* oops! forgot this :-) */  deliver( user input to destination objects );  step physical simulation(); /* may generate outgoing messages */  render scene();}
enum Bool { True, False, FileNotFound };
" step physical simulation(); /* may generate outgoing messages */
render scene();"

Ok, if this is a combat loop, or a more traditional UI driven game I can see how this works, and I can use it for part of what I'm trying to do. But my question is, and I almost hate to ask it, how do I handle normal Forms driven events in a loop like this?

For example. The game starts, the user gets a login form. After they login they get a select char form. After that, they end up at a main menu type form, from which they can go to other forms where they can view items or skills, or view other players. There's a combat form, and the combat section would definately use a loop like above, but I'm having trouble seeing how I would handle normal forms events like clicking to view another screen with items in, all the while the items list is pulled from the server. Is this making sense?

P.S. This game is really just a mock-up of what I'm trying to do. I wanted to get a small, scaled down version working first, before I attempt anything bigger. That's why it's just a Windows Forms app.
This line:
deliver( user input to destination objects );


is where the Forms events would get delivered. Typically, you'd just remember mouse and keyboard events in the OnXxxx() event notifiers, and you'd run one iteration of this big game loop inside your OnIdle() or OnTimer() proc. Just make sure you get the timer call often enough.

Most games don't use forms at all, but instead run the event loop themselves.
enum Bool { True, False, FileNotFound };
Application.DoEvents()?
You might want to seperate the rendering and the network prossesing.
So that the rendering wont go to a screeming halt when you hit a lag spike.


- Me

This topic is closed to new replies.

Advertisement