Organizing tips for a complex, multi-level game?

I am getting ready to start an actual build of my game, "Psi." So far, I've been working on the beginning game mechanics and getting the look right. I have read everything I can find in these forums on keeping your project organized and here is some of what I've learned:

1. Put all of your sprites into 1 layout and spawn them as needed. I actually plan on using 2 layouts, one for Spriter objects and one for standard sprites.

2. Have your layers planned out ahead of time so you don't have to go change 50 layouts.

3. Have the different aspects of your game compartmentalized into different event sheets and attach them as needed. UI, HUD, Enemy AI, Player controls, etc.

4. It sounds like the best way to deal with the 40 levels of my game is put them on 40 layouts in a group, does this sound right?

Can anyone think of anything else to add? Does my plan sound solid? I want to make sure to start properly so I don't hit a wall halfway through. I also want to keep my project as simple as possible and running smoothly.

Thanks to everyone who helps out on these forums and on the site in general.

livingartgames.blogspot.com

Looks solid.

I use lots of groups for my event sheets, even if I do not need to turn them on or off.

Gives a great overview

You could look into checking at anything related through famlies, and wheter or not you need global variables, local variables, instance variables, or even webstorage.

I was a bit late with exeprimenting with families, and while developing several things some weeks ago I came to find enormous power in the use of families. Eliminating heaps of events and checks just by using a simple reference.

I've gone with this approach and it works out okay, but layers remain a big problem. There's an excellent chance you'll need to change your layers in the future, and that's increasingly difficult to do for a huge number of layouts.

Here's another approach:

-Have a separate project for "level building" and build your levels within that project, each on its own layout.

-Write a system for saving your levels to a file - this can be easy or hard depending on how your levels are constructed. A simple approach might simply save the position/name of each object, while a more complex one would incorporate things like tilemaps. Either way, make it so you can press a button to save (the Node Webkit object can help here), and save each level to a text format. If you need to change a level later, change it and then save it again.

-For your game itself, you can put all the game logic and layers onto a single layout. When the game starts or the player transitions levels, you can remove any existing objects and load in the new ones based on the content of your text file, placing all the objects as needed. That way, all the levels can be loaded onto one layout.

Note that this approach is good for certain types of games, and not so good for others. For example, if you need to save changes when transitioning levels (for example: an enemy you killed in a previous layout stays dead if you go back), it might make more sense to use the built in layout and persist behaviors rather than going this route.

This approach has worked for my game, so I thought I would throw it out there. It may or may not suit yours, it just depends on your mechanics.

Another tip: Make almost every variable a static local, and access them through functions if you need them elsewhere. Global variables clog up the drop down menu a lot once you have too many.

Cool tips for someone who is starting... all of you :)

Squidget - I see that you mention saving the levels as text objects. I saw that mentioned somewhere else the other day. Can you tell me some more specifics about the Node Webkit object? My levels are very simple and linear. The backgrounds are tile based (usually only involving 2 or 3 objects) with sprites over the top for variety.

They say that creating extra layers is a bitch down the road if you need them. What if you just added an unused layer to your layout that can be used for whatever, later?

One extra layer might be helpful, but I've found that I often need more. I'm building some pretty complex levels, so the freedom of being able to add multiple parallax layers or play freely with layer ordering has been pretty helpful.

As far as how I save the levels as text objects: My levels consist of two things, a base tileset object that represents the core terrain, and then a set of 'props' with X and Y positions that represent various game objects. So in my text file, I have to store the state of the tileset, and the name and coordinates of each prop.

In general, the key to this method is creating lists in the text file using separators, and making use of the tokenat function to break up the lists again when you load. I pretty much just choose random character as the separators, but I'll explain it as best I can! Here are my saving events:

<img src="http://i.imgur.com/1B9rOEN.png" border="0" />

I originally tried to save the tileset data using the AsJSON component, but I ran into a lot of bugs and couldn't make it work consistently. I don't recommend that approach. Instead, I save the tile data for the levels by looping through each tile and saving its number, then writing them to a string as a list, with a "." separator between each one. You can see this in the setupTileString function above: It loops through each tile and appends its value to the list. This is then saved into StringToSave. Once I've done this, I add another seperator (a "|"), so I can differentiate the tile data from the prop data.

For the props, I just add each possible prop to a family and give it an instance variable that represents the props name. Then I just loop through each prop in the list and save its name, as well as its X and Y components. Each prop is separated from the other props by a "?", and the data within each prop is separated by ";". You can refer to the code above to see exactly how the string is built. Props could be anything - enemies, items, background objects, whatever you need to have directly placed. Just make sure to give each one a unique name, as this will be important in the loading. You could also add more data parameters here, if you needed to save more about a prop than just its coordinates.

Once the strings are all saved, you write them to a file using the Node-Webkit object, as I've done above. Node webkit makes it very easy to save files using the Open Save Dialog and On Save Dialog OK features. If you look at the two events above it should be pretty clear how that's being done.

In the actual game, the level files are loaded in a similar way. The strings are broken up and separated out (you can do this using the tokenat and tokencount functions), the tilesets are rebuilt, and the props are created and placed based on their names. This is all done on one layout, so I never have to worry about layering issues or mirroring my changes. You can then create your individual levels in your level editor project, saving them as separate layouts, and putting all of the actual behavior in the main game project.

Again, this may not be the best method for every game. For various reasons, it was the best fit for my game, but I only settled on it after some experimentation. Depending on how your game is structured, using a layers/layouts approach might work better for you.

Squidget - thanks for sharing this info but I feel it's a bit beyond where I am and what I understand. I think I'll have to take a simpler approach for now.