4 Hugues Ross Writes a Devlog: 02/01/2014 - 03/01/2014
Hugues Ross


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:


  • 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!


  • 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.