next »

[encoder]

anatomy - sounds like pseudo science

i tend not tot to group thins together, for me generally in programing there is no initial logic or anatomy that i follow. but there is planing, a lot of it. tend to write each bit and piece in an order that i see fit. not as a subordinate, or member of any other logical or illogical structure. then the apparent struct or hierarchy it's just another spot in the cloud, a simple property defined where the code is written to govern it.

the paradigm is like riding a chariot of 1000 horses without the chariot. see? 
and you still manage to focus on one horse at a time.

i think OOP was developed with this in mind, because there is no other discipline ( ) that can keep up with those horses.

[LemonScented]

At no time, ever, ... should animations affect game logic.

What about games like Street Fighter? The hitboxes and timing are closely tied to the animations.

So glad you brought this up :D This is exactly the sort of thing I think about.

Yes, on the surface, the hitbox appears to be tied to the animation. But why don't we simply reverse that? The game logic (should) know the position of the characters, what state they're in (punching, throwing, hadoken-ing, etc.), and should be tracking what point in the attack the character is in.

Isn't it then trivial for the display engine to simply show the appropriate frame at the moment, with the game logic still being in charge?

Of course, we want the animation to look smooth, and the engine to follow it. Not vice versa. So that approach requires converting the animation delays and frames required to exist as "states" within the game logic.. maybe not the way to go?

I don't really have an answer here, but this is an excellent example of one of many game engine structure problems I bang my head on the wall with every time.

John Nesky is right, in this case. Although there's some gut instinct that says that animation shouldn't affect gameplay, in many Real Life Game Engines(tm) animation drives a huge amount of the gameplay. If the game logic queries the input handler and finds out X has been pressed, it starts the character's punch animation, which runs at whatever speed the animator has chosen. At some point a few frames later, the animation system might indicate to the game logic that it's entered the period of its animation where it can deal damage, so the game logic gets the position of the fist from the animation system, and then feeds that to the collision/physics system to see if has hit an opponent.

It's considerably easier to just fire off an animation and forget about it until some callback or other change of circumstances a few frames later than it is to try to micro-manage every frame of animation from within an overly-zealous game logic core. Similarly, how quickly a character walks or runs is defined by the IK in the animations that get used, because otherwise the characters "skate", or you have to play the animations faster or slower than the speed they were authored at (which is going to look silly).

Incidentally, if you haven't done already, I'd recommend reading "Game Engine Architecture" by Jason Gregory ( http://www.gameenginebook.com/ ). I just finished it recently, and it's a good read. It's written by a bloke who has done engine work on several major commercial engines, and describes some of the ways different engines handle things differently, as well as the things that different engines tend to do the same, so it's a pretty good portrait of a modern game engine. It's geared towards 3D games, so parts of it aren't necessarily applicable to 2D indie engines, for instance, but even so there's plenty of good stuff in there.

[mewse]

Animation is just another form of data.

We don't have any trouble with the idea of level placement data affecting -- or even defining -- the state of the game.  Or scripts affecting the state of the game.  Or configuration files affecting the state of the game.  Or the idea that where a ranged weapon is located on a model might affect where its projectiles are fired from.

Why single out animation as the only sort of data that's not allowed to affect the game in any way, when other data is allowed to do so?

[Schtee]

Surely because the animation is purely presentation - representing the state an object is currently in - whereas the level is defining the state?

[Hajo]

I'd have expected that concepts like plugins, components, scripting and such are discussed, and not just input->logic->output, which is more or less how every program works.

Also questions how to make the game state persistent, or concepts for client-server or peer-to-peer networking.

Maybe also if component based architecture is better, or a layered approach.

Or are those not part of the anatomy of a game engine?

Still the question how much or how little presentation and logic can/must be separeted is interesting. In case of the animations, I'd assume that the bounding boxes/shapes are part of the logic, and onscreen visualy are part of the presentation layer, so they can be kept separetely. In this case the logic doesn't have to access (read) the visuals, but the only control (write) to the presentation layer.

[st33d]

That's fine and well until you write a game with destructible landscape made from pixels.

And I wouldn't think of it as presentation, it's communication. You're telling the player what is going on. If you dismiss that from being integral to design, then you might as well unplug your monitor right now.

[Hajo]

And I wouldn't think of it as presentation, it's communication. You're telling the player what is going on. If you dismiss that from being integral to design, then you might as well unplug your monitor right now.

Usually it's called presentation layer if an layered approach is used. Definitely the function is part of the communication, that is right.

Communication is bidirectional usually, as you mentioned. But in many systems the input and output channels are separated, and the end of the output channel is said presentation layer, because it presents the results to the user/player.

The end of the input channel would be the game logic or a controller component, in order to process the input.

The controller needs to know (data) how things behave. The presentation layer needs to know (data) how they look.

E.g. in a client server based approach the server only needs the behavioral data, for collisions that would be the bounding shapes. The client needs the models, sprites, to show them onscreen. The server most likely does not need them. It seems better to me to split the data sets according to which components need them.

[DeadPixel]

That's fine and well until you write a game with destructible landscape made from pixels.

And I wouldn't think of it as presentation, it's communication. You're telling the player what is going on. If you dismiss that from being integral to design, then you might as well unplug your monitor right now.

Even in that case your game logic can run off data that is completely seperate from the presentation of that same data.  The game logic doesn't need to know if you render that out as a mass of same-colored pixels, have them tied to a texture, have each 'pixel' be rendered as a larger blob of pixels, etc...

There's a layer of abstraction that can always be there.  Game logic doesn't need to know about how something is presented.  Otherwise you begin to tie yourself into a static state, and hardcoding is bad, right?

[jotapeh]

That's fine and well until you write a game with destructible landscape made from pixels.

I have one such game, or rather a prototype in the making, here.. (pressing the down arrow digs into the snow, spacebar throws snowballs..)

While it's true that 'graphic' data represents the terrain, that graphical data is just a black and white hit map which a player never sees. The 'display' in this case is a procedurally skinned version of that hit map. edit: This system is actually pretty much verbatim what deadpixelsociety describes in his post above

The point is not to be militaristic about "pixels are graphical data" - certainly they are just plain data of any kind - but the context in which you use them dictates their nature. If I printed ASCII characters to the screen as a means of display, I would still call them graphics

John Nesky is right, in this case. Although there's some gut instinct that says that animation shouldn't affect gameplay, in many Real Life Game Engines(tm) animation drives a huge amount of the gameplay. If the game logic queries the input handler and finds out X has been pressed, it starts the character's punch animation, which runs at whatever speed the animator has chosen. At some point a few frames later, the animation system might indicate to the game logic that it's entered the period of its animation where it can deal damage, so the game logic gets the position of the fist from the animation system, and then feeds that to the collision/physics system to see if has hit an opponent.

It's considerably easier to just fire off an animation and forget about it until some callback or other change of circumstances a few frames later than it is to try to micro-manage every frame of animation from within an overly-zealous game logic core. Similarly, how quickly a character walks or runs is defined by the IK in the animations that get used, because otherwise the characters "skate", or you have to play the animations faster or slower than the speed they were authored at (which is going to look silly).

Well said, and definitely something I've heard before, in particular from a friend who is currently writing a Zombie game for iPhone that uses IK extensively. My "gut" instinct tells me to separate the IK animation/bones from the skinned pieces of the character, and simply layer those on top, but perhaps there is little to no sense in doing this.

I'll definitely look into the book you recommended - I always appreciate well written literature on this subject, unfortunately every book I've ever picked up felt like it was written by a fellow working with vacuum tubes and hamsters. And not in a cool Rube Goldberg way. I think the biggest disappointment I ever had as a young Mac programmer was buying Sex, Lies and Video Games. It put me off video game coding for a long time.

[LemonScented]

Surely because the animation is purely presentation - representing the state an object is currently in - whereas the level is defining the state?

Animation is a considerably fuzzier concept that that, though. A particle effect, or a health bar - yes, those are definitely pure presentation - they take information from inside the game logic and display it visually, but nothing about that visual display is useful to feed back to the game logic layer, so it's a one-way line of communication. Animation is more than just visual fluff, though - the position of a character's limbs, for instance, can be of crucial gameplay importance, and since knowing the positions of limbs is precisely what the animation system is for in the first place, then it feeds that information back. The flow of data can be a bit circular in these cases, with the game logic dictating what animations to play, and in return being told when a foot has touched the ground (so it can play a "footstep" sound effect), or when a fist has connected with an enemy (so it can damage or kill the enemy).

It depends on the game, of course - not all games need to be wired like this, and many aren't, but it is definitely not a universally accepted truth that animation systems don't feed data or events back to the main game logic, because they can and do.

[st33d]

This is a good point actually.

In my project I'm positioning weapons on the character's body using blank MovieClips on each frame of the animation.

Code tells animation what to do -> animation tells code what to do -> code tells what graphics to do

It's loads faster than hard-coding every weapon position for every monster on every frame.

[Mikademus]

The job of a game engine is to provide useful functionality, to make it easier to create games.

In my experience, strictly formalised game engines (such as ones which mandate MVC) are not useful;  they slow down and complicate the process of creating games, rather than expediting and simplifying it.  You'd be better off to throw them away than to actually use them.


I find it far more useful to have an engine which consists of useful functionality, and just have your game code call into the bits it wants to use, rather than have the engine try to enforce a strict game structure that limits what's allowed to talk to what, or try to define and enforce The One True Way To Make A Game.

"Engine" is one of the most confused words in game development nomenclature... Anyway, strict architectures != dogmatic architectures. Large projects need strict designs relevant to the task. As you say, the purpose of all underlying game code is to facilitate the game, but system architecture (architectural patters) is a one part of the solution to the problem that is the creation of the game, just as implementation patterns are solutions to more isolate problems on the way there. Structure == good. Experience == good. Best practices == good. Dogma == evil bad fail at making and having fun. And I agree with you, one pretty nasty smelling dogma is the belief that there is One True Way (to make a game or whatever), but that is not the same as "any way is good", or "all ways are equal". Generally speaking, one should have a pretty solid reason to deviate from time-proved best implementation practices, but good developers will also generally have good reasons. Saying "strictly formalised game engines should be thrown away" is an huge overgeneralisation, but I assume you've had bad experiences with dogmatic peoples' code. 

[encoder]

The job of a game engine is to provide useful functionality, to make it easier to create games.

In my experience, strictly formalised game engines (such as ones which mandate MVC) are not useful;  they slow down and complicate the process of creating games, rather than expediting and simplifying it.  You'd be better off to throw them away than to actually use them.


I find it far more useful to have an engine which consists of useful functionality, and just have your game code call into the bits it wants to use, rather than have the engine try to enforce a strict game structure that limits what's allowed to talk to what, or try to define and enforce The One True Way To Make A Game.

"Engine" is one of the most confused words in game development nomenclature... Anyway, strict architectures != dogmatic architectures. Large projects need strict designs relevant to the task. As you say, the purpose of all underlying game code is to facilitate the game, but system architecture (architectural patters) is a one part of the solution to the problem that is the creation of the game, just as implementation patterns are solutions to more isolate problems on the way there. Structure == good. Experience == good. Best practices == good. Dogma == evil bad fail at making and having fun. And I agree with you, one pretty nasty smelling dogma is the belief that there is One True Way (to make a game or whatever), but that is not the same as "any way is good", or "all ways are equal". Generally speaking, one should have a pretty solid reason to deviate from time-proved best implementation practices, but good developers will also generally have good reasons. Saying "strictly formalised game engines should be thrown away" is an huge overgeneralisation, but I assume you've had bad experiences with dogmatic peoples' code. 

you don't to have to be an experienced programer to have a reason to deviate from time-proved best implementation practices. "proved" is OK, i have no problem with that, but "time" is a serious issue. many of the practices may not work because of a simple cause that they are outdated. for example oop or lately parallel processing, multi-threading, and so on. then there is the issue of constantly evolving languages.

another, and from my part, the most relevant. some practices cannot be applied to a type of game like to another. and as a game developer specially indie you might want and do experiment with different, new genders. so

"strictly formalized game engines should be thrown away" because they do not facilitate improvisation and invention. they are good for machines. i tend to master them not become one of.

if you browse for an engine, what is the first thing you search for?
features.
the more the better until you end up with one that is not formalized at all.

"An engine is a machine that produces mechanical force and motion from another form of energy"
"An engine is a code that produces data from another form of data".
it's an encoder

[Mikademus]

if you browse for an engine, what is the first thing you search for?
features.

No. Features and solidity - both at the same time, neither over the other. And well-made, solid frameworks and engines tend to be well designed.

[Hajo]

I'd put a bias on solidity. If it's not stable, you'll be annoyed, and also your players will be annoyed. I'd imagine it's easier to kludge a missing feature than to fix an instable engine in the average case.

[jotapeh]

Personally, I look for robustness, speed and efficiency in my engines

And compact/conciseness. The more feature-packed they are, the more wary I am!

Still, a lightning fast engine with tons of features that is a quick download is something I would certainly consider

[encoder]

I'd put a bias on solidity. If it's not stable, you'll be annoyed, and also your players will be annoyed. I'd imagine it's easier to kludge a missing feature than to fix an instable engine in the average case.

solidity is a qualitative property. and therefore it is a basic criteria.
what good it is one feature or 100 if the game keeps crashing, or run slow for that mater.
that is why i did not include it. anyway, features market, speed dose not (only if it is very fast).

but if i recall formalization was my main focus

[salade]

It's pretty obvious what a good engine does: runs fast, is stable, works on multiple platforms with multiple system specs, easy to develop for, support for features, modable, good rendering pipeline, good scripting system, robust physics, strong networking, AI, particle effects...

Yet how does one make an engine that transcends this? what engines out there push some limit or idea of how we think about an engine? that is what (I hope) people start considering. Graphics are going to peak soon on this type of hardware, and games are pretty on top of physics and AI. We need to find a new way to think about game engines and how they will work. The only thing like this so far has been source (IMO) with it's modular distribution system. What else can engines do now? that is the question that is going to be central to the development of the engines that will ultimately replace the current industry mainstays (Unreal isn't gonna be king forever y'know.)

In indie terms, it would be really cool to have an engine that is pretty much what Monocle is supposed to be.

[encoder]

i think a good engine can be developed. but not by someone who has one focus or or to be more precise someone who just disregards a possible implementation.

maybe there is a way to do it in the indie community. don't really know. but games are to date considered one or the most complex pieces of software, coupled with the experience of indies, and a clear focus on the goal could lead to a good start.

and end up in vaporware. 

however there was a software i played with a while ago, it was named virtools or something. it's focus on modularity lead them to the concept of a behavioral engine. pretty impressive it was.

and still is, for that matter. http://www.3ds.com/products/3dvia/3dvia-virtools/

it was used for the creation of some of the titles. on feature which i have to point out is that you can spread the calculation of an algorithm across multiple frames thus have a very good control over (otherwise mediocre) performance.

[Mipe]

I find this topic interesting, since I am developing a roguelike in Ruby. I am basically reinventing the wheel, as I don't have any concrete coding experience. Using minimalistic library that handles the hardware interaction - Gosu - really helps, though I still have to implement everything else - input, display, game logic handling etc.

I've already rewritten the whole stuff a few times now, undergoing another rewrite right now. I still get stuck here and there without any clue or idea how to proceed.

Basically, I have a tileset image containing letters, I crop each of the letters into a hash of 256 letters. That hash is then read by the display engine, which is responsible for drawing everything. At first I had a simple one tile drawing method, which I called whenever I needed as well as used it in more complex methods (Text, TextInput etc.). However I found it quite overwhelming, moreover it wasn't very efficient.

So now I have an array the size of screen in tiles (64x48 of 16x16 tiles on 1024x768 screen, for example) and just update the cells with symbol (representing a letter or tile) and color values, while display engine only has to iterate through the array and draw tiles each tick. Moreover, I can choose when to draw and when not to draw. Now I just have to modify methods to directly alter the array instead of drawing to the screen individually. There'd be some exceptions, such as overlays and effects (take mouse pointer for example), but those can be drawn individually. Alternatively, cells could include more than one tile and just drawn on top of each other (different Z levels).

And that's just the display engine. I've implemented a rudimentary menu system, which I am not happy with, however I have little knowledge and experience. I probably should implement a state machine, but that thing tends to spin my head wild. Then there is input, I have a rudimentary implementation which I'm not happy with either. There is a constant, a long hash of key IDs (Gosu) and symbols (such as :enter, :esc, :W, :w, :tab etc.). In the current form, I have a loop that iterates through the hash and checks whether that particular key is pressed, then it adds the appropriate symbol into another hash, which tracks pressed keys (as well as released). I also have a handler which filters the keys through various devices, so that keys aren't used by out-of-context devices.

As you can see, I am still stuck working on the basic engine without actually touching the game itself. So yeah, reinventing the wheel over and over, but I feel this is a good learning experience. I dread the actual game engine; how would I handle game states, transitions, interface, logic, data?

For example, the game world would be procedurally generated; its regions would be seamlessly connected, so that your character could walk across the whole world without any interruptions. I'd have to handle loading and dumping regions in real time, based on proximity to the character. There is another issue related to that; there would be entities, which would act regardless of player's proximity. For example, an enemy faction conquering land while the player bums around, a megabeast roaming around the world etc.

Then there is the entity data, coming up with a basic model was painful enough as well as some kind of relation model. How to define skills and abilities? How to define items, equipment, ability to equip items? There is a lot of core stuff I have to define; I'd rather come up with a reliable model now rather than have to rewrite the WHOLE engine at a later time.

Then there is combat and other actions that the player and AI would take. I'm already overwhelmed now, can't wait when I get to pathfinding, FOV and AI implementations. *shudder*

This is really frustrating, but I've never enjoyed something more. Guess that's the charm of game development. 

So yes, please debate on - I am hoping to learn something that could help me make the whole process less painful and more convenient. I want to get to the actual game, damnit!