4 Hugues Ross - Blog
Hugues Ross


Halberd Studio: No Sleeping, Just Scheming

I didn't sleep last night. The cause had nothing to do with my projects, but I ended up thinking about Halberd for a few hours. The more I thought, the more I became certain: Something has to change.

If you read my roundup for September, you'll know that I actually made some decent progress. Despite that, I still have a lot of doubts. After last night, I re-read all of my recent posts and decided that a new strategy was in order.

There's a wall of text about my motivations between you and this strategy. Click here if you'd prefer to skip it.

...But Why?

Obviously, this is coming off as indecisive. Still, I came to an interesting reason to change things up. I wrote about a similar feeling in August. At the time, I wasn't happy with the game. I looked back at my first post on it, decided that my reasoning was still correct, and kept going.

As a refresher, here are the reasons I had for starting:
  1. Making a game is a way to validate that the tool works, by forcing me to engage with all of its features. If there are any bugs or missing parts, I can fix them before release. It also lets me see which features need the most love and which are 'good enough' as-is.
  2. Having games made in an engine is also good for proving its capabilities. Anyone can make game development tools, but if no good games have ever been made with them then they'll be a tough sell for other devs.
  3. Finally, games can also serve as a useful reference for anyone who wants to try Halberd out. I don't think anyone will at this point in development, but when people do start using it they'll have something to help them.
  4. Additionally, the large scope of Halberd makes it a real marathon of a project. I need to break it up with smaller game projects if I want to keep my sanity! Not all of my 'filler' will be made with Halberd, but it's still a convenient excuse to give the engine a workout.
I still think these points are sound. However, my current project isn't actually the best way to address them. Let's go down the list again:
  1. The first reason is spot-on. Making a game is a pretty solid validation process. Making a demo of the engine's features could also work for this.
  2. This point disqualifies a demo as a complete solution, but there's an important word in there: Good. A bad game won't convince anyone to use an engine, it may even turn them away.
  3. See point 1.
  4. Here's the other problem: I replaced one drawn-out process with a drawn-out process and a diversion that I didn't personally enjoy. Demos won't fix that, but I have some other plans.
'Henry' is not a good game. It won't be a good game, and I'd even go as far as to say that it can't be one. As I work on this project, I can feel the time I'm wasting. That has an impact on my productivity, and it's exacerbated by the fact that I was never really that interested in it. I knew that my options would be limited, so I tried to go as simple as possible. I also used the game to try a new post format. That's pretty much all I have to say about it, because there was nothing else to hold my attention.

Despite my lack of interest, I still want to make RPGs in general. I have a few 'real' ideas on the backburner, but Halberd just isn't ready for them. The engine is technically in an 'MVP' state because you can make a game with it, but it's not viable for anything serious yet.

The Plan

That last section went long, but it felt good to get it out. Next, let's talk solutions. Back in August again, I listed some wants. After re-reading them, I can confidently say that they mostly hinge on being more patient and giving Halberd the time it needs. Working solely on Halberd brings up the issue of fatigue, but nothing is stopping me from keeping my current 'alternating weeks' strategy. Let's run with that concept.

Halberd is a huge project, and there are a lot of very different tasks needed for its success. I've split them into roughly four different categories:
  • Foundations
  • Progress
  • Polish
  • Content


Halberd rests on top of DFGame, and I've regularly had to dive in to fix issues and add features for the engine's sake. One thing that bothers me is that I never have enough time to polish all of this internal code. With the pressure of getting a feature to work so that I can finish whatever I started on Halberd, it's hard to spend extra time on code clarity, tests, refactoring, and so on.

Long-term, these things are necessary for a healthy engine.


The 'critical path' to making my dream games, if you will. This category represents the features needed to make a powerful and flexible engine, things like custom equations, items, cutscene and dialogue tools, etc.


Just getting Halberd to work well is enough for me, but to really sell (figuratively) the engine to the public I need to make sure that it also feels good to use. That means taking time to fix minor gripes, improve workflows, write help docs, and work on unifying the engine's look and 'brand'.


I've never brought it up, but I think a big factor in novice-oriented engines is the quality and variety of the assets they pack in. I'm convinced that this is partly why so many people are attracted to RPGMaker, and also why some people look down on games made with it. Assets matter in the market that I'm planning to enter, and they're also a good source of practice.

If I spend enough time building my art and audio skills before I start my RPGs, I can make them truly live up to my expectations.


With some diverse long-term tasks prepared, the remaining question is how to divvy them up. Conveniently, I found out last month that I can get a couple solid features done per week. For now, I'm going to try focusing on each of these categories for one week every month. I'll keep this up until the end of the year, then I'll re-evaluate if I'm still not happy.

Looking further ahead, I'm about 5 1/2 months away from the first anniversary of Halberd's announcement. I don't think it'll be ready for release at that point, but I'd like to at least have some convincing demo videos by then! I'll also make the code public some time in the next few months, so that I can point people there for more detailed progress.


Halberd: September Roundup

It's been a pretty long month. A lot of general life issues cropped up, and I honestly feel like I didn't accomplish enough overall. I also didn't find the time to write any blog posts either, so I thought I'd try and go over the current state of things now.

Where we last left off, I was trying to find a balance between engine and game progress. For the time being, I've settled on alternating weeks. A single week comes out to be enough time to get one or two notable things done, so that seems to get me slow but steady progress on both projects.

Given that the aforementioned life issues probably cost me a week or two, it's hard to tell if the resulting development speed is actually acceptable. I'll probably have a better idea after next month.

State of the Game: Audible frustration

With all that said, I've actually made very little progress on the game. The main culprit is, as with Cloudy Climb, my complete lack of musical skill. I'm slowly improving but making music is still a difficult process for me. I think this problem will eventually go away, but in the meantime it's still a major roadblock.

I've made some progress on the art front, with a finished player sprite and the beginnings of the second area's tileset. Once the music problem is resolved, I should be able to keep going at a steady pace.

State of the Editor: Polish!

One of the things that concerns me about working on Halberd while making a game with it is how to resolve the potential for feature creep. Let's imagine for a moment that I decided to focus on adding NPCs to Halberd. If I succeeded, there would be a pretty strong temptation to add NPCs to the game as well. They would certainly make the game better, but they would also increase the scope of the final product. With enough features, I might find myself overextending the game way too far. Thankfully, I have a long todo list and many items on it have no effect on project scope. This month, most of my focus has been on UX and 'branding'.


Improving the general workflow and looks of an engine is pretty much always useful, especially since Halberd is still so unpolished. So, I spent a couple weeks on making it look and feel better to use. I've been posting occasional screenshots to my Twitter account, here are a few for those who don't want to bother looking for them:
New landing page with a list of recent projects

Asset icons, and a new quick asset selection button

Settings split into sections, and a new vector editing widget with custom icons

There's more than this, but that covers most of the juicy bits. When the time to release this thing comes, I'll probably make another video in the 'walkthrough' style like I did last time.


I've never liked branding, advertising, community building, and other 'tangential' aspects of development. This is probably because I'm not a social type, I prefer to sit in a dark room and create. However, reality dictates that if I ever want Halberd to be successful, I need to 'sell' it to its target audience.

Halberd will always be free (in every sense of the word), but in this day in age that's just not enough. I need to convince others that my work is worth using, and one part of that is building a consistent presentation and messaging. To that end, I decided to start thinking about this problem early.

"What should Halberd offer?"

This is an important question, one that I believe is core to making the engine more than just a technical success. A common question that I see whenever a new engine is announced is:

"Why use this instead of insert established competitor(s) here?"

I know that this question will come for me too, and I want to have a real answer ready ahead of time. I already discussed some of my motivations in my original announcement post, but I now have a pretty specific idea of where I want to take Halberd in the future.

Right now, I think there's still a divide between engines that are immediately accessible to newcomers and engines with modern and efficient development pipelines suitable for serious commercial work. Engines like Unreal and Unity have tried to style themselves as welcoming, but the fact of the matter remains that developers must learn to program to make much with them (yes, UE4 blueprints are programming). On the other side of the spectrum, some engines like GameMaker: Studio have tried to modernize and improve. This development is more interesting to me, but curiously a lot of more targeted engines (such as RPG Maker, SRPG Studio, Wolf RPG Editor, etc.) don't seem to have kept up as well.

Not that this has stopped developers, of course. I believe that good games can be made with any engine, but games are best made with a good engine. My hope is that Halberd can someday offer itself to RPG devs as an engine that's dead-simple to start, but offers enough power and depth to be ideal for professional-grade work. It can't live up to that dream yet, but I think having a strong vision from the outset will help ease people's fears.

Thinking about names

I like Halberd. It makes for a simple and memorable name. On the other hand, it's a noun that doesn't really describe anything. That's not uncommon in game engines, but I decided to try and find some other possible names.

To that end, I threw together a bunch of words that I could fit together to try and find something better. I mostly stuck to descriptive words like 'builder', 'editor', 'engine', 'game', 'rpg', etc. Most of the results didn't really impress me, but I do like the ring of Halberd Studio. It's not really any more descriptive or SEO-friendly, but it has a more official tone to me.

Given my end goal, it might be worth sticking to. My only concern is that there are already several 'studio' game engines hanging around, and throwing another one on the pile might not be a good move. I've keeping that name for now, but it's still not a final decision.

Next up

Looking back on this post now, I suppose September was actually rather productive! I'll probably try to focus a little more on the example game next month, since that hasn't seen as much progress lately. I still don't know how long it'll take to finish, but I'm hoping for some sort of official release before the end of the year. We'll see how that works out over the course of the next month or two!


Changing gears on Halberd

Right now, I'm in a bit of a difficult situation. My current game project has been taking much longer than I'd hoped, and I still haven't made a first release of Halberd. I don't make release dates anymore, but I'm still not happy with my current progress.

When I originally announced the game project, I acknowledged the risks and gave a few reasons why I felt the project was a good idea. Unfortunately, my arguments are still sound. The game has a reason to exist, and dropping it to speed up development doesn't strike me as a good option. So, I need to rethink my overall strategy.

What do I want?

When coming up with a new approach, figuring out I think it helps to consider what you want and why don't have it. The former helps you shape a goal, and the latter indicates the obstacles that you need to deal with to attain it.

In my case, there are a few things that I want:
  • I want Halberd to become a useful, successful game engine - That much should be pretty obvious, most people don't set out to fail.
  • I want to make good games - And, hopefully, have people play and enjoy them.
  • I want to make tutorials - To give back to the internet, of course!
On the surface, these goals seem pretty simple. However, I think the biggest reason why I keep running into problems is that these goals are in conflict with each other. And where does the conflict stem from? That's right, it's time! All of these goals are achievable for me on their own, but they're time-consuming enough that juggling them all is difficult.

Fixing the problem

Like with any other resource, the only ways to resolve a lack of time is to make more, or to use less. Making time isn't an option for me (besides quitting my job, which would be a terrible idea), so instead I need to find ways to balance time and quality.

I can start by striking tutorials from the list. I don't spend time on them now, and it's unlikely that I'll suddenly start later. That leaves me with just my programming projects, which are currently the main problem.

Another common option for reducing the time spent working is to collaborate with others. This is how most people cope with a lack of time, since dividing work isn't too difficult. However, freelancers are expensive (they need to live too, after all) and volunteers are typically less reliable. I don't want to shelve the idea entirely, but I think I'll at least need to save money or produce work that's more exciting before I can take advantage of this option.

Making Changes

In the end, I don't have any strong solutions to this problem. Working on one item to the exclusion of the other (as I have been recently) doesn't work well, so I need to find a way to reasonably balance out 'engine time' and 'game time' so that they can coexist. Here's my current plan:
  1. Go back to my regular posting non-schedule. I was using this game project as an experiment, but I'm not impressed by the results. I don't think I produced much interesting content, and I ended up spending a ton of time writing posts.
  2. Resume work on Halberd. I'm going to get started on the next release while this game project continues on the side, so that Halberd doesn't get bogged-down too much by side work.
  3. If I finish the next release of Halberd before the game, then I'll try to devote more time to finishing the game with that release. Otherwise (more likely) I'll wrap up the engine when the game finishes and release both together.
Future releases of Halberd will probably work the same way, with one game on the side dictating the engine releases. This lets me make plenty of games, but doesn't stop the engine dead in its tracks if the process gets bogged-down. In the long run, I'll probably also see if I can split things up in a more decisive manner with scheduling. That seems like overkill for the time being, so I won't try anything like that yet.

What this means for you as a reader is that I've split up the Halberd roadmap into two pages, one for the game and one for the editor. The blog will be getting occasional updates about both, and hopefully things will work out nicely!


Making the first Halberd game: Is this still a mountain?

Last time, I started building the actual first map for my game. A bit of messing around later, and...

I'm not really sure how to feel about this. It feels a bit noisy and chaotic, and it's clearly not very mountain-like anymore. Even running at my target resolution, the result is a little too confusing:

Clearly, I've over-corrected a bit. After simplifying the terrain a bit, I end up with this:

It's alright. I'm not thrilled with my results, but I think they look good enough. There's a line to be drawn in terms of polish and I've already spent a week on this map alone, so it's probably better to keep moving for now. If I feel a strong urge to do so, I can do another polish pass on the maps later.

...But Wait!

Unfortunately, we're not out of the foothills yet. After all, there's no music and no enemies! Given the fact that is is supposed to be a fairly short project and I'd like to avoid holding up Halberd's development for too long, I'm going to try sticking to more of a 'sketch' quality level, something like this:

This will be the combat background for the first area. It's rough and not really that detailed/attractive, but it's god enough to work as-is. If I can match this level of detail in the rest of my assets, it should be easy to complete the project quickly.

Moving on to the actual enemies, I need to keep the designs reasonably simple to draw as well. After all, some subjects are much harder to depict than others. To that end, I've made a couple simple designs for the first area:

They're not the most exciting creatures you've ever seen, but I think they'll work well as cute little monsters to deal with early on. Now I just need to add them in and take a crack at music, but that can wait for a future post. For now, I rest.


Making the first Halberd game: There's no math in this blog post, I promise!

In the last two posts I did a ton of math, all to make a squiggly line. That's peak efficiency right there, nowhere to go but down!

Anyhow, today will be a little more hands-on than that. To that end, I've produced a gorgeous tileset:

Being serious for a moment, this tileset should cover all of my basic needs for laying out a path. It has 3 colors, representing floor, stairs, and wall. For a  little winding path in the foothills of a mountain, that should be all I need to start with. Next up is the map itself:

This is the first time I've really been able to appreciate the scale of what I'm building. It's big, bigger than I'd really pictured in my head! And of course, I'll be building several areas of similar scale. It shouldn't be a problem, but man. That's a lot of map.

Well there's no time to spend crying over map dimensions, so let's dig in. First of all, I can cut out the margins...

...3 minutes in, I feel the sweet embrace of Carpal Tunnel Syndrome approach and hastily add a 'paintbucket' tool. Some limitations are just too harsh.

With that roadblock out of the way, putting together a path that mostly matches the calculations from earlier is child's play:

...it's not the most awesome map I've ever seen, but it'll serve as a good template to work with. Next, I abuse the properties of Manhattan Distance to make the path much more interesting with little change to its actual length:

After measuring, this path is pretty close to my 250 tile goal. Finally, I widen it out a little bit:

I can fix any errors and smooth things out as I go, so this feels like a pretty good base to work with. Next up, we need some art!

Art, and problems

Over the weekend, I assembled the start of a tileset for this mountain path:

One thing probably stands out here--There's a lot of brick, but not much natural stone or dirt. I tried a few rockier walls at first, but I had trouble getting them to look good with the rest of the tiles. In the end, I decided to go with retaining walls, as you might see in a couple spots on a well-maintained trail. I'll probably keep looking for a good rough stone wall for some of the higher parts of the trial, though.

Once that was done, I put the new tiles into the map and came to a terrible realization:

The walls have inconsistent heights, royally screwing up the perspective. It's blindingly obvious in retrospect, of course the edges of the terrain need to line up!

Unfortunately, this means that I have some fixing to do.....