9 replies to this topic

[starstutter]

Let me start off by saying that this is a very strange question and I'm not really even sure how to ask it.

Ive been coding 2D and 3D engines for a while now and I'm used to it. I've refined it pretty well into a coherent and mostly consistant form. I write small modules and components that are totally independant from eachother, but come together to make graphics/physics/sound/ect. However, I cant seem to apply that same style of coding to an actual game; where everything seems like it needs to connect or interact to work properly.

I know how to code games in the small scale, but the style I've used thus-far becomes so quickly clustered and buggy in a larger scope.

I just have so many questions like: where should I draw the "code line" between the game and the engine? Should I seperate the 2 code sections as much as possible OR interweave them (but probably the first one)? Should the game be coded in the same style as the engine OR use a completley different technique? For a private engine (self-made, not for sale), it is a waste of time to make everything file based vs hard-coded?

So, if at all possible, might someone be able to point me in the direction of a decent article, book or site of any kind that covers this topic? It seems like there's so many articles on how to write games or engines, but almost never any clarification on how to handle the 2 seperatley in large-scale.

Thanks in advance (if only for reading my confusing question).

[Reedbeta]

At least in my workplace, the distinction between engine and game is approximately equal to the distinction between C++ and our scripting language. The role of the engine is to provide general facilities that are not game-specific, such as loading a map, spawning a character, running a mission or a cutscene, etc. Most of the game-specific stuff is done using script.

To take the example of a mission: our engine has a Mission object that is exposed to the script. Properties and functions on the Mission object provide various general features, such as checkpoints, loading in mission-specific characters and props from disk, running dialogue sequences and musical numbers, etc. To add a mission to the game, the game designer creates a mission object and then writes a script on it. The script handles all of the details of the particular mission, calling upon capabilities of the mission object to do so. For instance, the script might say "load characters X and Y; spawn 5 enemies at location Z; wait till the player has defeated them all; play cutscene 47; etc."

Another example is our UI menus, for which the navigation and logic is implemented entirely in script. Of course, the engine exposes some needed functionality to the script; for instance, there's a function to turn subtitles on or off, which the menu script calls if the user selects that option.

That being said, we generally build engine features on an as-needed basis. So, we only add a feature to the engine if we are pretty sure we need it for something we plan to do in the game. Moreover, some game-specific features are pervasive enough that it would be incredibly cumbersome or slow to do it in script. In that case we implement the feature in the engine. However, we still try to keep the engine feature somewhat general. As an example from Infamous, many particle systems change depending on the player's karma - most obviously in their color (blue for good, red for evil) but also in other properties. While this could have been done in script, it would be far too cumbersome to write a script on every particle system that needed to change to track the player's karma. So we added a feature in the toolchain/engine for the FX guys to define two sets of properties when they authored the particle system, and it would switch between them automatically based on the player's karma.

Now, your personal engine may not have a scripting capability. But even if it doesn't, the same sort of distinction between game and engine can still make sense. Think of the engine as providing both (a) an environment in which to run game code (our scripts are mostly in the form of event handlers attached to specific objects in the game world) and ( a library of useful functionality for game code to call upon, allowing it to manipulate the game world and state.

Of course, with a scripting language you have to explicitly expose any engine functionality you want the script to be able to use, which forces you to think about how you want the engine/game interface to be structured. If the game code is in the same language as the engine, it's easier to lose control of that interface and get the two too closely coupled. One way to avoid this might be to keep the game code in a separate DLL; then you get most of the benefits of the explicit interface again.

Anyway, I hope this long and somewhat rambling post helps address your question...

[starstutter]

Well it most definitley gave me a better search parameter (coding vs scripting) and appreciate the help. I guess the thing Im looking for is really more related to making the game "work" in the first place.

As an example question: where do the first (or third) person player controls go? In the engine or the script? I know thats a relativley petty question, but thats just the nature of the kinds of things Im wondering.

I suppose one of my main problems is that, when I used to hack every single line of code I wrote, it was easy to make small simple games quickly. Obviously the project always turned into a buggy hunk-o-crap past the small to mid scale, but the point is I could actually make them in the first place. Now that Im hung up on "elegance" Im finding it much harder to just create playable games. I find myself struggling to find the right spot for the players' code and how that ties in with the rest of the world.

One thing I just realized from reading your post is that I am now in the habbit of making everything as general and re-usable as possible, so its difficult for me now to write anything that is for one purpose, and one purpose alone.

*sigh*
I'm suddenly getting this feeling that I'm going through one of the many "programmer phases" :|

[Reedbeta]

In our case, the player controls are part of the engine. The basic controls (running, jumping, aiming and firing) could probably be done in script fairly reasonably; we'd have a script on the player character that would start a thread running to poll the controller and activate animations to make the character respond appropriately.

Where it would get a bit trickier is with things that are sensitive to spatial context. For instance, when the character runs into a wall they can no longer walk forward, and we don't want them to just play their walking animation in place, either. So here we have to integrate information from the physics system into our decision of how to animate the character. The parkour (climbing) mechanic is another example of this, as is pressing circle to take cover. All these depend on accessing spatial data structures to examine the environment around the character, and it would probably be too cumbersome and inefficient to do it in script, so it's easier to keep it in the engine.

[fireside]

All I've done are small games with engines, but for me object oriented methods are the best way to organize and develop a game. I start with an Actor class, which is anything that moves, and then build classes over that. It makes it very easy to expand without the thing turning into a nightmare. The static parts of the world are normally taken care of by the engine and it has a scene manager for collision testing, etc. The thing to be careful about is threading. It's best to do most of the actual work in the game loop and use as many statics as possible in the classes. The other nice thing about it is everything is reusable up to the actor class.

[starstutter]

hmm, Ill have to give this more thought. Thanks for all the help so far. I think what I need to do is really just sit down and design the whole thing out before I code anything. I mainly want to avoid writing the whole architecture twice (although that will probably happen anyway).

[rouncer]

When your right up to making the game, its all ai from then onwards.

Keeping things simple, base everything around an actor class, just like fireside said... its a good way to simplify how a game usually operates.
If you just take what fireside said, go to notepad, you should be able to figure the rest out yourself.
the ai needs functions to talk to the engine with, like get near actors, get colliding actors, get map collisions, collision detection gets you through a lot of situational problems.

The functions give the script "eyes" without special functions to call from the ai, you couldnt tell what was happening in the game.

you could hard code it into the exe, or you could develop an interpreted scripting system if you want to do it more pro.
But a cool thing that people have developed is re-pluggable ai, its come up a few times here on this site.
Basicly it means you have generic ai, and you can have specific "mission" ai that plugs into a spare pointer and gets the actors to do things specific the situation in the game, and thats what makes all the hard to code things possible.

So its just a scripting system, that communicates with the engine via functions, and its all ai.

You should be proud of your script, because it can handle any situation you could imagine and its complete and needent be recoded.

Me personally, i would put the camera controls and fps movement in the main player actor script. It would work fine from there.

[SyntaxError]

My strategy is ..... Don't worry about it too much :-) ... Ok so it's a bit more complex than that. I put a modicum of thought into design up front and then take my best shot. However I know in advance I'm never going to get it perfect the first time and I will have to rework module interfaces in many cases. This strategy probably works best if you are not working in a large team where your changes will affect everyone else. On the other hand it keeps you moving forward and getting results which I find is paramount in keeping your motivation up when working on your own.

[starstutter]

SyntaxError said:

On the other hand it keeps you moving forward and getting results which I find is paramount in keeping your motivation up when working on your own.

Which I am :)
Thanks for the thoughts

[Dim_Yimma_H]

For personal games, I think game-specific callbacks work pretty nicely, i.e. defining a callback "template" in the engine: For maybe input event, character colliding with obstacle, character moving into spatial trigger, AI finished a task, and so on.

Then the callback implementations can be defined in a separate "game module" and the nice property is that the callback functions aren't related with each other - so buggy spaghetti connections can be avoided.

Especially spatial triggers can be useful, because the event in the game module they trigger can load resources, maps, more characters on the fly (by invoking the engine to do the "pieces")

That way the game code can be kept separate from the engine without having to bind scripts everywhere, and be debugged using the native language debugger too.