🔒 Locked

Game Modes

Started by Penance Oct 17, 2005 at 11:48 AM 1 replies 1k views

Original Post

Oct 17, 2005 at 11:48 AM

I'm writing a game library so I can quickly and easily put together new games. I'm trying to keep it as generic, loosely coupled, and well designed as possible on the off-chance that I need to show it to a company as resume padding, etc. I'm trying to black-box the Engine as much as possible. Under the hood it will have a stack of GameMode objects and the GameMode on top gets called to do whatever the designer has programmed it to do. My game loop within the Engine object will be something like: Gather User Input into a Queue Update any Engine-Internal Stuff (gametime, etc) Call GameMode (operates on game objects and state managed by the Engine) Clean-up I'm just wondering how best to allow the GameMode to interact with the Engine. I've had a few ideas: a)Give GameMode's an API object that exposes functions that operate on the Engine. (Kind of like an Adapter/Mediator pattern, I guess). b)Give GameMode's a callback function provided by the Engine that lets the GameMode request operations or data. ie: CallBack(GET_OBJECT_DATA, objectID, "health"); CallBack(PAUSE_GAME); etc. c)Give GameModes direct access to the Engine and have the Engine expose a crapload of public functions. Any other ideas? Your input is appreciated!!

Toolmaker

Oct 17, 2005 at 6:34 PM

Go for C. Why? Because you want your GameMode's to be able to interact as fast as possible with Engine class. Also, if you're talking about rendering, abstract it away from the engine, and have a Renderer class.

That way, you can have the Renderer implement all the code that concerns rendering, and keep the engine to do what it's suppose to do: Get things working seamlessly together.

Provide the Engine with components, such as InputManager, GameStack, etc.

Toolmaker

Penance

Oct 17, 2005 at 9:24 PM

Hey, thanks for the input!

I am already making sure that the GUI is completely separate from the engine. From the start I wanted the engine to be usable either locally or remotely, so I tried to keep it as close to a client-server model as possible.

What I want GameMode's to be able to do is handle all the logical stuff that a particular game might need to do without relying 100% on scripting. For example, a Tetris game might have a Setup Mode where you select the game type, starting level, and number of players.

Then it would push Play Mode onto the stack and that would do things like say "Hey, engine, what's the game time?" "Hey, engine, give me the position of game object #23" and then "Hey, engine, this is the new position of game object #23" Stuff like that.

In a nut shell, when someone uses my library I want them to include it, create an Engine, and then run their GameMode's on it. That's why I was thinking of using an API object to expose an interface, because from my perspective as a software engineer I don't think an end-user of the library should have to know anything about Engine itself, only the services it offers.

Again, thanks for the input, it'll give me more to think about =)

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.