Single-frame game design advice

[DavidN]

Hi everyone!

With Crystal Towers 2 out the way (again) I'm looking towards my next major project. After suffering through CT2's "one frame per level" design and copy-pasting events around, this time I want to be better about designing a game around a single frame, with levels/environments stored externally and a scripting language to define interactions with objects. I have a couple of experimental screenshots up here:

http://davidxn.tumblr.com/post/56731...ting-somewhere



It's working so far, but my concern is the need to have so many different objects and events in a single frame, to handle everything that's going to happen in the game. To anyone who has designed large games around single frames - are there any tips you can give about how to prevent the object/event lists from becoming unmanageable?

Thanks!

[Steven]

Hi David,

I just use a spreadsheet to keep track of everything. Try to be as frugal as you can with creating individual active objects. For instance, I've used one single AO for all my tile sprites, making use of the different directions and animations and the values corresponding to them are then stored in the array.

Steve

[Danny]

Hey David,

I have built many (most) of my engines and client engines purely using the one-frame method. I'm sure you're already aware of the doors it opens in terms of manageability and convenience. When it comes to managing stuff, it really depends on how well you code your level editor. I tend to work in reverse initially. I design and develop the level editor first (always handy for testing out levels early on) then start the engine development (with the ability to load up levels and test from the off). Both INI and Array are fine for the level loading, I would say Array is a preference over INI but each to their own.

Steven's tip is great, I do that myself. For backdrop objects, I use one Active and a whole host of animations/directions/frames. You could practically contain all your backdrop objects to a single active object as on level load, all you're effectively doing is selecting the animation/direction/frame and pasting it into the background.

I would steer well away from Global Events and try and steer away from Behaviours (only if possible). Having your engine contained to one-frame means you can use Qualifiers much more efficiently, labelled and you now have the added bonus of unlimited Global Values and Global Strings.

I could go on all day, there are so many avenues that will open up.

Here for answers to any questions!

[DavidN]

Thanks a lot - I'm using a single active with multiple animation frames to act as my background objects, and interactive items are also a single active that decides its appearance based on ID. Characters like the raccoon above are interactive objects that have a flag set that allows them to 'wander' a little, and a sprite on top that changes animations based on the invisible object's state.

I think my main concern is for setting up objects with a lot of complex interactivity (such as bosses, or cutscenes) - though I think that might be a test of the scripting language I'm inventing for the game.

[Outcast]

I also only develop in one frame now. It can easy be a bit "messy" and hard to navigate after a while though.

I have posted some suggestions in the bugbox for things that would make it a whole lot easier:
http://bugbox.clickteam.com/issues/3114
http://bugbox.clickteam.com/issues/3113

Btw, DavidN, you are not planning to do any dev videos for the new game? That would be really interesting to follow the creation of it

[BartekB]

I've made quite a lot of (unfinished) games that have single frame gameplay, I try to make everything structured perfectly so I don't have to clean it up afterwards.
That is, the events, objects, group qualifiers, and using as fewest actives as possible (For Printing tiles, I use an active with backdrop's images and paste it into a backdrop)

My game is at 400 events and that will double in the next few days, it is still manageable because I have everything in event groups:

[Outcast]

400 events seems very manable. My current project have 2000 events and will probably have at least 3000 once it is done :/

[Steven]

I think I'll be handling cutscenes in a separate frame as it will give me a lot more flexibility I think. Although it will make it more difficult as I'll need to re-create a dynamic level in a new frame... so we'll see.

Everything else will be in the one frame though.

[Danny]

Cutscenes could be handled in another frame, but displayed as a sub-app, that way, you don't have to re-render the level-load again upon frame switch...

[Steven]

Good thinking Batman.