Still trying to muddle through. I have a question for you more experienced C++ programmers.
The Python version is implemented procedurally. That is my way of saying, there are multiple loops. In this way, program state (title screen, menus, gameplay, edit mode, etc.) is basically kept in the instruction counter.
It's a comfortable way to program, basically how I would implement things back on the old Commodore 64, but is hard to convert to an event-driven paradigm, which is why the pyglet and, maybe, the C++ versions are bothersome to develop. (Well that and the fact that C++ is maddeningly finicky.) I'm trying to design this one using a master event loop that switches off depending on the program state. Which is not how I ordinarily would do this, but it seems to be what is expected from a more professional program, and when it comes time to make an iOS version would potentially pay off there.
Or will it? I'm making assumptions that might not be borne out by practical considerations. It is an alien way for me to code, a method that requires a bit more forethought than I'm used to. In the past, I've coded in a kind of iterative way: I know generally where I'm going, I think out what will be necessary, then I try to get a bit of the way each time. This seems like something more architectural.
Or is it? Does this make sense to any of you? Is there a better way to do this that I haven't considered?
Event-driven is the way to go as far as I am concerned. Not a professional (games) developer but have read a lot of source code.
ReplyDeleteIt might be a pain to switch your mental model, but once you get it going it should make things easier.
My only question -- why more than 1 main event loop depending on state? You should be able to capture all user action in 1 main (literally, in main) loop and determine where to send it based on game state (title screen, gameplay, etc).
But honestly it probably doesn't matter what you pick right now. Law of roguelike programming says you will end up re-coding it at least twice before you are done! :)
Event driven with a single main loop will generally work better with a variety of UI frameworks.
ReplyDeleteYou could have multiple loops. It works and I've done so under time pressure, but it tends to be clumsier in the long run. You're likely going to run into logic that all of the loops need to implement identically: Coping with a WM_CLOSE or similar even from the operating system, reinitializing your graphics context the user Alt-Tabs away from your full screen game, and the like.
I'd expect this to be true for any procedural or object-oriented language.
ideally you should use an abstract class that represents your game state,
ReplyDeleteclass gamestate
{
virtual void updategame(gameobject g);
}
class gamestate_menuscreen : gamestate
{
override void updategame(gameobject g)
{
}
}
//mainloop in your game object
gamestate currentstate;
while(true)
{
currentstate.update(this);
//handle OS
}