Basic Game FrameWork or Theory.

[Chesso]

Does anyone have a basic framework or theory, on where a game should start programitically.

Like, how you handle the states (menu, pause, level 1, level 2 blah blah), how you work timing out? (for example if I drawn an intro with some animation and at a certain point during this intro, you want to change an animation and make it start moving around like a jump or something).

Just things like that, iv'e never been able to make a nice clean and solid beginning and the one I have right now is mostly for experimentation and messing around as it's very messy :P.

[WILL]

Hi Chesso, I'd like to aks you to post in the appropreate categories relating to your topic. You are sort of jumpping around and posting everywhere. This does not make for good forum practice as it makes relivent material hard to find and makes a mess of other categories with information that does not belong there.

I have moved this thread to the appropreate category for it's subject matter, but please next time take more care with where you create a new post. Thank you. :)

[Chesso]

Well I'm using Omega, and having information pertaining to the question that is relavent to this package would be more usefull?

Doesn't seem like Omega is used too much though, (it seems pretty good so far though).

[cairnswm]

I'm a great fan of Frameworks for doing rapid game development. I've even done presentations on using frameworks for games :). I do however believe that each persons requirements in a framework are different.

In the Dev.Mag (see my sig) I have had a series of articles about the value of frameworks and how to put them together. The latest article (due out soon) is about making a state management system for your framework.

My S2DL set of JEDI SDL wrappers is in itself a framework designed to make writing games easier - but its not well documented for it yet.

[WILL]

I realize that often a topic will bleed into another, but in this case it seems that what you really want is here anyhow. No matter whatever way you design your framework, Omega plays very little if any factor in it.

True be told, Omega and other libraires like it will mostly only manage your game engine's 'extremities'. The core functionality and real meat of your game will be completely of your design no matter what libraries you use.

Besides that is how you can tell the difference between a good and bad library. A good one will be very modular and have the least amount of requirements to be used. A 'bad' one will have many unnessissary requirements and be far less interchangable. This however is not so in the case of 'helper' libraries such as say SX Media where it was designed to be an add-on for DelphiX. But in the end really it's based on context. :)


Anyhoo since what you really want to know fits here I've not moved it, but just please consider PGD's category system in the future. Thanks. ;)


cairnswm: I noticed Issue 9 is out. Very nice... I'll be reading tomorrow. :thumbup:

[Chesso]

Yeah at the moment i'm looking for theories on how to approach building a base, say for a 2d platformer (no scrolling to begin with, fixed screen).

Like ummm, hmmmmm:

How to handle the different screens (like game states is a byle value I use to determine what screen to draw, hmm but what to do about one time initalization and de-initlization at the start and end of every *scene* or *game state*?).

Another thing is time, how could I go about handling this, you may have levels with monsters and things that trigger based on events, but what about things that are time based, like a message explaining the level to appear a few seconds after the scene begins, etc.

Iv'e had problems with running more than one timer at once, so using multiple ones is probably not a good idea, so how?

[cairnswm]

How to handle the different screens (like game states is a byle value I use to determine what screen to draw, hmm but what to do about one time initalization and de-initlization at the start and end of every *scene* or *game state*?).

My article in DevMag no 9 is exactly about various ways to handle different game states.

There are two basic ways:
1. Keep statemanagement as part of the Game Loop - something like a case ststement that defines which methods get caled based on the current state. This is nice when multiple states use the same input or sound routines
2. Create a state class for each different state. Using inheritence you link a base class and call the Draw, Input, Update or Sound functions. The relevant method will be called using polymorphism.


Another thing is time, how could I go about handling this, you may have levels with monsters and things that trigger based on events, but what about things that are time based, like a message explaining the level to appear a few seconds after the scene begins, etc.

Iv'e had problems with running more than one timer at once, so using multiple ones is probably not a good idea, so how?

There is no reason why you cannot keep a timeline going within the game. Instead of using a trigger mechanism based on a certain time elapsed, predefine a structure that records when you want an event to trigger and keep deducting time from it. When it hits 0 then trigger the event.

My prefered way to do it is to store an array of predefined events along with a time value. Each pass through the game loop I check the events to see if the time has elapsed and then trigger it.[/quote]

[Chesso]

Hmm, perhaps concerning level based games and such, using external data to define this would be better and create a parser for it.

So when a level loads, it can store what needs to be done instead of having it all hard coded in all nice and messy heh heh (well there are other ways).

[cairnswm]

Even better - have a AI script file per level that contains custom events per level. I've used DWS for this before.

[jdarling]

As cairnswm said, there are quite a few good articles on this. I haven't read cairnswm's version on the subject (downloading as I type), but I found http://www.ai-junkie.com/architecture/state_driven/tut_state1.html version to be very good.

As for scripting languages, search the site for DWS, "Pascal for Delphi" and Lua. You will find LOTS of information. Personally, I'm a Lua backer. This is due to the number of games on the market that have made Lua a popular scripting language. DWS or PfD are very niche if you plan of having user editable content.

JavaScript via Monkey is another good solution, but I have yet to see anyone integrate it into a Pascal based game or game engine. Its also slower then all of the above listed engines.

[Chesso]

Heh, heh, heh.

I know how to create my own for a given task, I prefer to do as much as I can without a third party library, Iv'e experimented with this before and works reasonable enough :P.