Computer Science Canada Idea for game programming |
| Author: | mirhagk [ Fri Feb 25, 2011 8:04 am ] |
| Post subject: | Idea for game programming |
Games are update at 60 fps, and I've decided to use a 4 stage system, I want to know if it's a good idea. There are four groups of update methods, the first group is NECASSARY update methods, stuff like audio, input or other things that must be updated 60 frames per second. PRIMARY update methods, which should be done every frame, but can be skipped a couple frames now and then if it's running slowly, such as a physics engine. SECONDARY update methods can be updated every other frame, and can be skipped for a couple frames when needed, stuff like animating models. TERTIARY update methods should be updated about 10 frames per second, but can be skipped to only 2 frames per second when needed. This is stuff like checking mission objectives and such. I just wanna know what you think, and where stuff like AI should fall under. And should I have each different object be categorized into one of the four, or should it have multiple update methods? |
|
| Author: | DemonWasp [ Fri Feb 25, 2011 8:26 am ] |
| Post subject: | RE:Idea for game programming |
It's not a bad idea, and this sort of thing is done implicitly (I've never seen anyone discuss it in terms as rigid as yours) in a lot of games. Don't forget to consider how your game will communicate over the network, if it's multiplayer. You probably do not want to synchronize to the time specification of "frames". Instead, think of "ticks", which is the number of network updates per second from the server. This, at least, is the way that "Counter Strike: Source" works, meaning that in general that's how the Source engine works. You are correct that audio and input should be updated as much as possible. Physics engines have two main types of computation to do. The first is the mundane (X is moving at speed X.v, update position of X...). The second is to calculate collisions and determine the effects of interaction. I'm not super-experienced, but I suspect that the first kind needs to be done at every tick, whereas the second kind can wait for some fraction of a second (every 20th of a second, say). I could be wrong. I'm not sure I've ever heard of animating models taking up additional resources to any great degree; I think in general the cost of model updates is folded into drawing them. Drawing a model is so expensive that you may as well make sure you're drawing the right one. You can probably check mission objectives every other second, for all that it matters. On the other hand, this is probably the cheapest computation, bar none, that you've mentioned here. You could check it every tick and nobody would ever notice, unless you do something hideously complex. The question of which category AI should fall under depends on how your AIs are implemented. In general, however, AIs don't need to be synchronous with ticks / frames, but should probably be invoked every few frames to update their targeting or whatever. Again, if your AIs have two kinds of updates (tactical and strategic, where tactical selects a target / where to move and strategic selects pathfinding to the objective across the map / where to ambush from) then you can probably favour updating one over the other. |
|
| Author: | mirhagk [ Fri Feb 25, 2011 8:35 am ] |
| Post subject: | RE:Idea for game programming |
yeah I think I'll set up the AI with two different update methods, like you suggested. Choosing where to shoot etc pretty often, and choosing any strategic things such as when to run away, when to hide, when to shoot etc only a couple times a second. Pathfinding too will go under that. I know mission objectives shouldn't really take up any time, even though I've chosen a system that optimizes for ease of programming, sacrificing speed. I'm just saying that that sort of thing can go there. My game is not going to be networked, although I will leave the option for it, just in case I decide to add it. For instance I will center the game around frames, but I will make sure the game has room to have update methods centered around ticks from the host. Although most things should be updated completely seperate from the host (like drawing, and moving). I think for networking every client will be in charge of it's own stuff, like where it is, where it can move, who it's shooting at, if it misses etc, and the host will merely tell everyone these things, and take care of global goals. |
|
| Author: | DemonWasp [ Fri Feb 25, 2011 10:43 am ] |
| Post subject: | RE:Idea for game programming |
Another important thing to consider is that if you run "expensive" operations infrequently, you want to make sure you aren't running all the expensive operations on the same tick, because then you have one very long tick and a lot of shorter ticks, which violates the whole idea of the tick (discrete near-uniform quanta of time used as the basis for simulation). Basically, you want to make sure that the AI and the physics don't fire on the same tick, or that will be a relatively slow tick, and may degrade performance perceptibly. If your game is ever going to consider being networked, it's probably best to do that first. Adding networking after the fact will generally require a complete redesign to do it properly. You have to be careful when designing the network portion of your game. If your clients handle their own validation (ie anything that makes sure what the user is doing is valid), then a modified client can change its in-game behavior. If, for example, collisions are done on the client and the client then reports its location to the server, that means that if I modify my client I can walk through walls. Perhaps more frustrating is an alteration where I always hit my enemy in the head the instant he rounds the corner, just because my client application said so. Hell, I wouldn't even have to play: just have the program set my location to immediately behind the enemy, fire a single bullet through their head, and move on to the next enemy. It's fine to take care of some validation on the client side, but you should always take care of all validation on the server side. For example, it may be faster or smoother from a client perspective if their program detects them colliding with walls and prevents them from walking through them, but the server should also check to make sure that the client isn't a dirty liar. |
|
| Author: | mirhagk [ Fri Feb 25, 2011 12:03 pm ] |
| Post subject: | RE:Idea for game programming |
Just for clarification the game will run on the xbox, which I point out seems to have a lot of client side validation. (Which makes the whole JTAG-ing thing possible). The host will do some verification to make sure the client isn't lying, but full verification isn't possible with all the potential lag. I'm not making it a part of the game, but I'm making the game very object oriented, and very willing to accept networking. It'll be pretty easy to add it in later with my current design. And yes that whole skipping frames thing had at it's heart the concept of updating different things on different frames. For instance I will have the Primary things not run whenever the tertiary things run, and the secondary things will alternate. |
|
| Author: | DemonWasp [ Fri Feb 25, 2011 12:18 pm ] |
| Post subject: | RE:Idea for game programming |
Just because hacking is more difficult on the XBox does not mean it's impossible. In general, it may make more sense to leverage an existing engine. For example, the Unreal3 engine runs on both XBox and PC trivially: you can develop on your PC and then run on the XBox later; as I recall, the UDK is free for some non-commercial uses. You get to skip a lot of this complexity if you use an existing engine. Also, be aware that no matter how beautiful your object-oriented design is, networking isn't a trivial feature. Building a game to work only locally then adding multi-player later: very difficult. Building a network-capable game, but playing it only locally: trivial. Most modern games work this way anyway: when you start up the "single player" version, it starts the server on your machine and then connects to it. You never know the difference because there's no lag / latency. From the developer's perspective, it's simpler too: multi-player and single player are the exact same thing, with the tiny exception that you connect to a different server. It's certainly possible to add multi-player as an afterthought, but my strong suspicion is that you will regret it if you try. |
|
| Author: | mirhagk [ Fri Feb 25, 2011 11:07 pm ] |
| Post subject: | RE:Idea for game programming |
I've designed every actor class to run very much apart from the main system, receiving updates from a server would actually amount to about the same thing as of right now. And it's definetly possible, but it's possible no matter what I do. I'm pretty sure any measures that I could do, somebody who has huge issues like call of duty could do better. And the thing is I'm not an artist. I'm the kind of programmer who likes get his hands dirty with stuff like this, not artwork |
|
| Author: | DemonWasp [ Sat Feb 26, 2011 2:22 am ] |
| Post subject: | RE:Idea for game programming |
Okay, so your existing idea can handle receiving updates from a server and working with those easily enough. How about sending updates to the server? How about the server-side code, wherein you have to receive and authenticate actions, then compute the results and forward that to other clients? What about lag compensation? Depending on your scheme, you may not be able to use random numbers for certain things, or you may not be able to do things in a different order from one machine to another. Consider carefully: if you do it wrong, client and server can get out of sync (very bad). There are a lot of helpful articles on how some of the first multiplayer games worked (Quake, etc) available on the Internet. In any case, it's up to you. You may, if nothing else, want to do some research on how to implement multiplayer before you assume that your existing architecture will work well. |
|
| Author: | mirhagk [ Sat Feb 26, 2011 10:43 pm ] |
| Post subject: | RE:Idea for game programming |
I have actual read several chapters in several books dedicated to network gaming. Yes actually the framework will need to be modified, but with OOP, adding an external actor that is updated from elsewhere is not overly difficult, and the updates would include position+velocity, and the class would predict where it would go, and then smooth it out as it recieved the actual location. Having coded all this yet, but I've thought about it all. And i don't believe in random numbers. Seriously, other than for stuff like particles where it doesn't actually affect anything, nothing is random in the game. I instead opt for the chaos theory way of doing random. for instance if an enemy decides whether to attack based on distance to you, how much ammo it has, health it has, and health you have, there is no possible way you could predict the outcome. You could however print out stats in a debug session to easily test it. Choas AI is the best since you can't predict exactly what it will do, but it's not unreliable. It may attack you at different distances based on the other factors, appearing random, but it's actions will make sense. I actually take this to the extreme I admit, but I prefer having control. For instance say in an RPG the AI "rolls" to see if it can see you sneaking. I would never use a random number generator, but would rather intertwine a number of factors so that it'd appear pseudo-random. For instance how many items you have, where it's looking, how far away you are, how much light is in his eyes, how much light is around you, your sneak level, his perception level. I'm sure I could think of tons more but you catch my drift. I know, it's slower, but it makes AI act alot more lifelike IMO. You can even add things to the AI like their mood, which can change, and influence their actions. Nothing would be random, so a machine would easily be able to follow along, but a human couldn't. I seriously never use random number generators in games, except for graphics, which doesnt matter. That way on a multiplayer game, even if the systems lagged so hard that they didnt update for like a second or two, the only parts they would need to sync would be what they did in the last 2 seconds. |
|
| Author: | DemonWasp [ Sat Feb 26, 2011 11:12 pm ] |
| Post subject: | RE:Idea for game programming |
It sounds like you've thought most of this through, and I do like your description of how to get around using a pseudorandom number generator. Good luck with your game. |
|
| Author: | mirhagk [ Sun Feb 27, 2011 4:18 pm ] |
| Post subject: | RE:Idea for game programming |
Yay, finally impressed you lol. I was thinking about doing a tutorial about the benefits of using chaos theory instead of random values. Do you think I should write one? |
|
| Author: | DemonWasp [ Sun Feb 27, 2011 7:10 pm ] |
| Post subject: | RE:Idea for game programming |
Not a bad idea. I'm not sure that what you're describing is really chaos theory though: that's a specific branch of applied mathematics. If anything, I might call it "non-random number generation". One thing to consider, if you're making predictions, is that you might not want to use location, health or other changing gameplay values that could get out of sync easily. I'm not sure what you'd use instead, though. |
|