Back to the Maze - 4 - Hey, it Works!

Hello again!

I wasn't expecting it to go so smoothly, but I got AMAZE's rewrite to a point where it mostly works. At the very least, every level is fully playable at this point so I feel happy enough calling Stage 2 of my plan a success (and in just a month and a half, if you ignore how long it took me to sit down and write this)

But how did I do it? Let's talk strategy:

1 - Data

My original goal for this stage of the project was to get the games final data files loading and running in the new engine, but I very quickly abandoned that idea in favor of loading the source files instead.

The main benefit of this change was greatly simplifying the asset loading process. Instead of handling custom compressed binary files, I just had to deal with simple text and xml. Many of these files were similar to existing formats in DFGame, so loading them was pretty easy.

2 - The Critical Path

I thought a lot about how to approach the problem of recreating the game, but in the end I decided to simply play through it. By visiting every level, I could implement just the parts that were necessary to make the game function and ignore the rest, which was another good speed boost.

3 - Writing Bad Code

I think terrible code is underrated. No-one wants it in their codebase and it has a very high maintenance cost, but ignoring quality allows for lightning-fast initial development speeds. Even at work, I usually start by hacking together the "naive solution" to quickly get a prototype in place that I can then redesign to better fit with existing systems.

I applied the same concept here. Since I'm already planning months of cleanup, polish, and refactoring, I just wrote the cheapest possible recreation of the original I could. I'll be paying that debt back soon, but I'll be doing it with the luxury of a working copy.

Like a finely-aged...steak

Since I had to play through the game for testing, I can also give a verdict on the original content! I hadn't touched this thing in forever, so I came in totally fresh. And let me tell you, it sucks!

I remembered that the game was lacking in polish and some challenges were too tight, but but the latter was much worse than expected. Looking back, I think there are two even bigger problems:

1. Minimal Checkpointing - AMAZE is sort of a hybrid action/puzzle game, but there are no in-level checkpoints. Replaying an action sequence isn't too bad, but following the same steps to complete a puzzle after dying feels pretty bad. (The fact that resetting a level when stuck costs a life is also bad)
   Additionally, running out of lives is very easy and a game over can push the player back pretty far.
2. Blindness - A lot of puzzles suffer from not showing the player enough in-game. This becomes especially obvious in some later areas, especially with ice puzzles. There are multiple places where the player has to run into areas full of deathtraps, completely blind!

Naturally, the result is a really un-fun game. If I want to make the new game a success, I need to keep these points in mind.

Planning My Approach

As you may remember, the next two stages are about refactoring the new code into something solid, and building tools to produce the new data. Before I can do that, I need a better idea of what to do with this game.

With that in mind, I'm taking a break from the project for a little while. Now that I have it running with newer libraries I can worry a little less about compatibility (though I don't plan to stop long enough for that to be an issue), so I'm going to spend some time on a few other projects and come back to this with some fresh ideas later.

My next post be about one of those projects, which is already released!
Stay tuned.

Back to the Maze - 2 - Setting Our Sights

I had my fun in the last post, now it's time to get a little more serious. If I want this project to be successful, I need to plan a little in advance.

What Do I Want?

Before jumping deciding into this project, I think it's worth stepping back and deciding if I really want to do this. In this case, it's not actually a hard decision to back up. I was never really content with how the game wound up the first time around, that much is made clear by the release and postmortem. I've toyed with the idea of remaking the game for several years, but it never really felt like the right time. With Halberd shuttered, my slate is now pretty clean.

My drive here is pretty simple. I think AMAZE was a fun concept, but the execution was really lacking. With my vastly improved programming and art skills, I think I'm in a good position to do it justice. That informs my goal:

"Take the original concept of AMAZE, and turn it into a fun and polished result"

About the Project

Overall, AMAZE is actually on the smaller end. At almost 4kloc it's slightly bigger than Cloudy Climb, but dwarfed by Halberd and DFGame. Besides the antique rendering, it has a few odd quirks:

• A custom scripting language, which looks like this:
  Component Physics yvel 0
  Component Physics xvel 2
  Wait 48
  Component Physics xvel 0
  Component Physics yvel 2
  Wait 48
  Component Physics yvel 0
  Component Physics xvel -2
  Wait 48
  Component Physics xvel 0
  Component Physics yvel -2
  Wait 48
  Repeat 
• And yes, those times are measured in frames
• A data-driven pseudo-ECS, but with (originally) no concept 'prefabs'. Besides some later parts of the project, every object in every level was made by hand.
• And where prefabs were made, the files looked like this:
  Body
  0 4 0 0
  Collide
  ?P Kill . !c Info solid false = Destroy .
  Sprite
  Obstacle.spa:Cannonball
• A sprite format that looks rather similar to DFGame's, but with separate images per-frame instead of spritesheets. This was the original prototype that eventually led to DFGame's (improved) sprite assets.
• My first ever attempt at graphical development tools, in the form of a simple asset exporter. This was needed, because the asset format is compressed binary for some reason.

Baby Steps

Starting over completely from scratch doesn't seem like a great idea. Instead, my current plan is to handle this remake in stages:

1. Mockups
2. Recreate the engine, and get the original game's data working in it
3. Upgrade the engine, adding features and replacing the godawful custom scripting language with something sane
4. Build simple development tools, validate them by remastering the original game's content with new assets
5. Build a better game with the result, and include the redone original levels as a fun little bit of side content

This is a fair bit of work, but I'm optimistic because it's broken up into concrete sub-projects with well-defined endpoints. If I ever get tired of the project, I can just wrap up the stage that I'm on and set it aside for a while.

Looking Deeper

Just making a list is all well and good, but I think it would be good practice to try and predict the future. My predictions are often wrong and I don't believe in ship dates, but it might be interesting to compare predictions with reality as I progress.

Mockups

As I mentioned in part 1, this all sprung from a desire for mockups. Since that was my original goal, it stands to reason that I should do that first. This is a simple art project, so there's no real risk here. I expect a couple weeks of work for a couple simple mockups, and judging by the original screenshots there's a solid guarantee of improvement regardless of what I do here.

Time estimate: 1-3 weeks

Recreate the Engine

This is an interesting one. Given that I'm changing language and underlying APIs, it's safe to say that I'm going to have to commit to a full rewrite. On the other hand, I don't have to worry about tools, exporters, or asset creation. In the old codebase, that's a modest 2.5kloc and I have a spec to build against.

On a third hand, there's one possible stumbling block: Asset loading. AMAZE had fully custom binary asset files (because of course it did), and I'll have to translate those into some DFGame equivalent when loading. This, combined with a custom scripting language and nonsense code, could create some problems. Just to be safe, I think it's worth padding this figure.

Time estimate: 3 1/2months

Beyond the initial engine rewrite, I'm not confident in any predictions. Stage 3 could last forever if I kept adding features, and beyond that requires more design and scope considerations. Still, what I've looked at here feels like enough to wrap up most of the year.

I haven't yet decided how I want to handle this project from a blogging standpoint. I know for certain that I'll be capping off each stage with a post, but I haven't yet worked out how much I want to do in-between. We'll see when we get there.

Next Time: Actual Real Progress

Back to the Maze - 1 - TERROR AND MADNESS

I think it's about time for another video game. In the spirit of last year's Cloudy Climb remake, why not take another of my old games out for a spin? Why not, say, AMAZE?

What could go wrong?

And So It Began

It all started innocently enough: A certain art community that I'm in announced an activity about re-drawing an old piece of work. Just for fun, I thought I'd grab a screenshot of AMAZE and make a mockup in my style. However, AMAZE doesn't really work anymore. The Linux build compiles, but the old renderer doesn't, err, render.

The Windows build fared a little better in Wine, but crashes frequently. I can't really blame Wine for this, I'm not entirely convinced that the game is crash-free under normal circumstances...

Foolishly, I began to think: "Man, I wonder what that drawing code looks like? Maybe it's a simple issue, I'll bump up the OpenGL version and we'll be all set."

As it turns out, the game is running OpenGL 2.1's fixed-function pipeline. For the unaware, OpenGL 2.1 is roughly 13 years old at this point, which is very interesting considering that AMAZE is only 5.

Delving Deeper

So, ok, maybe the rendering code is unsalvageable. You win some, you lose some. However, I thought it might be fun to poke around the rest of the codebase and see how I used to write code.

After all, why not take a fine trip down memory lane?

   23 class Game{
   24  public:
   25   Game();
   26   void loadspr(string s){Sprite spr = spriteLoader.load(s); sprites.insert(pair<string, Sprite>(spr.id, spr));}
   27   Sprite* get_sprite(string s){return &(sprites[s]);}
   28   void frameStep();
   29   void gameLoop();
   30   void end();
   31   bool get_keydown(byte key){return keys[key];}
   32   MapLoader* get_map(){return &maploader;}
   33   float camera_x = 0;
   34   bool camera_xlock = false;
   35   float camera_y = 0;
   36   bool camera_ylock = false;
   37   float camera_xscale = 1;
   38   float camera_yscale = 1;
   39   void drawText(float xpos, float ypos, SpriteFont f, string text);
   40   unsigned score = 0, level_score = 0, hub_score = 0;
   41   unsigned equipment = 0;
   42   float equipment_percentage = 0;
   43   unsigned lives = 3;
   44   unsigned max_lives = 3;
   45   unsigned hub_max_lives = 3;
   46   game_states gamestate = SPLASH;
   47   float splash_alpha = -1;
   48   float splash_timer = 30;
   49   string disptext = "";
   50   vector<c_CResponse*> active_scripts;
   51   vector<int> script_positions;
   52   vector<int> script_timers;
   53   vector<pair<int, int>> script_args;
   54   void updateScript(c_CResponse* script, int& position, int& timer, pair<int, int> arg);
   55   ScriptLoader scripts;
   56   unsigned disptxttimer = 0;
   57   bool keys[5] = {false, false, false, false, false};
   58   int menu_select = 0;
   59   string hub_level = "Z1-Beginning.rma";
   60   string hub_tileset = "Tutorial_tiles.tla";
   61   string hub_song = "/TitleMusic.ogg";
   62   string current_song = "/TitleMusic.ogg";
   63   int hub_progress = 0;
   64   map<string, ALLEGRO_SAMPLE*> sounds;
   65   bool scripts_run = true;
   66   bool game_running = false;
   67   MapLoader maploader;
   68   int triggers[10] = {-1, -1, -1, -1, -1, -1, -1, -1, -1, -1};
   69   string var(string input);
   70   void alter(string key, string val);
   71   bool compare(string key, string val, char op);
   72   float sound_volume = 1.0f;
   73   bool godmode = false;
   74   void writeSave();
   75   bool dead = false;
   76   bool shield = true;
   77   int dcooldown = 60;
   78   int difficulty = 0; //0: easy, 1: med, 2: hard
   79  private:
   80   Sprite* s;
  ... 
  105 };
  106 #endif

oh no.

Some of you may be wondering to yourselves: "Strange, what's that 'Sprite* s' for?"
ABSOLUTELY NOTHING

Next Time: Busting out the hacksaw

AMAZE Postmortem

With this post, the little saga of AMAZE will be over.

It's rather freeing to be able to move on to other projects, but I think it's good to give it a bit of closure first. Normally, when I make a postmortem like this one I list what went right and wrong with the project. However, very little went right, so I think it's better to focus on what I learned so that I don't make the same mistakes again. Without further ado, here's the list:

When handling things asynchronously, watch out for race conditions:

This is a big one. It's the source of the stupid crash bug that I can't fix. The issue lies in the engine's scripting. Specifically, the ability to put delays in script. Originally, scripts were executed synchronously, in a single frame. By adding delays to scripts, I introduced an asynchronous element that meant that multiple scripts could run concurrently. This quickly became a nightmare, and eventually led to the bomb crash. Specifically, a delay occasionally causes a bomb to be destroyed while a collision script involving it is running. Because the remaining script is now trying to mess with something that doesn't exist, the game crashes. If I'd just made the script activate a timer on the bomb, the script would run on one frame and naturally would be prevented from running unless the bomb existed. This is the method that I'm going to try next time.

Don't put off art/audio:

For that matter, I shouldn't put off levels either. Because I focused solely on the code for so long, the end of development was just a mad rush to crank out as many assets as possible, and the quality suffered accordingly. Had I been working on the assets throughout the process, the game would probably be much nicer now.

Entity Component Systems are great, but don't forget prebuilt objects completely:

ECS was probably the biggest success of the project, but I still screwed up with it. I made creating levels slow, and updating objects next to impossible by not having any means of making predefined object 'templates' that I could stick everywhere and modify as necessary. Not only did this make designing levels take a long time, it also worsened the final product's polish immensely. For instance, I wanted to make a little ding sound and some sparkles when treasure was collected. However, this would've required me to alter every single bonus in the entire game by hand! Seriously, I'm not even joking. Had I made prebuilt objects possible early on, doing this would've been trivial, and taken 2 minutes at most. Whoops.

Preparation is key:

This rule applies to basically everything related to this project. Had I decided on a concrete art style, the game would've looked better and I wouldn't have had the issues I did(Like how some sprites are top-down, and others are from a slightly angled perspective). Had I planned the engine out more from the start, I wouldn't have had to rewrite as much as I did and the game would have been finished quicker. Had I spent more time thinking not just about what to put in the game, but how to do so, I would've started with a much smaller scope. I could keep going for a while, but I think you get the idea. Without a clear direction, the project became a nasty mixture of ideas that didn't quite fit together right.

Start Small:

When making the first version of this engine, I shouldn't have tried for a major project. Instead, I should have tried to make a bunch of small, varied games. It would've given me a better idea of where my strengths and weaknesses lay, and I could have spent more time fixing and upgrading the engine.

So, you might be wondering what will happen next with the engine. To make things simple, I'm taking a mulligan. I'm going to rewrite the engine from scratch and try to apply all of the lessons I've learned this time around. I'm going to plan more, make more small games, and also try to practice art and sound more. Then, hopefully I can try for a major project around version 3. Finally, I'm going to try and be more open about my work. I'm going to set up a public repository for the project so that others can see and contribute to the project if they want. I'll write more about that soon.

AMAZE Released!

Changelog:

• Added more bonus pickups.
• Fixed a bug where Zone 2's music wouldn't play.

Well, it's finally over. As of today, AMAZE and all of its source files are available for download on the games page. To be perfectly honest, it's a very underwhelming game. There's a serious lack of polish, a (thankfully rare) crash bug, and a general unfinished feel to the game. It makes me sad, in a way, to see it end like this. I first started this project about a year and a half ago, making it the longest project I've ever completed. Despite this, it has a similar, if not worse, feel compared to my tiny game jam games. Anyway, at least I know the reasons why. I'll explain that more thoroughly in my postmortem tomorrow. 

Needless to say, I will not be making the same mistakes again. I will be beginning a new project shortly, along with the second version of DFEngine. I will be fully rewriting the code, but now that I know what I'm doing it should be a bit faster. Stay tuned for that!

AMAZE - 26 - Done!

Changelog:

• Finished the last 2 levels.
• Finished the music for the Title Screen and Zone 2.
• Added two difficulties: Casual and Challenge.
• When loading a new game, the correct music should now play.
• Changing the volume will now have an immediate effect.
• Added some bonus pickups to almost every stage.

Here's the total completion of the remaining parts of AMAZE:

• Levels: 30/30: 100%
• Tilesets: 6/6: 100%
• Music: 7/7: 100%
• Total: 100%

So, that's it! The game is finished!

I'm glad to be done two weeks ahead of schedule, though feels rather odd. Normally, I'm several months(or more) off! Anyways, this will give me a couple of weeks to run tests on the game, and maybe tweak things a bit.

Unlike most of my projects, I will also be publicly releasing the source code at launch. You'll probably be seeing me do this much more often from now on. I think it's time to start giving back to the open source community. In fact, I will(hopefully) have the next versions of AMAZE be open source from the start, letting people see my progress much more closely and even contributing if they wish!

If you read my last post, you might notice above that there's no mention of a Hardcore mode. That's because I've decided to change how the difficulties work. Challenge is the same as Hardcore was supposed to be-exactly as the game was up until now. Casual has been changed a bit. Instead of adding checkpoints, I've decided to start Casual games with the maximum number of lives. I decided to change this mainly because of scope issues. Implementing checkpoints alone would be a pain, but then placing and testing them for every level in the game would be a nightmare. It's a feature that I really want to add, but that I should have started long ago for there to be any chance of it getting in. Anyways, if Casual is too easy, or Challenge too difficult, you can change the setting at any time. Note that you only get the extra lives if you start on Casual, and switching to Challenge will not remove them.

Finally, I'm going to take a short break next week, and I'll be back once AMAZE is released. I want to make some changes to this site, which will hopefully make it a bit nicer. If I'm fast enough, I might even manage to launch those changes with the release of the game!

For now though, goodbye!

AMAZE - 25 - So Close...

Changelog:

• Finished the Final Zone tileset.
• Finished the music for the Tutorial, Zone 1, Zone 3, and the Final Zone.
• Life pickups now permanently increase your max life count, but only if you grab them on your first run of the level. Afterwards, they're just a bonus.
• Finished 2 more levels of the Final Zone.
• Added an end to the game.

Here's the total completion of the remaining parts of AMAZE:

• Levels: 28/30: 93.3% 
• Tilesets: 6/6: 100% 
• Music: 5/8: 62.5% 
• Total: 88.6% 

At my current rate, it looks like I might be finishing next week! After I get the rest of the music and levels, I'm going to take the time to add several difficulty levels. I decided to do this, mainly because of the final levels. Right now, even I have some difficulty getting through the last few levels and I've been playing this game longer than anyone else!  I will be making three difficulty levels:

1. Casual Mode - You'll get an extra hit before death, and you respawn at checkpoints throughout levels.
2. Challenge Mode - You respawn at checkpoints throughout levels.
3. Hardcore Mode - No checkpoints, just as the game is now.

To do this, I'll need to put in checkpoints. These should be pretty easy, just setting where to stick the player when killed. Progress and items will be kept when  respawning like this, but the restart button will still reset everything.

I think this will make the game a bit less punishing for players, especially when they're just playing for the first time.

I've also started screwing around with a new project, but I'll save those posts for after AMAZE is finished.

AMAZE - 24 - Get a Life!

Changelog:

• Finished Zone 4.
• Finished the Zone 3 tileset.
• Started the Final Zone tileset.
• Finished the first level of the Final Zone.
• Finished the music for Zone 4.

Here's the total completion of the remaining parts of AMAZE:

• Levels: 26/30: 86%
• Tilesets: 5.5/6: 91%
• Music: 1/8: 12.5%
• Total: 73.8%

I'm going to start putting in this little completion bit until the project's done. I find that it does a good job of showing what I have left, even if it isn't perfectly accurate. I've decided that since the Final Zone doesn't introduce any new puzzle mechanics, I need to add in something to up the challenge a bit. To this end, I've added a timer to the levels. If you don't escape in time, you have to try again. I'm also considering making a change to how lives work. Currently, lives are temporary things. Grabbing an extra life is nice, but once you die it's gone. Instead of this, I'm going to make extra lives increase your maximum life count. This makes an extra life worth that much more, and allows players to make the game more difficult by ignoring them. I'm going to put one in each area, and make them only available on the first run through that area. Be on the lookout for them!

AMAZE - 23 - Not Much Coding Here...

Changelog:

• Finished all but one level in Zone 4 (The last is ~50% done).
• Fixed some issues with bombs.
• Remade the sprites for: Fireballs, Drills, Bombs, and Explosions.
• Made the tileset for Zone 4.
• Started the tileset for Zone 3.
• Made bombs beep before exploding.

Now that 7drl is over, it's time to get back to work. 

I spent the entire week worried that I was getting nothing done, only to realize today that I'd actually done a fair bit. That makes me rather happy. Seems I haven't lost my touch after all!

Unfortunately, since the game is so close to completion, I've been hardly touching the code at all. I haven't yet decided what to do with the second half of these update posts in the meantime, but hopefully I'll figure something out by next week.

AMAZE - 22 - Boom!

Changelog:

• Finished the first two levels of Zone 4.
• Fixed a bug where pushing moving objects caused them to be flung in some direction forever.
• Added Bombs and Explosions.
• Added a reset button in the corner of the screen. It works the same as hitting 'R' in game, but some people were requesting it.
• Fixed how multiple lines of text are displayed to make a bit more sense. Before text was wrapping in strange, incoherent ways.

Normally, I'd spend some time here adding technical stuff, but there isn't much to talk about today and I'm rather tired. The bombs were surprisingly simple to add, and consist almost entirely of out-of-engine scripting. I guess I could talk about the pushing bug. As you can tell, I've noticed lately that pushing is quite buggy. Most of the issues with it come from the fact that before Zone 4, it was impossible to ever push a moving object. This is because the only pushable objects are stationary by default, and even when on ice you can't reach them from a different angle before they stop. Of course, conveyor belts changed all that. Another source of issues is that objects that stop on the game's grid do so based on reaching new grid spaces, but the game's collisions don't take grids into account. This meant that you could theoretically push a moving block that's halfway between grid squares, and it would start moving in your direction along with its' current one. However, that change in direction would offset it from the grid, and so it would never reach another space and stop. Since walls and holes are based on that too, that means the blocks will ignore them, and fly offscreen forever. I've now forced pushable objects to be aligned to a grid to move, so the problem should now be gone.

Finally, the 7 Day Roguelike challenge has rolled around again. Last year I wimped out, but this year I'd like to give it a shot. We'll see how well that works...

AMAZE - 21 - Pushing Things Around

Changelog:

• Added Conveyor Belts, which move anything on them in one direction.
• Revised how object velocity is handled with respect to object collisions.
• Added an animation for disappearing locked doors.
• Fixed a bug where loading a saved game, exiting to the menu, then starting a new game could start you with the wrong tileset.
• Fixed a bug where loading a saved game, exiting to the menu, then starting a new game could cause the camera to start oddly zoomed out.
• Smoothed out the camera zoom animation.

Today, I'd like to talk about the second item on this list, the nebulous 'Revised how object velocity is handled with respect to object collisions.' You might be wondering what exactly that means. Basically, prior to this week, any object that collided with a solid object stopped on the spot. While this worked really well up until this point, I started running into issues once I added conveyor belts. Before now, you could hardly ever run into situations where two solid moving objects could run into each other. Now, it's easy:
Let's say there's an L-shaped section of conveyor belts. If two blocks are moving through this and they're close enough, one will run into the other at the turn. Previously, both blocks would get stuck and stop moving. With this new change, objects only stop moving when they collide and are moving towards the other object. Thus, in our L-shaped conveyor belt, the second block will stop until the first one moves, then it will continue. The first block was never moving towards the second, so it shouldn't suddenly stop.

AMAZE - 20 - Fixes and Balances

With the Games Fest over, I finally have time to fix things up a bit and focus on getting the game in a more fun and more stable state. Here's what I've got so far:

Changelog:

• Fixed Windows builds. It was quite a dumb bug. It also took maybe 5 minutes to fix, so I'm both very relieved and very annoyed.
• Made some small changes to a few early levels, mostly to simplify things and help teach the player a bit better.
• Doubled the number of starting lives.
• Fixed an issue which would cause the game to be reach an unbeatable state once you ran out of lives and respawned.

Speaking of the Games Fest, I think it might be fun to write about that here. Overall, I think things went quite well. I set up a little table with the game running, and I was almost unable to leave the booth at all with all the people playing! Most of the people who played got through the tutorial up until the last level, gave it a few tries, then left saying they'd had fun. While people liked the game, few of them got past this stage due to it being a sharp increase in difficulty. After some tweaking, I made it a bit easier. I think more people will be able to go through it now. The people who made it past the level all continued playing(at least, until they ran out of lives and reached the game-breaking bug that I described above), which is a good sign. I also was initially surprised about something I noticed: The players who seemed enjoy the game the most were young children and their parents. This makes sense in retrospect, as those kinds of people generally make up most of the 'casual' demographic. I never intended to aim my game at a specific set of people, but it makes sense. The game lets you move at a slow pace and think, levels are short, you can stop whenever, and there's pretty much no violence to speak of. Another thing I noticed was that two people who tried out my game noticed similarities to Chips Challenge, the game I'm taking a fair bit of inspiration from. It made me happy seeing that some people noticed this, but no-one thought it was too close or anything.

I also decided on a release date: April 25, 2014.

This gives me only two months, so I don't know how easily I can hit the date, but I'll do my best. April 25th is the last day of finals this year, so the idea is to get this game out just as summer vacation starts. With that done, I'll have the whole summer to work on new projects, including the next version of my engine. Here's exactly what I have left to add, in a general chronological order:

1. Finish the game code. I only have to code in the mechanics in the final zone, and the game's code should basically be done.
2. QA testing. Champlain College has a QA lab where you can get some basic testing and feedback for your games, so I just need to sign up for a few sessions.
3. Figure out the licenses for the libraries being used, and see if I can merge them into the game's executable. If I can, I won't need to provide libraries or get people to install them. This will greatly simplify the process of getting the game into the hands of other people. EDIT: I figured out a better way to distribute the Linux libs, so I shouldn't need to static link anymore. Also, it looks  like all of the libraries are using the same license, which coincidentally happens to be the one I was planning on using.
4. Finish the final 10 levels of the game. At this rate, I could make 1 per week and be okay, so this shouldn't be an issue.
5. Make/remake all of the game's assets. This one's the hard bit, and I don't know exactly how long it'll take. For now, I'll try to get 1 done per day and see how well that works.

That's it! Once those 5 things are done, the game should be finished, and I'll be able to release it.

AMAZE - 19 - This was one week?

......I really overdid myself this time. Nothing like a hard deadline to get me working, I suppose!

Changelog:

• Made trigger responses act like other scripts, and obey delays.
• Added an argument to make spawned objects be placed relative to the object that spawned them.
• Finished Zone 2.
• Created sprites for cannons and cannonballs.
• Fixed a bug where respawning in a different area could leave you with the wrong tileset.
• Made the ingame fonts less squiggly.
• Remade the sprite for spikes.
• Remade the sprite for level exits. Not sure I like it though.
• Added a script conditional that lets objects get more information about what they've hit.
• Made a sprite for doors that open from switches rather than keys.
• Remade the progress indicator in the main hub.
• Made a special sprite for zone entrances.
• Added doors to the hub. Zones must now be completed in order, but you can replay a cleared zone.
• Started reworking the title screen.
• Added ice, which causes objects to slide around.
• Made all of Zone 3.
• Fixed a glitch where some tiles didn't act correctly on load.
• Fixed a glitch where starting a new game after loading a save gave you some extras.
• Added some text at the start of a level indicating that you need to hit space to begin.
• Updated the credits to include the names of the libraries I use.
• Made the title screen a bit less atrocious.

In addition to all of this, I've made some major cuts to the game's scope. I was worried about the eventual length of the game for a long time. Originally, when I started on the hub setup, I'd intended for well over 100 levels. I found pretty quickly that this was going to be too much, so I limited the game to one hub, with 7 areas and 75 levels total. As I spent time on Zone 2, though, I realized something: I'm really starting to get tired of this game. I think the biggest problem is that the engine is still very annoying to work with, even after all this time. The best way to fix this would involve massive amounts of work-I'll pretty much have to rewrite the whole thing to get it in a state I like. I can't do this while I'm in the middle of a game, though. I found myself stuck in a loop, where I didn't want to finish the game until I'd done something that couldn't be done until I finished the game. After talking to friends about the problem, and pondering it myself, I made a decision. First, the number of areas was reduced to 5. Second, each area will only have 5 levels each, not 10. This brings the number of levels down to a far more manageable 30. Almost immediately after this decision, I found myself much more energetic and I've since pumped out not only the rest of Zone 2 but Zone 3 as well! This puts me at around two-thirds done now. I've got one more 'themed' area, and then it's the final levels. I've put up the newest build on the Games Page!

AMAZE - 18 - Experiment

For today's post, I'm going to try a new format. Instead of my usual style, I'm going to break up my posts into two parts. First, I'll provide a 'changelog' style of update, where just the features and fixes are listed. Then, I'll have a second part where I'll go more in-depth about something from the project, probably one of the features above it, and try to explain more precisely how it works. So, without further ado:

• Added a new file type, .oba, for premade objects. This pretty much follows the same format as objects do in map files.
• Added a new script function (Create) that creates a new object at a specific position and with a specific size and shape.
• Hitting escape anywhere outside of the menu now returns you to the menu. From the menu, escape still exits the game.

If you read my last post, you might be wondering why I got so little done despite having started on object files last week. I'm as surprised as you are. The main thing that kept me from finishing up this feature is a perplexing bug that I still don't understand. When making asset files, I use a library called zlib to compress them, making them much smaller. Then, when the time comes to load the files, I use zlib again to turn them back into their original form. Normally, this works like a charm. However, with the object files only, the loading process gives me nothing. I'm not sure why this process fails, as it's exactly the same as everything else that I use. Maybe I'll return to try and debug this later, but for now I just don't have the time. Eventually, I decided to settle with leaving the object files uncompressed. They're small enough as it is, so I'm not too worried about size issues.


If you have any feedback regarding the format of these posts, feel free to comment or send me an email at hugues.ross@gmail.com.

AMAZE - 17 - Under the Hood

Alright, it looks like I'm finally back on track. My increasing tiredness and lack of productivity culminated in a not-so-spectacular 1 hour catnap this afternoon, and I somehow feel refreshed. I've gotten a little bit of work done, too! 

To kick things off, I fixed a whole ton of memory bugs, mostly from forgetting to delete little bits of memory here and there. I've been focusing on trying to get features in, and it was starting to get a bit unseemly. Next, I went to the main menu and added everything that wasn't in yet. You can now set the volume at the start, and a basic credits screen is in. 

After that, I decided to tackle the problem of toggling switches. The way things were, switches would toggle if you walked into them, making them rapidly switch back and forth once per frame. I added a short pause, which makes things a bit nicer. However, that little pause took some ridiculous amounts of work to get functioning. Before this change, any reactions from collisions would happen immediately, and delays would be ignored. To add in delays again, I had to make the engine treat collision reactions in the same way it treats scripts. Then, I had to make it so that reactions wouldn't repeat as long as they were running. That way, the reaction doesn't trigger until the previous one ends, and thus it'll wait until any timers run out. Now, if you put a timer at the end of a reaction, it will only trigger at intervals set by the timer, and no faster. 

Normally, I would end the post here, but I have one last thing that I've started but am still working on. I'm making a new data file type for holding premade objects. Normally objects are defined uniquely in an engine like mine, but this will let me create 'templates' of sorts for certain types of objects. The biggest change that this will bring is the creation of new objects at runtime. I've been wanting to make cannons that shoot fireballs at set intervals for a while now, and this will let me do just that!

Finally, a bit of sad news: Considering the time I've lost, I doubt I'll be able to finish Zone 3 in time for the Green Mountain Games Fest. I've revised my estimates to aim to have Zone 2 done instead, as much as it pains me to do so. Still, Zone 3's mechanic will be very easy to implement(unlike this one), and I expect to at least have some of it done by then. Here's to two more (hopefully) productive weeks!

AMAZE - 16 - Bogged Down

I don't know what it is, but something keeps getting in the way of my productivity. Every time I say "Let's get a bunch of work done!" nothing happens, and I hardly get a thing finished. I have made a small bit of progress, but things are going way too slow and I only have 3 weeks to get this thing in a decent, presentable state.

Last weekend, during my little progress jam, I got very little done. However, I did accomplish 2 things:

1. For whatever reason, I felt like adding an overview of each level before it begins. I made the camera start zoomed out, then zoom in on the player when you choose to start the level. It's still a bit buggy, but I rather like the change.
2. I added a system that lets objects trigger level-wide events, that other objects can respond to. The next area is supposed to have lots of little contraptions, switches, and puzzles, so something like this is very important to have.

Overall, these were actually pretty quick, and I spent the rest of the time just slacking off. Then, I did a bit more this week. The biggest change I made was adding a means to access certain bits of game data from scripts. The main reason for this was so that I could add a little completion meter in the main hub. Whenever you complete a level, the meter fills up  a bit more, and once it's completely full the path to the final area will open. In addition to this change, I(finally) started working on Zone 2. Right now, if I work hard and maybe get a bit lucky, I think I might be able to complete the first three zones in time for the Green Mountain Games Fest. If so, the game will be pretty much half done and things will moving along rather well. I don't know if I'll manage to finish the whole thing before the end of the semester, but I can probably get most of it done by then and wrap the project up in late spring/early summer.

I think in 1 week I'll be able to tell how well things will turn out, depending on whether or not I can get work done by then.

AMAZE demo 2 released!

Click here for a list of updates and changes.

Unfortunately, as I mentioned in my last post, I will temporarily pause Windows support for at least a month. Still, if you have Linux you can check out the newest demo on the Games Page as always. Currently you need Allegro 5 installed to run it, but I plan on seeing if I can simplify the process a bit. I'll probably hold off on that until I start fixing the Windows releases though.

With that done, it's time to work on the next level set! My current aim is to have 50 levels done in time for the Green Mountain Games Fest, where I'll be presenting AMAZE. I don't think I'll hit that target, but I can probably pull off 30-40 without too much trouble. We'll see.

Finally, this weekend is the Global Game Jam again! As much as I want to do it again, I think I'll do another progress jam like last time, since I've still got this deadline looming.

AMAZE - 15 - Coming Soon to a Blog Near You

First off, let me apologize for the seriously late post. I wanted to finish the second demo before posting, and that took longer than I'd hoped. It's done, though. I've still got to compile and test this release for Windows, but then I can release it.

Now, it's a bit early but here's what you can expect out of this new demo:

1. Zone 1 now joins the tutorial, bringing the level count up to 15.
2. 2 new game additions! The drill can break through large rocks, and some new spikes pop in and out of the floor.
3. A number of bug fixes, and a whole slew of new bugs to go with them!
4. Automatic saving and loading, letting you exit whenever you want.
5. Respawn points make running out of lives slightly less of a chore. If you run out of lives outside of the tutorial, you just get taken back to the hub. You'll lose your progress in the zone, however.
6. Sound support, with sound effects for dropping blocks and spike traps.
7. An improved font for the score.

That looks like a pretty good list. I may go back and change levels from time to time, as I add new stuff. For now, though, they're fine as they are. Remember when this comes out, though: this demo represents the game in an extremely early and unfinished state. There will be plenty of bugs and annoyances, and the game will still be rather short.

I'm quite busy with schoolwork, but I'll hopefully get the demo out in a few days time.

Sorry about this!

There will be no post today, and there may be no Friday post either. I've become sick again, and frankly, I feel like s&#%. I've been in no mood for playing games, and I've been making very little progress on AMAZE. I will post the next development post when Zone 1 is complete, and link the new demo then. It might have to be next week if I don't start feeling better soon. If I do, I only have to make 8 more levels, and a few assets.
We'll see how it goes.....

AMAZE - 14 - Speedy

Sorry about the late post. Yesterday I had a meeting for my Game Production team, followed by a very long Dungeons and Dragons session, ultimately keeping me up until ~1:00 AM. Thankfully, I bring good news.
I've been coding up a storm this week, and I've not only met all of my week 2 targets but I nabbed some of the week 3 ones as well!

The biggest update is the save system. It's quite simple: The game quietly autosaves every time you beat a level, so you can just quit whenever you want without worrying about losing progress. Note that I've seen to it that you can't cheat by just reloading when you die a couple times. Anyway, once a couple simple bugs are worked out I'll be done with it. After that, I'd say the revamp of the engine's scripting would be next biggest. While most users won't notice a difference, this makes developing levels a bit less of a headache. While I was at it, I made a new font for the score too.

What's left for this week is mostly level building. I also need to make a new tileset for the first real zone of the game, which will probably be released in the next demo within a week or two. I'm also not perfectly happy with how certain things work right now, but changing them would be a massive timesink.



Lastly, here's an important announcement:
So far, AMAZE has only been shown off to my friends and colleagues, not counting this blog. However, as the marathon approaches completion, I have signed up to show off AMAZE to the wider public on February 22nd as part of an event run by one of my college's game development groups. I'm quite excited, but also worried. I don't think I'll be done by then, so I need to get as many zones completed as possible in the coming weeks. Assuming I make good time, I can probably get 4-6 zones done in time for this. After that, I hope to finish up by the end of the semester. However, I may spend another month or two after finishing up. Either way, I already know what game I'll be making next, though I won't tell anyone until the time is right..... Let's just say there will be explosions.