Halberd, and the Roadmap

I've spent the first three months of this year making a new game and doing bits of research. Now, I think it's time to start working on something a little more long-term again. The Halberd project was put on hold back in college, and the DFGame rewrite prevented me from picking it back up last year. With a fairly clean to-do list in front of me, now's the perfect time to get back to it!

Halberd What?

It has been a couple years since I did or wrote anything substantial about Halberd, and the original attempt began nearly 5 years ago. With that in mind, here's a quick refresher on what the project is.

Halberd originally started as an attempt to make an old-school JRPG in LÖVE, then rapidly ballooned into an attempt to make a more general JRPG engine and tools, still in LÖVE. The project was put on indefinite hold, and I eventually picked it back up as a sort of open-source RPG Maker alternative developed in C and Vala.

That final design has held. My goal with Halberd is to produce a complete and polished open-source RPG engine, with an editor and all other associated tools. I want to produce something simple enough to enable someone with no previous programming or gamedev experience to make RPGs, but flexible and feature-rich enough to be a serious consideration for a more experienced developer.

Of course, I also want to make some games of my own with it!

Scoping Up

One thing that I want to do with this new attempt at Halberd is an increase to the project's scope. This may seem rather foolish, but there is a reason. I've played a lot of games made with various engines and tools, and I've noticed that many games made with engines that are too restrictive often end up either feeling generic, or fighting with the engine to produce a unique but half-baked result. This is not to say that all engines should support all types of games, but I think there's some value to be had in supporting a collection of related genres, rather than a single narrow game type.

Ultimately, I want Halberd to provide good support for 4 types of games:

1. Old-school turn based JRPGs. The obvious example here is any Final Fantasy game prior to 7 (and much of Square's old catalog in general), but this genre covers a wide swathe of games. This is what Halberd was always meant to support, as a theoretical alternative to RPGMaker.
2. Old-school action RPGs, like the Mana and Ys franchises. I would also place the Legend of Zelda franchise here due to its mechanical similarities, although many people have differing opinions on that one.
3. Turn-based strategy games, specifically in the vein of the Fire Emblem and Advance Wars franchises.
4. Graphical Roguelikes such as Dungeons of Dredmor, Nethack (in some variants), ToME, and the Pokemon Mystery Dungeon games.

I selected these four genres because I believe they have many overlapping features. In my mind, it seems reasonable for a less experienced developer making RPGs to want to add more action-oriented gameplay, strategy aspects, or even procedural dungeons. By supporting several genres, I can help this theoretical dev implement their desired mechanics in a less janky fashion.

To back up my choice of genres, I've also produced a Venn Diagram to try and show where I see overlap between the listed genres. I know that there are plenty of exceptions, but I think it still does a good job highlighting some common shared aspects and mechanics:

Click the image to view a larger version

A Change of Strategy

In theory, I've convinced you to accept my rationale for this major scope increase. Now, here's my plan to pull it off. I have enough experience to know that an overly large scope can easily bog down or kill a project, so I'm going to break up this task into smaller parts to improve the overall chance of success.

In the past, I've typically had a "release when it's done" attitude, which results in long periods of development followed by either complete releases or major updates. Case in point, the period between when I announced that I was working on DFGame and when I finally made the first release was 22 months. This time around, I'm going to start with a Minimum Viable Product, and follow that up with numerous smaller updates to give myself regular milestones to hit and stay on track.

In the short term, the MVP release will be enough to make a map the player can walk around and fight monsters in. No skills, levels, items, or dialogue, and only the bare essentials of UI will be present. Once that's done, I'll produce a small demo with all the features, and expand from there until I have a fairly flexible and robust featureset for turn-based RPGs only (in other words, the original scope of the project). In order to ensure that the engine and tools work in practice, I'll be working on a full-length JRPG at the same time. Once both of these things are done, I'll slap a 1.0 on the project and begin work on supporting additional genres and mechanics in largely the same way.

With this method the scope increase isn't going to impact development in the short term, instead existing as a reminder to keep features flexible and open for further expansion.

The Roadmap

With this post, I've also made a new addition to the site! I'm trying to only post when I have something interesting to write about, but I still want there to be an indication that I'm working on something when I'm busy (such as the period of relative silence when I was busy with Cloudy Climb). To that end, I've rolled out the new Roadmap page to show progress on larger projects.

Every project tracked on the Roadmap page will have:

1. A graph showing the status and relationships between tasks
2. A changelog of task updates, blog posts, and releases
3. Various associated links
4. No official release dates or promises. These pages will track my progress and general plans, but nothing on them will be truly set in stone.

For the time being, Halberd is the only tracked project. As I pick other larger projects back up, they will also be added.

I already use graphs to map out some of my projects in private, so I thought it'd be nice to use them to show progress in public as well. It also lets me keep a public log of my work. I'll be updating the Roadmap page once a week, provided anything on it needs to be updated.

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.

Takeaways

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.