next »

[TheLastBanana]

Latest (Version 1.0)

Well, it's finally done! I've been working on it since last September, and Dauss has been helping out for... I dunno, most of that span. Major thanks to Felix for doing music for us - send him an email if you like his work:
arifin[dot]felix[at]gmail.com

THE GAME





Your goal in this game is to get the plant to the teleporter at the end of the level without breaking it.  Your tool for doing so is the ability to change gravity, making everything in the level falls with it.  This means your plant is at the mercy of being crushed or falling too far (and in the future, there will of course be more devices to destroy your beloved greenery).
In terms of story, you're a new member of the crew for a cosmonaut space project.  Your job is to transport plants to testing chambers throughout the ship without contaminating them with human hands - hence the gravity changing.  Throughout the story the USSR and US are constantly trying to one-up each other.  Hilarity ensues.

WHAT'S IN IT NOW?
The game has 25 levels, complete with dialogue, music and cutscenes.
Another feature of the game is that it can load objects dynamically.  If you go into the "Modules" folder, you'll find a folder called "Main".  Inside there, everything is defined.  Poke through the code a bit, it's fairly straightforward.  This system makes it really easy to add in new objects for levels, and you can add in your own module by making your own folder within the "Modules" folder and giving it an "Include.ini" that defines what it should load.
If you're interested in making levels, the documentation is right here, and is also included in the game.
The Play button leads to the game itself.  The controls are arrow keys to change gravity, Space to pause (although it isn't all that useful) and R to restart.  You can advance dialogue with C, and skip an entire cutscene with Space.  Controls are customizable in the settings menu.  If you get par on a level, it'll be outlined in yellow, so if you want more of a challenge, try to do levels in less turns.

Next is the Level Editor, with which you can play around with the objects in the game.  The buttons do the following (from left to right):

• Left/right arrows - cycle through modules and objects within modules.
• Save - Saves the level to NewLevel.ini in the main folder.
• Center - Centers everything while maintaining a 24x24 grid.
• Clean up - removes any objects that are over top of another object (useful if you accidentally clicked twice in one spot)
• Test - Saves the level, then loads it for play.
• Load - Loads a level for editing.
• Link - Links e.g. a button and a door.  Click the output first (usually a button) then the input (usually a door).
• Preview - Takes a resized snapshot of the level and saves it to Preview.bmp in the Gravity Garden folder.  Useful for making previews of your level.

OTHER STUFF
Feel free to share your levels and objects (although I'm not sure what the policy for posting within others' DevLogs is here).  I'm entirely building this engine from scratch aside from using SDL as a media layer, so I expect a lot of bugs - please let me know if you encounter them.

ARCHIVE

• ReGrav
  
  • Game Maker version of this same concept from quite a while ago.
• Version 0.1 - May 2nd, 2010 @ 6:36 Mountain Time
  
  • First version
• Version 0.1.1 - May 2nd, 2010 @ 9:23 Mountain Time
  
  • Fixed a crash in the level editor when a module is empty
  • Added level select screen
• Version 0.2 - May 4th, 2010 @ 10:02 Mountain Time
  
  • Added "Entity" class that can be used as background/foreground images
  • Added ability to load a musical theme for a level
    
  • Fixed some level editor tools
• Version 0.3 - May 5th, 2010 @ 8:40 Mountain Time
  
  • Fixed a level loading bug
  • Redid level file format to be smaller
  • Added a back bar to the editor to keep buttons/text visible
• Version 0.4 - May 8th, 2010 @ 6:22 Mountain Time
  
  • Made the main menu look nicer
  • Redid rendering code to deal with depth better
  • Migrated menu code into their own classes
• Version 0.5 - May 13th, 2010 @ 11:08 Mountain Time
  
  • Fixed some collision detection problems
  • Added buttons, doors and linking
  • Added variable for rotation in level declaration
  • Decreased level editor grid to 12x12 instead of 24x24 for more precision
• Version 0.5.1 - May 14th, 2010 @ 8:01 Mountain Time
  
  • Fixed a level exit collision error
• Version 0.5.2 - May 14th, 2010 @ 11:21 Mountain Time
  
  • Fixed a memory leak
  • Fixed a bug where an object falling off the level would stop you from progressing
• Version 0.5.3 - May 16th, 2010 @ 10:28 Mountain Time
  
  • Fixed another memory leak
  • Added a few more levels
  • Added more buttons and doors
  • Doors can now be jammed open with an object
• Version 0.5.4 - May 16th, 2010 @ 9:55 Mountain Time
  
  • Added a cushioning variable for BreakablePOs to negate fall damage, as well as a new object for it.
  • Added DirChanger object type, which can change a single object's gravity.
• Version 0.9 - July 22nd, 2010 @ 3:48 Mountain Time
  
  • Added more levels.  At this point there are 18.
  • Added Dialog class, which allows spoken text when events are triggered.
  • Added dialogue to every level in-game.
  • Added a variable to keep buttons down once they've been pressed.
  • Added variables that allow BreakablePOs to change their collision box once broken.
  • Added a proper level select menu.
  • Added music for every level in the game.
  • Changed the GUI's look to something a little more communist.
  • Changed the weight system so stacked items count.
  • Fixed countless bugs.

• Version 1.0 - December 3rd, 2010 @ 11:27 Mountain Time
  
  • Game finished! More changes than I could keep track of.

[mokesmoe]

Your "Here's a link to the gamemaker version" link is broken.

Seems really cool, like the graphics.

[TheLastBanana]

Oops, apparently I was linking to http://here's a link to the Game Maker version.  Fixed that up.
I'm actually kind of surprised, I've heard from a few people now that they like the graphics.  I'm planning on having somebody who's way better at pixel art than I am doing the graphics for the game, but it'll probably be in a similar style.

[Tycho Brahe]

awesome, it reminds me a lot of the boulder pushing puzzles in pokemon games, which is not a bad thing!

However, the graphics in the game maker version are radically different to the ones in your post, which I think i prefer more...

[TheLastBanana]

Hmm, maybe I need to make it more clear in the post.  The Game Maker version is an old version of this.  I'm redoing it in C++, and there's a download for the new one at the bottom of the page, which has those new graphics I showed in the screenshot.  I'll switch the two around so there's no more confusion.

[Tycho Brahe]

Ahh! much prettier. I had a look at your level file as well, and you might want to find a simpler way of storing level data if you don't want to end up with a massive download.

[TheLastBanana]

Any thoughts on how I could trim it down while keeping it data-driven?  I want to keep it human-readable, and able to support objects people add into the game themselves.

[Tycho Brahe]

I suppose the main thing is that you have every entity as being something like

Object {
 type = data
 name = data
 x = data
 y = data
}

when you should be able to trim it down to something like:

type(x,y)

and let the program do the work for how to parse it.

or even, as you've got a very tile based game you could go the whole hog and do a tile specific map format like this:

Code:

//metadata, like map width and height
width = 8
height = 8
gravity = 1 //starting orientation of gravity

//actual map data, with 1 being a filled block and 0 being an empty one, this can be modified to allow any number of different block or entity types.
data{
1,1,1,1,1,1,1,1,
1,0,0,0,0,1,1,1,
1,0,0,0,0,1,1,1,
1,0,1,1,1,1,1,1,
1,0,0,0,0,0,0,1,
1,1,1,0,0,0,0,1,
1,1,1,0,0,0,0,1,
1,1,1,1,1,1,1,1
}

whatever you do I'd recommend at taking a look at the ways other games structure their level files, I'm not the expert.

[TheLastBanana]

Well, the tile-based approach probably isn't possible, as the game loads everything dynamically, so attributing a number to it, while possible, will make it difficult for others to design levels in the long run.  Assuming I did it with strings, it would cut back a bit on how custom levels can be made (although that's a trade-off I may be willing to make.
Each object has a type, a name, and an x and y coordinate.  In the future, in order to, for instance, link buttons to doors, I'll need another variable there.  There's enough variables to cover that I felt they needed separate lines.
Just for the sake of testing, I tried filling a level fully with blocks, which would represent a full level pretty well.  The file size was 63 KB.  I ask this, no sarcasm intended, do you think that's too big?  I'm not really sure what would qualify as too large a size for a level.
Sorry if it sounds like I'm defending or anything, I'm really just trying to be as objective on this as possible.  This was an issue I had been thinking of for a while before I implemented the level loading, so I'm interested to see any thoughts you have on how I can improve it.

EDIT: Maybe something like this could work?  It does halve the file size for the test level.
Add: [BreakablePO] Main/Block B @ 216, 120

EDIT EDIT: Okay, I changed it over to that format.  Thanks for the suggestion, 14113.

[Tycho Brahe]

hmm, I suppose 64 kb isn't really that much. I like your new method better actually, especially as it seems to involve less typing for each block, something which I'm sure people hand editing levels would enjoy.

[TheLastBanana]

So the latest update is making the game look a little less like a tech demo, which is nice.  I'm not entirely sure this will be what the final menu will look like, but at least it's better than just a white background.  Any suggestions on what I can change?

[TheLastBanana]

No update today, but I thought I'd update on what the next feature I'm implementing is.
Now that I've got the rest of the basics down, it's time to start putting in more item types for more interesting levels.  First up is the button.

If you tried out the Game Maker version, it was only ever tied to doors.  However, I'm thinking this is going to be more of a multi-purpose thing now that I've got ultimate control of the level editor.  So, I added a new button to the editor:

The "link" button is a helper for linking two objects together.  You click the button, and then the first object you click will be the output.  The second object you click will be the input.  In terms of the actual level editor syntax it shows up like this:

Code:

Link  (a) -> (b)

This is on the end of the object declaration, which I described in one of my previous posts.
You can replace "a" with a unique name ID that will identify the object.  You can replace "b" with the object identifier that it should get input from.  Of course, different object types will get different kinds of input, but hopefully this linking system will be versatile enough to support more objects as I add them in.

[TheLastBanana]

After some more fiddling, the new version is up.  I remade almost all of the levels from the original version, excluding the "inverse zone" and first level, as I don't think I'll be including them in this version of the game.
This means that the game is now beyond its predecessor by a significant amount.  Now it's time to start building levels and make a full game out of this
I've been noticing some crashes with the level editor when testing a large level - it seems to save all data except for one object and crash, and usually happens when the level includes buttons.  If anybody else actually uses the level editor and ends up experiencing this, please let me know and send me a copy of the level so I can try to replicate the bug.

[Mincus]

Is anything supposed to happen after completing a level? I was moving to the next level by hitting escape then going back to the level select screen.

I found a bug on Level 4: Doing the following replicates it.
w, d, s, d, s, a, s
At this point whenever you hit w the exit flashes and the 'completed' sound is made.
Pressing s then w again will cause it to happen again.

[TheLastBanana]

Yeah, I haven't put something in to automatically go to the next level yet.  I'll be putting that in once I've got some more levels together.
Also, thanks for that bug report.  It's a problem with the way I'm doing collision detection, so it will be an easy fix to just decrease the exit's hitbox.

[TheLastBanana]

So, having now overcome an embarrassing amount of memory leaks, I can say that I think I'm getting a bit better at managing code in C++.  A lot of my functions and classes have evolved into more sophisticated creatures since their original conception, and it's nice that they're starting to work together a bit better.  Now it's time to really start cranking out levels and new object types, as most of the engine work is done.

[TheLastBanana]

Today I added in object cushioning and a new mattress block:

These can negate fall damage in varying degrees using the "Cushioning" variable in any BreakablePO.  Fall damage in the game is measured in how many pixels something has fallen without touching ground, so that's also how the cushioning is measured.
Next is the DirChanger class, which (surprise) changes something's direction:

This can be relative to its current direction, or constant.
Both of these could lead to some interesting level designs.  Speaking of which, a friend of mine is now working on levels, and we've got a Dropbox folder set up to share everything, so if all goes well the levels will start pouring in.

[TheLastBanana]

So I finally got some documentation on how the data-driven file loading works.  If you're interested in making levels for the game (or for your own use), take a gander.

[TheLastBanana]

I've been puzzling for a while over how slow it is to start levels.  Also, in the level editor, it seems to take longer to switch to a level exit than anything else.  I did some snooping, and I found the source of my problem: apparently, I've been loading sprites and sounds as they're needed rather than storing them when the game first loads.  So, in order to decrease load times, I switched it to work the other way around.
Now, this does mean the game takes longer when it starts up, and it also means that it will take up more memory, depending on how many modules are installed.  I think this is a fair trade-off, though, as it makes level editing and testing much easier and it means you don't constantly have to wait whenever you restart a level.

[TheLastBanana]

It's been a while since I've updated this, so I figure it's worth throwing in an update on how things are going.
Thanks to some fine suggestions by my buddy (and level designer) Dauss, we've come to a decision on what we're going to do in terms of storyline.  The game will be revolving around a cosmonaut, in charge of maintaining the People's Growing Operations, which are located on a rickety space station.  Throughout the game, there will be various bits of dialog with the Americans, who are constantly trying to one-up the Russians.  In the end this ends in a bit of a catastrophic way, but we'll get to that later.
In other news, also thanks to Dauss, the game will be featuring some music in the next version.  In fact, it sounds like we may even have a track for every single level in the game.  I totally didn't expect this, and frankly I'm surprised to have music for this so early, but it's great to have one less thing to worry about.
The next update will probably come around once I've got a proper level select screen ready and we've worked out all the bugs in the current version.  I've been bugfixing like crazy, so hopefully the next version will be much more stable and work better in general.