Well, it has been 2 1/2 months in the making. But today, Halberd has reached its first milestone!
Video captions can't really convey how happy I am to see this happen. I've been thinking about Halberd for years now, and it's great seeing it take its first step.
Granted, I still have massive amounts of work to do, but this still feels special regardless.
MVP, or Not?
One thing that I've been struggling with is figuring out what an MVP actually looks like, in the context of an RPG engine. What features are required for such a tool to become 'viable'? Where do I draw the line between wants and needs? I've generally tried to stick to as minimal a definition as possible, but such a definition is probably not what a user would actually expect. It's a tough balance.
In the end, I've decided to go with a little cop-out: The next milestone is what I'm referring to as my 'AMVP' (Absolute Minimum Viable Product), and the next one is the 'True MVP', with additional features and polish that your average user would likely expect as their minimum. I'm still figuring out the details of the latter, but my current benchmark is Dragon Quest 1 (a.k.a. Dragon Warrior). If Halberd can do everything that game can (minus some polish and a few of the more specific features like torches), then I feel like I can more confidently proclaim Halberd to be a viable (if bare-bones) engine.
After that? Who knows! Once Halberd has reached a usable state, a lot of potential avenues will be open to me. I'm probably going to keep finding progressively more varied and complex games to compare against, and mix those features with quality of life updates.
Whatever happens, I'm excited to see where the project goes next!
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:
There's very little room for 'soft' failure states. For obvious reasons, messing up your movement always means death.
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.
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.
Today, I'm doing something a little bit different: I've created a video for this update!
Additional Comments
It has been a while since I last posted any videos, and this is my first attempt at making something more detailed than a simple playthrough. In my opinion, the result is ok. I think it was a pretty good decision, given that I mostly worked on graphical stuff this month.
The video contains an overview of the update, but I wanted to add a couple of details that didn't make it in:
Axis inputs received a few changes that I didn't mention. First of all, they are no longer 2d. Each axis is independent. They're also missing the "joystick emulation" input smoothing at the moment. I'll be adding that back at a later point.
I've made a ton of bugfixes this month. There were a lot of things (especially in the core module) that didn't quite work, but testing them didn't seem worth doing until I had an actual use for them. Now that I'm building demos, I'm running into the issues and fixing them naturally.
Lastly, I've written a bunch of macros for printing out certain structs to logs. This makes debugging much easier, because I can quickly print out the value of a matrix/vector/quat with little effort.
Goals
Let's start with the current state of the project:
Time left: about 3 1/2 months
Application Module: Done
Audio Module: Not Started
Core Module: Done
Editor Module: Not Started
Gameplay Module: 80%
Missing joystick emulation for input
Graphics Module: 40%
Missing sprites
Missing text
Missing framebuffers
Missing particles
Math Module: Done
Resource Module: Not started
I'm making pretty good time right now. My goal for May is to knock out the Audio and Resource modules, which will leave me a couple months to reimplement the more advanced graphical features and make API easier to use. I've decided not to bother with the editor module for now, because it won't be useful for game jams and concept work. Instead, I'm going to work on it after the deadline has passed.
Next week, I'll be unveiling a new schedule and discussing my forays into Taskwiki in more detail.
It's been a few weeks since my last capstone post, and quite a lot has happened! Last week we finished The Last Light and presented it at the senior show, and it got a pretty great reaction all around. Even better, the game got several Let's Plays after we put it up on itch.io, and the overall reaction seems to be pretty good.
By the way, you can download the game here:
(Sadly, it's Windows only right now. I might see if I can put a Linux build together at some point though)
Now that the dust has settled, I thought it might be a good time to go over some statistics from the project. I got a few requests from fellow team members, and also wanted to do some things myself, so here we go:
(Please keep in mind that these numbers are estimates pulled from hastily-constructed git queries. They should be close to the right number, but may not be perfect)
Total Number of Merge Conflicts
When dealing with teams that have more than a couple of members, it's only natural that at some point, merge conflicts are going to happen. This problem becomes even more common when your project consists mostly of binary files that can't be merged normally. We certainly had our fair share with 122 merge conflicts resolved.
Floor_400x400
For some reason, a random unused asset from the UE4 starter content folder, Floor_400x400.uasset, kept getting marked as changed. My team was curious how many times it got 'updated' in git. Apparently, 60 times. That's about once every other day!
Substance Plugin Kill Counter
Unreal really loves the Substance plugin. If your machine has it installed, Unreal has a habit of quietly slipping it into your project when you're not looking. Then, everyone else on your team gets a little popup saying something along the lines of "This project requires the Substance plugin. Do you want to download it now?"
Naturally, this message is a tad irritating, so we tended to go into the project file and purge the plugin. We did this 34 times, in fact. That number actually seems remarkably low, but I think it's because we didn't always remove the plugin immediately if we were busy, so sometimes it would stick around for a while.
Total Number of Binary Updates
Have you ever an artist to go compile some code? It's not pretty. Although Unreal makes compiles pretty easy, we programmers made a point to include the compiled binaries in git so that our fellow team members could spend less time compiling and more time developing. This happened 96 times.
That's it, but hang on to your seats, boys and girls! It's time for.....
Uncle Huey's Repo Analysis Awards
The "Biggest Git" Award for Total Commits
Let's start with a simple one: Who made the most commits overall? It was a close race, but the winner is: Chris Johnson, with 292 commits Second place is Vincent Loignon, with 288 commits. Simple, right? On to the next category!
The "Man of Mystery" Award for Commits under an Alias
Not everyone keeps to a single name, especially when jumping from computer to computer. This award is for the person who made the most commits under a non-name: Jesse McKinley, with 122 commits listed as 'Dekeche'
Second place is Hugues Ross (me), with 121 commits listed as 'DF458'
Looks like it's another close one. Next!
The "Fashionably Late" Award for Latest First Commit
You know what they say: The early bird is a total loser. This award goes to the person who was the last to start making commits to the repo. Who won? Why, it was: Paul Scardera, who first committed on April 13th
Second place is Kyle Patterson, who began on April 8th
I think it's important to mention that these awards are meant to be fun, and that this isn't any sort of condemnation. Paul and Kyle are both producers, so they only joined in with direct development at the end to help with 11th-hour grunt work. They've been super helpful throughout the project, just not with commits.
And speaking of strange awards...
The "Writing is for Losers" Award for Most Commits Without Changing a Single Line of Text
Git keeps track of how many lines of text were added, removed, or changed in text files. This award goes to the developer who made the most commits while maintaining a perfect 0 in all of those categories. Let's hear it for: Paul Scardera, with 7 commits and 0 lines
Second place is Scott Beecher, with 6 commits and 0 lines
Again, be nice, not everyone's work is represented by commits, yada yada.
Now, time for the final award:
The "Who's That Pokemon" Award for Most Enigmatic Team Member
Among the huddled masses of our Slack channel, there are rumors of a secret developer, spoken of only in hushed tones, working from the shadows. Who are they? Where did they come from? No-one knows for sure. Of course, I'm talking about: Unknown, with 18 commits
Yeah, so someone probably just forgot to enter their name into git before committing. Still, it's good to have fun with these things, that's what the awards are for!
Actually, I just double-checked and apparently it was me all along (with one commit from vince). Whoops!
Project Development Visualization
All this text is pretty boring. Thankfully, I have a solution to that problem. In addition to all of these stats, I also have a visualization of the project's development, starting from February (Fullscreen viewing is recommended):
This video was made with a super-cool tool called gource. Go check it out!
So I said that I'd start making Youtube videos of the games I make, and here's the first:
Sorry about the poor video quality. I'm still getting all of this set up, and future videos will be in higher quality. I plan on getting some footage of Diamond Rush! and A Wheelie Good Time up within the next week or two.
