4 Hugues Ross - Blog
Hugues Ross


Cloudy Climb -- The Announcement and Postmortem Double-Feature!

Hello again, readers. It's been quiet around here lately, but that changes today. For the first time in quite a while, I'm releasing a brand-new game! The game is called Cloudy Climb, and it's--wait a second, we've done this before!

Not Quite a Remake

Yes, that's right. I've made a second Cloudy Climb. Like most of my projects, I was never really happy with the original. More importantly, I was in the mood to make a game. I've been working on this version for about 2 months, and I think it's finally reached a point where I can call it 'done' and not feel bad about it.

You can get the game via the widget below, or take a look at the git repo here.

A Postmortem for Our Dear Prince

While I still have your attention, I'm going to do a write a quick postmortem for Cloudy Climb. Postmortems are a very useful tool that I don't use nearly often enough. So, let's get to it!

The Story

I started Cloudy Climb during the last week of December, mostly because I was bored. After DFGame and Singularity taking most of last year, I was in the mood for some simple game development. I also wanted to see how well DFGame would fare under Game Jam-esque constraints, so I set myself a time limit of 1 week.

As we're all well aware, it took a little bit longer than a week. I got the basic mechanic and some of the graphics done in a couple days, but I got sick around the 4 day mark. Since I wanted to make something decent (and this wasn't really a game jam anyway), I decided to spend a few more weeks taking the game to a more finished state. Then, I just decided to take "as long as I need" to get the game into a relatively solid finished state.

In late January, when the game was really starting to come together I finally revealed its existence to some of my friends. Besides being friendly, I primarily did this to gather feedback. I started with this video:

...And slowly polished things over the course of a few more:

With the feedback gathered from my work, I completed the remaining assets and now we're here!

What Went Right?

  • Feedback! I'll be gathering more of that in the future. My friends caught a lot of little things that I was able to fix ahead of release. For a good example of that, listen to the stage end jingle in the last feedback video. One of my good buddies pointed out that it was too drawn-out, and I ended up cutting the final note out. I think it sounds a fair bit better as a result.

    There's also the really nice spike animation, which involved a bunch of critique passes in a pixel art community I found. I think the difference of quality there is very clear compared to the rest of the game's art.
  • Field Testing! One thing that I got out of this that I find really valuable is the experience of using DFGame on a non-trivial project. It's been really enlightening, and I'll be making (and in some cases, have already made) several changes to the API as a result.
  • Requirements! Because of this project, I was finally forced to get off my butt and learn audio. I'm still very bad at music, but I still think much of the game's audio is a good step up from previous games. I've taken the first step, now I just need to keep practicing.

What Went Wrong?

  • Rushing! A number of the assets could be much better, but after spending the better part of a weekend just making that spike ball I decided to try and make things "good enough" and move on. Frankly, it shows! Most of the art is pretty ho-hum, and it could've been much better if I'd taken the time to flesh it out and get critique. This was supposed to be a quick filler project, so I'm not too upset at the quality, but it's still a clear weakness.
  • Procrastination! I spent a long time finding tasks that didn't involve audio to do. This resulted in my last few weeks being almost nothing but music and sound, which got old pretty fast. It also means that the part that was my weakest skill also got the least amount of dev time! If my old drafts are any indication, the music would probably have been significantly better had I been iterating on it from early in the production.
  • The Core Design of Your Game, You Numbskull! So this is kind of a big one: Cloudy Climb's concept is pretty awful. The game works pretty well as an "infinite runner"-style game like the original, but the value doesn't translate well to a level-based platformer (in my opinion) for a few reasons:
    1. There's very little room for 'soft' failure states. For obvious reasons, messing up your movement always means death.
    2. Your character's only means of interaction with the world are 'bounce' and 'bounce, but moreso'. One could envision a game with one or two additional player actions, but the base concept pretty much requires one of the primary actions in the game to also be the basic movement.
    3. The game is extremely vertical, but the platform (PC) uses a horizontal aspect ratio. What's more, you move up and down pretty quickly thanks to gravity. A metroid-style camera would've helped, but I don't think it could've magically fixed the problem.


So the game didn't come out great, but at least most of my sins are pretty fixable, and a quick gander at this ancient postmortem indicates to me that I'm capable of learning from my mistakes. I put off much less of the content this time around, my code was perfectly fine, and I had a tight scope that grew organically to fit my needs and capabilities. Much like the game, the development process was distinctly not terrible! So here's my big lesson:

Iterate and get feedback on your big mechanic from the start, and make sure that your game is always presentable. That means taking the time to make assets (or at least decent placeholders), to ensure that you're always engaging with every aspect of the work and not leaving anything for the end.

There's More!

Even though this project is finished, I'm not moving on just yet. During the project, I found a few bits of technology that I want to explore, and this seems like a good opportunity to do just that. I'll be using this game as a testbed to get a feel for them, then I'll move on to something new. I also got an idea for a short tutorial/informative article based on some of my work on Cloudy Climb, so I'll be working on that as well.


Adventures in GrafX2 Scripting

I'm currently working on a little game project. Since I want a relatively polished result, I have a lot of art assets to make. I'm spending many hours in my editor of choice, GrafX2, and I get the opportunity to see places where my workflow falls short. Sometimes, I want to do something but it's a little annoying because of the tools I use.

If I were nothing but an artist, then that would be the end. I'd either have to grit my teeth or move to another program. However, I'm a programmer and GrafX2 has a scripting API. I think you can see where I'm going with this.

Minor Troubles

There exists a pretty major roadblock for anyone who wants to get into GrafX2 scripting: There's no API documentation (As far as I can tell, at any rate). I spent my first 15 minutes or so trying to use the example scripts as reference, before getting fed up and tracking down the source code. As you can see here, there's one convenient spot in the codebase where you can find the relevant Lua functions. Thanks to my line of work, I'm already very used to reading code in place of docs so this made my work much simpler once I discovered it.

Another thing to be aware of is that GrafX2 always loads scripts when they're called. That means that all you need is an open copy of GrafX2, and you can regularly call your script for testing/debugging as you work. In my case, I set up my code and my editor side-by-side like so:
Click the image for a larger view

With these tools in hand, writing new scripts to improve my workflow is quite easy!

The Scripts

In the spirit of giving, I'm going to discuss the scripts that I've written and share them with the internet at large. All 3 or so GrafX2 users in existence can enjoy my work and rejoice!

If you just want the scripts and don't care about my chattering, click here now.

Animation to Spritesheet

This was my first and arguably most important script. GrafX2 generally exports animations as gifs which I have to go back and edit in GIMP to make them into spritesheets. This process is rather annoying, so I decided to make a script to do it automatically. Once that was done, I figured it might be worth my while to polish and release some scripts. (Technically, I still have to change the color mode to RGB in GIMP, but I plan to add indexed color support to dfgame sooner or later)

This script pretty just copies animation frames to the second page, and arranges them however the user asks. There are probably more options that I could add for more complex layouts, but it should cover most cases.

I recently noticed an issue with this script where it doesn't work occasionally. When that happens, you can probably just run it again and it'll work. The script's logic appears to be correct, so it may just be a GrafX2 bug. It's hard to tell for certain.


Zoom-in-Place, or ZinP as I like to call it, is a product of how I like to present my work. As you can see in this post, I like to place a zoomed version of my art next to the original. This is also useful for getting critique! Unfortunately, this is a little bit annoying to do manually. I could just take a screenshot, but that method is impossible for animations like this one:
That took about 2-3 seconds to produce, and most of those seconds were spent finding and starting up the script. It's probably even faster than spinning up a gif/video recorder, and unlike a recording this preserves the palette information correctly.

Append Page

Since I was on a roll, I decided to write another script. This 3rd script, Append Page, is pretty simple: It just copies information from the inactive page to the currently active one. Unlike the page copy in GrafX2, this script appends the copied data instead of replacing the original contents. The result leaves the two pages side-by side for easy comparison. Unlike a normal copy and paste, Append Page preserves layer information. As a result, you can easily compare two variations of the same image layer-by-layer without making several manual copies.


I'm aware that these scripts are fairly situational. Indeed, they're absolutely catered to my specific workflow. Honestly though, I think that brings up a really good argument for non-coders to learn just a little bit of scripting:

When you know the basics of scripting, you can take your tools and make them work just right. Maybe there's one little thing that annoys you here and there, or a minor little convenience feature you wish existed. When you know how to script, and your applications support doing so, there's nothing to stop you from solving your own problems and getting that perfect workflow.

Someday, I want to see a world where DIY scripting is regarded as normal enough for everyone to know just a little bit. It's awfully idealistic of me, but I think it'd be a nice thing to see. Programming can be awfully hard work, but just a little bit here and there can produce great results for relatively little trouble.


Singularity v0.3 relesed!

Can you believe that it's been 3 years since the last Singularity update? That's crazy! Never fret, I have a new one right here. It ended up landing a week late, but I don't really mind.

Honestly, I don't have much to say about the release itself that I haven't mentioned in a previous blog post. It's funny to see how far I've come since the first release, though. In the original version, you had to wait 10-15 minutes before it would actually open the window. In 0.2, the window would open but you pretty much couldn't do anything until it finished loading anyway. Now, it opens instantly and you can just start reading. Y'know, like any normal application.

I think that's the really funny thing about the progress I've made over the years. I've finally gotten to the point where I can make something "acceptable", something that looks like a run-of-the-mill product. Up until now, my work had more of this... hacked-together student project quality to it. Now, it feels more professional.

I think there are two main factors to this. One is obviously skill, you get better at things with practice. However, I think changing standards have made the more visible impact. For a long time, I developed things with only me in mind. I would embrace bugs and weirdness because the results were close enough to what I needed. Recently though, I've begun to think more in terms of "What would someone else think if they saw this?" As a result, I've been putting more effort into polishing my work.

For a good example of this in action, look at the commits I made between merging my code and making this release. What happened is that I decided to take some screenshots of the program, but realized that there were tons of little inconsistencies and problems that would ruin the shot. This led me to start tweaking and fixing, until everything felt like it met a certain level of quality. In doing so, I realized that several of my earlier additions had been left half-finished, like bits of the column view UI and the popover for new subscriptions. I fixed them up, but I'll have to be more careful about this in the future.

Looking good.

So that's a Singularity update out of the way. I'm still working on my game, slowly but surely. I was planning to release it this weekend, but it's still pretty rough. Since I no longer have a schedule to keep to, I'm in no real hurry to push this game out the door. I'd rather have one good, polished game that took too long than several bad games that I rushed.


2017 End of Year Wrap-up

I wrote this a couple days before New Year's Eve, but forgot to schedule it. Whoops!
Another year has come and gone, and even with health problems and tutorial troubles I still managed to complete a few projects.

This year also featured several new things, like my DFGame update videos and a semi-stable schedule. Without further ado, let's look back at the year's bounty:


This is the 3rd year in a row that I've brought up DFGame in my end of year wrap-up.
In 2015, I decided to drop the DFEngine project in favor of something smaller and sleeker.
In 2016, I talked about how DFGame was pretty successful (and the rewrite I was planning).
And now, this year, I had an actual first release. It's nice to see a plan come together like that. There will be a new DFGame update coming out in 2018, with a few changes and fixes related to this post. I've updated the application module to provide split editor/game functionality, and stripped out all direct references to GLFW from the demos for good measure.

I've also been making a small game this week. I'll have more to share on that front soon.


As a welcome surprise to cap off the year, the latest version of Singularity is pretty much done. All that I want to get done at this point is a little bit of extra documentation, and then I'll make the release official!

The Website

I redesigned several pages this year, and it's almost all finished. I'm not particularly fond of the tutorials page right now, both because it's not great looking and because it's lacking in content. However, the landing page, about me page, and software page got some nice makeovers.

The Ill-Fated Roguelike Tutorial

This whole project was really unfortunate. I think I made the right call by ultimately cancelling it, but I'll have to make up for the lost content with some smaller tutorials at some point.


Learning pixel art wasn't a very high priority on my to-do list, but my shoulder issues forced me to find a new hobby. Things have gone pretty well so far, and hopefully I can start reaping the rewards of my practice once I start back up on game development. In the meantime, have a few more pieces:

Next Year

With my retrospective done, it's time to give some consideration to the year ahead. Obviously my plans are subject to change, but I do have a general idea of what I want to do next.

Judging by my overall performance in 2017, I think I can feasibly complete somewhere in the ballpark of 1-2 reasonably-scoped projects in a year. I definitely want to revisit Halberd, although it'll probably take more than a year to complete. Alongside that, I want to make a couple tutorials (probably small ones) and some kind of game. I haven't really worked out any specifics for those, but they're on my to-do list.

For now, though, look forward to a singularity update and a minigame coming soon!


Taking a Break

It's holiday season, so I've decided to take the rest of the month off from posting. I will have the usual end-of-year reflection post, so either that or the Singularity v0.3 update post will be next.

Happy Holidays!