Tag Info

Hot answers tagged

29

If you save in combat, you run the risk of saving just before something is going to kill you. Reloading that saved game just puts you right back into the game moments before that event, and it can sometimes be impossible to recover. As an example, I have a saved game right now in Dead Space where my health is incredibly low, and not 1 second after the ...


28

I think you're just arguing semantics here. It's called Game State because it behaves like a Finite State Machine, with a finite number of states and transitions between them. The 'Game' in 'Game State System' refers to the overall system, with 'Loading', 'MainMenu' etc being states of the game. These could easily be called 'scenes' or 'screens' or 'levels'. ...


21

There are a number of reasons that I can think of why designers would do it this way. The first and probably the most important reason is to prevent really, really annoying the player. E.g. You're in a middle of a tense firefight, you save the game, leave it for a few weeks, load it back up and you're under fire from all angles without any room to breathe. ...


20

I'm pretty sure it is most often done in a proprietary (binary) format, just writing each variable from whatever game state struct you use into a file, or reading that file back into an instance of the struct. In C++ for example you can treat an object like an array of bytes and just fwrite() it into a file, or fread() from the file and cast it back into its ...


17

Behaviour trees are getting pretty big in the industry right now. Halo 3 uses them extensively for their AI (Halo 3 - Building a Better Battle). Alex Champandard seems to be a big fan as well (Lots of articles on it on AIGameDev.com). For code examples, take a look at: ...


15

I think the existing answers are very good but I want to posit another possible reason. Disabling save prevents the user from using as a cheap crutch, saving right before taking a serious risk and then reloading their save if they fail. I used to do that all the time in RTS games and it eventually sucked all the challenge out of it. Similarly in console ...


12

I once came across an article that solves your problem quite elegantly. It is a basic FSM implementation, that is called in your main loop. I have outlined the basic rundown of the article in the rest of this answer. Your basic game state looks like this: class CGameState { public: // Setup and destroy the state void Init(); ...


11

In general that's a very complex subject. You have two conflicting aims (at least if you don't plan on running every single game on a dedicated server): You'll want as much as possible done on the server, both to prevent cheating and to make sure all clients see the same things. But you also want things to be fair, which means if one person has a 0-time ...


11

Remember that all you need to save is the dynamic data generated at runtime. For example, if you have a monster about to attack the player, you need to save its position, its monster type, and its aggressive state, but you don't need to save its textures, model, behavioural scripts, and so on, because they are part of the static state that can be inferred ...


10

Here's an example implementation of a gamestate stack that I found to be very useful: http://creators.xna.com/en-US/samples/gamestatemanagement It's written in C# and to compile it you need the XNA framework, however you could just check out the code, the documentation and the video to get the idea. It can support state transitions, transparent states ...


10

I wrote a FSM based off of a chapter in "Massively Multiplayer Game Development" Edited by Thor Alexander. Inside is a chapter labelled "Parallel-State Machines for Believable Characters". This is written in python, but the concepts are easily translatable into C++. I highly recommend checking this out, even though this is about character states, not game ...


10

I would also consider allowing a stack of states. That way when the state on top leaves, the state under activates. this is really nice for menu states. When one menu leads to another, it simply puts the next state on top. If the user wants to go back, you simply deactivate the current state and the previous state activates. Very easy for menu navigation. ...


10

Battles are entirely separate things from any of the objects you mentioned. Yes, they take place on a Tile (and, naturally, within the Map), and happen between NPCs and the Player, but none of these object is the Battle. I would suggest creating a new object, Battle, to maintain battle state. Hand it the participants and any terrain info it might need (e.g. ...


9

The basics are there, but I think you want to break them down a little bit more. State - Find Something To Do Enter - Nothing Execute - Pick something to do from a big list of options weighted however for this AI personality Exit - Transition to new state (For this example its 'Enter Mine') State - Enter Mine Enter - Start playing an enter animation ...


9

It's not necessarily a sign of any flaw. Not every entity or state will have a use for every available method. Just leaving the execute() method empty would be fine, IMO.


9

Not having read the book, those calls sound like normal entry points for a state machine. To understand the calls, let's look at what they do. enter() - executed when the state is activated. execute() - executed while the state is activated. exit() - executed when the state is deactivated. These fit any kind of state machine. Some machines only need the ...


8

My suggestion is to not have game states like this whatsoever. Most of your essential game objects exist across and outside of all the states (eg. renderer, resource loading, input, networking, audio), and a massive amount of the rest span multiple states (eg. players, some NPCs, certain resources). On top of that, the stack system doesn't seem to work well ...


8

Programming Game AI By Example (http://www.ai-junkie.com/books/toc_pgaibe.html) has an example implementation that's pretty straightforward and just handles the basics. Transitions are handled in a single method call (first Enter(), then Execute() every update, Exit() when transitioning)> I don't know what you'd need besides that. I would implement more ...


8

I will try to answer this as best as I can, but there are certain "best practices" which I am unsure on, but I'll try to break it down as cleanly as possible. FSMs Firstly, the Miner tutorial is from Programming Game AI by Example by Mat Buckland (which I do recommend you get as an introduction to AI). He uses an enum for each state, NOT a struct. With the ...


8

I'm not sure what sort of hierarchical FSM do you have in mind, so I'm sorry if this does not directly answer your question, but I'd really like to take the chance and add some input from my own experience using a stack based screen manager. Since you need the ability to open a popup screen but still be able to see the screens below, having a stack based ...


8

What is often used is an intermediate Intent System which abstracts the input and keeps track of the context and relevant gamestates. The Intent system will stop transmitting inputs when the simulation is paused for example. It also handles the mapping between controller events and intents (move in direction, run, shoot, reload...). This way your other ...


7

Here is the method I used in my games. First, every object that needs to be persisted must implement the NSCoding protocol. You want to only store your model data and nothing specific to the current process. This means that you can't persist pointers or any resource ids that the OS gives you at runtime. For the pointers you can fix this easily by just ...


7

States are not actions, in your game they would control how the character is updated (e.g. each state could have its own update() function). Take a look at the diagram on this page: http://en.wikipedia.org/wiki/State_diagram. The states tell us something about the world (the door is open or closed). The actions show us what takes the world from one state ...


7

It does seem a bit odd to have Need To Run and Run states. What might be better is having a Running, Walking and Fighting state. Your finite state machine then checks the appropriate logic (Do I need to run? Do I need to walk? etc) to determine what state to transition to. Check out Programming Game AI by Example. In that book, there is an implementation ...


7

I'm not sure what it is exactly that you want to achieve. But, there's one pattern that is used constantly in game servers, and may help you. Use message queues. To be more specific: when clients send messages to server, do not process them immediately. Rather, parse them and put into a queue for this specific client. Then, in some main loop (maybe even on ...


7

The brute force approach as recommended by others is how you should proceed. Modern CPU's, even mobile ones, can check the whole board several thousand times per second, so you should not worry about game freezing. However in your question you ask can this be speeded up, a question that will become very important if your game becomes more complex. And the ...


7

I gave this problem - flexible computerized card game engine - some thought some time ago. First off, a complex card game like Chez Geek or Fluxx (and, I believe, Dominion) would require cards to be scriptable. Basically each card would come with its own bunch of scripts that may change the state of the game in various ways. This would let you give the ...


7

I agree with Jari Komppa that defining card effects with a powerful scripting language is the way to go. But I believe that the key to maximum flexibility is scriptable event-handling. In order to allow cards to interact with later game events, you could add a scripting API to add "script hooks" to certain events, like the beginnings and endings of game ...



Only top voted, non community-wiki answers of a minimum length are eligible