My flags are furled
I want to ask about flags. Thousands of flags are read, created and destroyed within any game engine where the environment changes in any signifigant (not to say dynamic) way. For RPGs, flags are an integral element of the game, as indespensible as scripting. Also, for simulations and strategy games, I suspect flags are similarly important to managing plot and the general composition of the game world. Why then, doesn''t anyone discuss, write tutorials, offer sourcecode, and, like every other aspect of game design, develop various methods of implementing flagging systems into their code?
Of course, it could be that most indi games are so short or of such a genre that flags and plot related IF...THEN statements can be hardcoded in. For instance, adventure games generally have their flags actually coded (aside from the two Sierra engines), and most genres are linear enough that they need not worry about plot points interacting in different stages of their developement.
Still, I''d think with the popularity of RPGs with beginning programmers, there''d be at least some attention given to flagging systems. But, no.
Maybe I should clarify. When I say flagging system, I mean code that can do at least several things. It needs an IF...THEN interpreter that allows flags to indicate what to do if they''re triggered, and how to effect it in the game either from creating new flags or by running scripts. It needs to keep track of flags time wise. It needs to link groups of flags and generally know how flags relate to one another (for instance, if they''re attatched to the same object or not). It needs to know when in the game to check to see if there are any flags that may be triggered. It needs to be able to create new flags, delete old ones, and, depending on versitility, to devise code independent ways of flagging things so as to allow elements of the game to interact with each other in new ways.
I know that''s a pretty disordered description but I''m hoping the gist comes across well enough that you''ll recognize the type of code that I''m referring to. Hopefully, you''ll know what I''m talking about because you''ve thought about it yourself or seen it well demonstrated in sourcecode somewhere. That''s what I''m hoping because I''d like somebody to discuss (abstract theory is more than sufficient) how they''ve implemented such a system, or perhaps offer a referral to some obscure tutorial or actual sourcecode. Anybody?
I''m sure I''m more than rambling at this point, so if any of this comes off as unclear, I''d be glad to elaborate. Perhaps the best way to develop an elegant way of handling tons of RPG flags would be to start throwing out ideas of how flag arrays can be attatched to classes or whatever. I''m all for free discussion, but I''m really hoping somebody has previously thought of a smart flexible, and efficient way of doing this. And, of course, that somebody is willing to share.
Thoughts?
Firstly, this answer will be of no help to the straight ansi C crowd.
If you are using an object oriented language, I''d first like to say that all those If-then''s are not the ideal way to do things. The switch statement was created to make those much easier on the eyes. Of course, anywhere you have a large switch statement, you should be looking at ways to turn that into objects.
In a word, what you need is an EVENT structure. Java and C++ can both handle this...hell VB could. Think on a death event, rather than looking every iteration to see if the player is still alive. If nothing else, the code is MUCH cleaner this way.
Of course, this is my opinion, but since I''ve never admitted to being wrong...
Hope this helps some
Eboz
If you are using an object oriented language, I''d first like to say that all those If-then''s are not the ideal way to do things. The switch statement was created to make those much easier on the eyes. Of course, anywhere you have a large switch statement, you should be looking at ways to turn that into objects.
In a word, what you need is an EVENT structure. Java and C++ can both handle this...hell VB could. Think on a death event, rather than looking every iteration to see if the player is still alive. If nothing else, the code is MUCH cleaner this way.
Of course, this is my opinion, but since I''ve never admitted to being wrong...
Hope this helps some
Eboz
Yeah, agreed. We would expect a flagging system to be event driven. In fact, it''s implied by the very fact that the sole purpose of flags is to track and record changes that have occurred in the world, or we might say, events that have occurred in the world.
Unfortunately, switching flags on and off is the easiest part of programming flagging code. What is really needed is:
A way to store, alter, and access flags.
A way to differentiate between different types of flags.
A way to know when to check for flags, and which flags to check.
A way to link flags together and prioritize them, that is, govern how flags interact with eachother.
A logical way of naming flags and ordering them.
These are the hard parts.
Hasn''t anybody programmed something for this? Every single FF clone needs something like this, every single Everquest or UO clone also needs something like this (but moreso even, so as to coordinate immense user-driven plot systems), how come there''s not been more attention given to devising such a thing?
Unfortunately, switching flags on and off is the easiest part of programming flagging code. What is really needed is:
A way to store, alter, and access flags.
A way to differentiate between different types of flags.
A way to know when to check for flags, and which flags to check.
A way to link flags together and prioritize them, that is, govern how flags interact with eachother.
A logical way of naming flags and ordering them.
These are the hard parts.
Hasn''t anybody programmed something for this? Every single FF clone needs something like this, every single Everquest or UO clone also needs something like this (but moreso even, so as to coordinate immense user-driven plot systems), how come there''s not been more attention given to devising such a thing?
Maybe I''m missing something but I think you''re digging too deep to understand flags. It''s really not as complicated as you make it sound.
A way to store flags? binary files
When do you check for flags? When it''s relavent. You don''t check inventory when seeing if a player is alive.
A way to tell them apart? their name/values
How they interact? Game rules, see second answer
Logical naming system? int flags[1024];
Programming is simply the manipulation and display of values. That''s why there are no tutorials on flags.
Ben
http://therabbithole.redback.inficad.com
A way to store flags? binary files
When do you check for flags? When it''s relavent. You don''t check inventory when seeing if a player is alive.
A way to tell them apart? their name/values
How they interact? Game rules, see second answer
Logical naming system? int flags[1024];
Programming is simply the manipulation and display of values. That''s why there are no tutorials on flags.
Ben
http://therabbithole.redback.inficad.com
Ok, lets assume Java, since it''s terminology for event-driven programming is pretty clear.
First, you want to know when to check for flags, and which to check? Register the objects that need to know for the event the flag triggers.
For instance. I have a flag called LIVING as part of my MOB class (which all living critters in my world are decended from). When I change this flag (through it''s accessor method) to false, I fire off the MOB_DIED event. In that event, I send the ID of the MOB that died. Now, every object that gives a damn (likely , the MOB itself, my world, and the player) will have registered itself to this event. They will be immediately notified.
For saving those flags, SERIALIZE YOUR WORLD. I''m sure you want to save more than just flags during a save game.
Don''t worry about organizing your flags. Organize your OBJECT model. The flags are merely properties of your objects. Any flag that could exist without an object should be SERIOUSLY looked at. If you have one, you likely need to refactor that object model.
You are not seeing the forest for the trees. Flags are just small bits of data. Worry more about your objects and their properties. When you need to, let the object fire an event to tell the objects who care that a state has changed. Your code will be a LOT more clean, and you will find it easier to add features to your game.
Once again, hope this helps
Eboz
First, you want to know when to check for flags, and which to check? Register the objects that need to know for the event the flag triggers.
For instance. I have a flag called LIVING as part of my MOB class (which all living critters in my world are decended from). When I change this flag (through it''s accessor method) to false, I fire off the MOB_DIED event. In that event, I send the ID of the MOB that died. Now, every object that gives a damn (likely , the MOB itself, my world, and the player) will have registered itself to this event. They will be immediately notified.
For saving those flags, SERIALIZE YOUR WORLD. I''m sure you want to save more than just flags during a save game.
Don''t worry about organizing your flags. Organize your OBJECT model. The flags are merely properties of your objects. Any flag that could exist without an object should be SERIOUSLY looked at. If you have one, you likely need to refactor that object model.
You are not seeing the forest for the trees. Flags are just small bits of data. Worry more about your objects and their properties. When you need to, let the object fire an event to tell the objects who care that a state has changed. Your code will be a LOT more clean, and you will find it easier to add features to your game.
Once again, hope this helps
Eboz
Thanks Eboz,
Now that I''ve actually started actually coding around it''s a lot easier to see how I should handle flagging. I was trying to get a hold of things conceptually before and this was making it a bit hard to visualize how my flags would work. Strange, because as a rule it''s usually the conceptualization that''s easier, and the implementation that''s harder. Heh, go figure.
Regardless, thanks for the replies, it did help.
Now that I''ve actually started actually coding around it''s a lot easier to see how I should handle flagging. I was trying to get a hold of things conceptually before and this was making it a bit hard to visualize how my flags would work. Strange, because as a rule it''s usually the conceptualization that''s easier, and the implementation that''s harder. Heh, go figure.
Regardless, thanks for the replies, it did help.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement