Development Log 10 – Road to Release

I’ve decided not to release this month, August 30th was approaching quickly and the game just isn’t quite where I want it to be. It’s close, so very close, but not quite there yet. I was finding game breaking bugs just about every day so I’m not confident the game is ready for public consumption just yet.

To be honest when I first announced HOBL2 was going to release in early access in March this year I had really just pulled that date our of nowhere. It seemed aggressive but achievable, but to be honest I mostly just guessed at a date. But you only get one first release and I’d like it to go smoothly, so September 30th is now the new official early access release date!

As the date approaches I’ve given some thought to how long and far the game has come. I’ve been working on HOBL2 since October 2014 – at least that’s when I started submitting changes to source control. That’s almost 5 years now, and I was curious just how that work was spread our over the years so I took a look at my source control change logs:

5 Years of Development

That’s the number of commits to SVN per month for the last 5 years. I’m pretty impressed with my own tenacity on this project. It averages 0.89 changes per day, every day, for 5 whole year.

That fits pretty well with my philosophy of working a bit every day on my game. Whether it’s adding a whole new feature or just playing for 15 minutes, I try and touch the game every day. Part-time game dev is definitely a marathon not a sprint. I don’t always follow my rule, but I try and I think the graph above shows that as well.

There are some interesting patterns too – you can see the first month spike of excitement. The drop off in November and December of 2014 is due to my push of final large update to HOBL1. You can see my excitement continue for a couple of months and then start to slow in the summer.

The increase after September of 2015 is due to me taking three months off to take care of my first daughter, and the sharp drop after December 2015 is me starting a new full time job. After that you can see this cyclic rise and fall of effort and motivation over the years.

Finally you can see the show increase from Oct 2018 onward once I decided to enter early access. The drop in March and April 2019 represents a change of jobs and a second daughter. The July spike should be obvious as I switched from slow part-time development mode into ship-it mode for my early access release. August is only half over so I expect it to surpass July’s changes. September will hopefully slow down as the bugs and fixes calm down as I prepare and test release build.

Exciting times ahead!

Development Log 9 – So it’s August already…

Where’s Heroes of a Broken Land 2?

It’s almost ready for early access. I’ve been doing end to end testing, trying to beat a very small game. I’ve been fixing critical bugs and improving the critical UI issues as I go. Unfortunately each time I find a critical issue, such as a bug in save games, I need to start over. So it takes time unfortunately.

The good news is I’m mostly happy with the dungeon pacing and I think the gameplay is fairly balanced at the lower levels so it should be a good base to build on.

Will it be ready in August? Maybe…

I’d rather have a solid first release than make some arbitrary date, so it won’t be released until I think the game is ready for early access. Currently I’m mostly looking for game breaking bugs that will completely prevent progress. If I don’t find any in about a week of testing then I’ll consider the game ready for public consumption.

It will take a week or so before a build of the game would be approved for release by Steam. This means if I’m not happy with the current status of game in the next week or two then it won’t be out for August

Will it be ready for September? Very very likely.

Right now it’s heads down, fix and polish.

Development Log 8 – Core Features

I’ve written about what I think is needed for early access to work and have been steadily trying to complete the necessary tasks in time for an August release. I believe I’m still on track for that time line, but some of my requirements (balance, fun) are very subjective and hard to estimate.

One main addition is the initial party creation screen, up to now I’ve been using randomly generated parties to test. In the real game you’ll be given a selection of heroes to start with.

The last little while has been spend on making the game work as a proper game from beginning to end. This might seem strange to outsiders, but much of game development isn’t done it the same way you play a game. When I add and test new features I rarely start from the main menu and follow the standard flow that a regular player does. I jump straight to a dungeon to test dungeon generation and combat.

This means that during development the standard gameplay flows aren’t getting well tested. This is why I’ve been focusing on testing (and fixing!) for the last few weeks, to ensure the standard player experience is smooth and functional. This involved mostly UI/UX work that’s kind of boring to summarize but actually incredibly important to the player’s enjoyment.

Here’s an update on the general status of the early access features compared to the earlier post:

  • Major systems implemented [95%] -> [98%]. Adding systems like initial party selection have moved this forward, but again most major systems exist and are on track to be ready for EA.
  • Reasonably balanced [60%] -> [70%]. Only a little progress has been made here, tweaking initial damage and monster stats. Lots more work here before this game is for the public!
  • Stable Build [75%] -> [90%]. I’ve been doing lots of testing and making sure broken flows and bugs have been fixed. This is difficult to test as a solo dev on a large game, but I think the game is much more stable since I first announced early access.
  • Playable end to end [50%?] -> [70%?]. General stability and other general fixes have increased this number, but end-to-end testing hasn’t really been a focus yet.
  • Solid procedural generation [75%?] -> [85%?]. Always hard to quantify, but fixes to monster and trap placement and other small dungeon generation tweaks probably increased the overall quality here.
  • Bug reporting features [0%] -> [90%]. As mentioned in a recent devlog a basic bug reporting screen has been added. This is the most important step here: an integrated and easy to access system to report bugs. This is 90% and not 100% because I can think of a few nice features to extent the reporting functionality (auto attach logs or savegames), but they’re not necessary for launch IMO.
  • Fun [75%?] – > [80%?]. Not much has really changed as my effort has been on systemic and UI features, but there have been a number of UI/UX improvements that make the game more enjoyable to play.

Development Log 7 – Progress Update

I though I’d make this log a proper devlog and list a few things I’ve been working on the past couple of weeks. Nothing truly unique or exciting to report, these are mostly tasks to improve overall stability and usability of the game.

Save game functionality is now working properly. This is a pretty fundamental feature, but I’d neglected it for a long time and it had started to accumulate bugs. Maintaining software has a constant tax – each change or addition you make can easily affect another part and save/load basically touches every system in the game.

Balanced dungeon loot. I was feeling dungeon exploration a bit unsatisfying and after some analysis found the item drop rate was too low. Opening a big shiny chest and finding a pile of gold is fine, but if that’s all you get it can feel disappointing. Balancing is a never-ending task, but this makes dungeon delving more rewarding overall.

Candles make even the darkest dungeon more romantic…

Candles are back. Another example of “code rot”, at some point I adjusted how object were placed in dungeons – to prevent them from overlapping – and candles stopped appearing. Finally got around to investigating and fixed the bug. Little objects like this make the dungeons feel less empty and repetitive.

Numerous UI fixes. From making sure you can’t cast a spell while looking at your inventory to just making menus easier to navigate a turn-based RPG is probably 50% game and 50% UI, so this area will be under constant development. For early access there’s minimum usability bar for the game to be enjoyable, I don’t want a player’s first experience to be painfully trying to navigate buggy menus.

Bug reporting. This feature is one of my criteria for launching in early access. No matter how much time I spend trying to find all the issues HOBL2 is a very large game. Especially when combined with procedural generation it be nearly impossible to find all the issues before release as a solo developer. This feature allows the player to send me a report with various game related information so I can re-generate their world and fix procgen issues. I’d like to add a nice way to send save games and engine logs easily too – both are critical for tracking down the cause of bugs.

Looking at my earlier log about early access you can see there’s still quite a lot to do! I’ll be continuing to polish and fix issues as the arise (I have a loooong list of improvements large and small). Next, I’ll be focusing on world and combat balance as well as seeing how many character skills I think I can get working before August.

Development Log 6 – the Tactician and the Sage

Where the Mercenary and Healer are fairly standard RPG skill sets and fill obvious roles, the Tactician and the Sage jobs are a bit more unique. They both focus on more indirect skills and are meant to provide secondary support – either as extra party members or a second or third job. That’s not to say you can’t have them as main party members but that’s probably for more advanced players or those looking for a challenge.

The Tactician learns skills that improve their teammates, helping them act better in combat and in the world. Let’s look at their skills:

  • Rally – An action that cause a single ally’s readiness meter to charge, letting them act sooner
  • Leadership – An aura that improves the party’s effectiveness in battle, increasing everyone’s reaction time
  • Tactical Readiness or Inspiring Speech – An upgrade to Rally so it either affects the Hero too (reducing their recovery) or an upgrade to Rally the make the target act immediately
  • Offensive Tactics or Defensive Tactics – An upgrade to the Leadership aura that give either offensive or defensive bonuses in addition to improved reaction time
  • Logistics – A passive skill that increases movement on the world map
  • Charge! – An action that makes every party member make an melee attack at the same time

You can see the focus isn’t so much on direct damage or healing as much as the Tactician focuses on improving the effectiveness of other party members. These skills make a good addition to any team but still give the Tactician some nice direct actions especially when they learn Charge!

The Sage learns skills that help their teammates learn, but can also learn to use skills by studying monsters. Now let’s look at the Sage’s skills:

  • Research Target – This action is a bit different, the Sage can use this skill and has a chance to learn a monster’s ability. However they can only learn one ability at a time (and can choose to Research another monster to learn a new skill). The skill learned will depend on the monster that was researched.
  • Teacher or Scholar – Choice between the boosting party EXP with the Teacher skill or a boost to the Sage’s EXP rate with the Scholar skill.
  • Disciplined or Enlightened – A one time boost to INT or WIL
  • Monster Biology – Passive skill that makes learning monster weaknesses easier (reduces the number of monsters defeated to learn their stats)
  • Examine Target – Same as Research Target, this skill provides another potential monster skill slot.
  • Knowledge is Power – An Aura that provides a boost to party stats

The Sage’s skills are even less direct than the Tactician’s skills, they help your heroes gain levels faster or let your adapt by learning monster skills. Monster skills are interesting but possibly not immediately useful. If you’re fighting a Fire Elemental you’d be able to learn fire based skills from them, however those skill won’t be very useful against a fire-based enemy. This makes the Sage’s skill more of a long-term investment than other jobs we’ve looked at so far.

These last two update have meant to give just a taste of variety that the new jobs system can add to Heroes of a Broken Land 2. There are dozens of other jobs planned – many of which are sill somewhat undefined. My goal is to ensure that each different jobs bring a unique set of hero skills. More importantly they should each bring a unique approach to tactics and each job should expand on player options while ensuring that no single job is so important that each hero ends up selecting it.

Hopefully a look at the Mercenary, Healer, Tactician and Sage jobs gives a sense of the variety that I hope to achieve with HOBL2’s job system. These are only 4 of the 30+ planned jobs available in the full game. The number of combinations of different jobs should really increase hero variety and help make for interesting choices when building parties.

Development Log 5 – Hero Skills

I’m current working on the save game system, which is mostly making sure you can load and save your game properly. That’s pretty boring to blog about so I thought I’d discuss the new skill system in Heroes of a Broken Land 2 instead.

Heroes will no longer have a single class, instead they will have multiple “jobs”. A job is essentially a set of specialized skills that a hero will unlock as they gain levels. You could also think of this as a multi-class system. Each job represents a fairly narrow progression path, with a few opportunities to specialize and customize as the hero progresses. I gave some reasons for this change in a previous devlog.

We’ll look at two of the most basic jobs in HOBL2: the Mercenary and the Healer. These are two of the most generic jobs in the game so far, most other jobs are more specialized. These roles are so common in RPGs I think they’re make a good introduction to the Jobs system in HOBL2. Note: Skills and jobs aren’t finalized yet, and I expect a lot of changes once play-testing and early access begins, so take the details here with a grain of salt.

The Mercenary’s skill tree looks like this:

  1. Strike – Attack twice with your equipped weapon.
  2. Offensive Tactics or Defensive Tactics – passive boosts to the Hero’s Attack or Defense stats.
  3. Critical Strike or Quick Strike – passive boosts to the Strike skill, either increasing critical damage rate or reducing recovery time when the Strike skill is used.
  4. Weapon Training or Armour Training – passive skills that reduce the requirements to equip weapons and armour.
  5. Veteran Aura – aura’s are passive boosts that affect a group, in this case a Veteran Mercenary provides a small boost to their allies combat stats.
  6. Whirlwind – Melee attack that targets all enemies for multiple attacks.

The Mercenary shows a basic pattern that all jobs will follow: Unique actions such as Strike and Whirlwind, choices between skills at certain levels like choosing between Weapon or Armour training and skills that modify the behaviour of existing skills such as the Critical/Quick strike skills

Let’s look at the Healer’s current skill tree:

  1. Heal – Restore health to a ally
  2. Shield – Increase the defense of an ally for a time
  3. Improved Heal or Mass Heal – Skill that modifies Heal to restore more health or heal the entire party for a lesser amount
  4. Defensive Aura – Passive aura that increases the defense of your party
  5. Reinforced Shield or Mass Shield – Skill that modifies Shield to increase defense more or affect the entire party for a lesser amount
  6. Resurrect – Bring a Hero back to life

Again you can see the similar pattern to the Mercenary – unique action skills like heal, specialization with choosing Improved Heal vs. Mass Heal, and more powerful skills at higher levels. This forced specialization is meant to enforce the need to multiple heroes and to build parties to deal with specific encounters and dungeons.

In the next installment we’ll look at two more interesting jobs the Tactician and the Sage.

Development Log 4 – Road to Early Access

Now that I’ve announced HOBL2 will be coming out for early access in August 2019, I though it would be a good idea to list what needs to be done before the game is actually ready for the public.

This is a pretty high level feature list that needs to be done before the game’s ready to go on Steam. I’ve broken it down to three basic categories: critical must have features, important features that should be there but can be added later if needed and nice to have features that make for a better experience but don’t make or break a release.

Many of these features are pretty vaguely described because I don’t want this post to be a 100 line point form list of programming tasks, but instead a view into what I consider an acceptable quality and completeness metric for entering early access. I threw in a % at the end to give and idea of how far along each group is before being ready for early access. The numbers are mostly guesses rather than objective measurements.

This list is also not the list for release of the full game. Pretty much everything mentioned is a key feature for the full game and must be done before the game can be considered complete. The list for the full game is much longer and will also evolve and develop during early access.

Critical Features

  • Major systems implemented. Worlds can be customized and generated, heroes recruited and parties created. Towns can be updated, building built, equipment purchased. Dungeons can be generated, explored and looted. Combat can be fought and won or lost. The core of the game should function and early access can be used to iterate and expand systems rather than implement them. [95%]
  • Reasonably balanced. You shouldn’t die at the first encounter you meet nor should you cut through every enemy you find. The balance won’t be perfect, there will still be exploits and certain unbalanced encounters and builds, but these should be rare. [60%]
  • Stable build. The game shouldn’t crash. I won’t say never crash, and I won’t say bug free but you should have a reasonable expectation that you can play the game for a decent amount of time and it not break. [75%]

Important Features

  • Playable end to end. The game should be complete-able from start to finish. The quests may be limited, the game may not always be fun and there might not be a end game screen but you should be able to make it to the end of the game. [50%?]
  • Solid procedural generation. Generated worlds and dungeons should basically just work and produce interesting, balanced and functional spaces. This is hard to do just because of the sheer number of possible combinations, but it’s important because HOBL is based on this generation. [75%?]
  • Fun. I’d like the initial release of HOBL2 to be fun to play, even if it’s limited in content it should be fun to play the game, loot dungeons and do many the things you’ll do in the full game and enjoy it. This requires most of the features above to be working well plus enough polish to make the experience smooth. I’d like the early access to feel like a game that’s building up rather than some janky early alpha test. [75%?]
  • Bug reporting features. I’d like to have some in-game way to report issues and bugs easily and quickly. HOBL1 had a bug report button that was a good idea, but it wasn’t that great to use. For early access I’d like to have a system that makes it easy to report issues without making either me or the reported do extra work. [0%]

Nice to Have Features

  • UI fully skinned.
  • Cloud saves.
  • All hero Jobs implemented.
  • Multi-party dungeons.
  • Interesting amount of quests.
  • Varied amount of monsters.
  • Equipment and modifiers defined.

Not Planned For Early Access

There are still many features and content that won’t be part of early access until much later: non-windows builds, most monsters, most dungeon types, non-human heroes, non-human towns, music and really almost too much to list. Most content creation will happen during the early access period.

In Summary…

I hope this post give a bit more details on what to expect later this year, and hopefully lets future players set their expectations for early access appropriately.

The last few development logs have been pretty focused on either HOBL1 or some vague high level goals. In future posts I hope to look into more specific development issues and progress. Stay tuned!

Development Log 3 – How to fix Heroes of a Broken Land

So I’ve discussed how I think Heroes of a Broken Land 1 was a decent somewhat innovative game but flawed in a number of ways.  I’ve also discussed weather HOBL1 was a financial success or not. Now lets look at how I intend to address these flaws and make Heroes of a Broken Land 2 a much better game than the original.

Procedural Generation

Heroes of a Broken Land 2 will still be a procedurally generated game. Each game will have a different world, each dungeon will be new, it’s a core pillar of what makes Heroes of a Broken Land what it is.

However procedural generation is both a blessing and curse.  It allows you to generate nearly endless variations of worlds, dungeons and monsters. However it can also generate very similar content, and if not careful the content can be too random and generate spaces that aren’t designed for the game at hand.

This was a major problem HOBL1’s procedural generation is it was too random. The short explanation is HOBL1 generated mazes and then tried to put interesting content into these mazes. Sometimes this worked, but more often than not it just generated some sprawling random mazes filled with monsters.

To overcome this flaw in HOBL2 we first generate a graph that represents to flow of the dungeon. This ensures that each dungeon has a logical progress, a flow from start to end. It also allows dungeons to be quest driven and designed from a high level, while letting the procedural generation fill in the details and physical layout of the dungeon.

The main world will also be generated in an similar way, as a series of connected fragments you travel through instead of a large single map. This should improve the feel of progression through the word and allow for more variation in world generation.

Another way I plan to augment the procedural generation is with the ability to weave custom content into a larger procedural world or dungeon.  I’ll have more to say about this in future posts.

Better Quests

HOBL1 suffered from a poorly implemented quest system. Simply put it was difficult to author quests for technical reasons, and so the game simply didn’t have many different quests. This led to basically performing the same dungeon crawl over and over, which can be fun, but it obviously repetitive.

Fixing this has been a personal priority. HOBL2 will have an entirely re-written quest system that allows for much more variation through a custom scripting engine. The new system is so much more powerful that essentially the world generation is based on the quest system. The quests define the higher level game world and progression and the procedural generation systems will fill in the detail.

This new quest system will be also covered more in future development logs as I have a lot more to say about this and it’s critical to many of HOBL2’s improvements.

Character Development

Heroes of a Broken Land is all about heroes: recruiting them, customizing them, upgrading them and adventuring with them.

HOBL1’s flaw was that heroes converged to generic adventurers. That goes against the theme of recruiting teams of heroes to tackle dungeons. Instead you just kept the same heroes and increased their power and abilities to handle any situation. To address the heroes need to specialize rather than generalize.

This required a re-design of the whole class and skill system. Heroes will no longer have a single class, instead they will have up to 3 “jobs” (the name may change). Each job provides a mini-skill tree that evolves as heroes gain levels. The main reason for this change is to make each Hero more distinct, as heroes gain levels they will get more powerful but also more specialized. This will encourage different skill and job selection as well as make the use of multiple heroes more desirable.

From a player perspective this opens up many more interesting character builds, encourages a more diverse hero pool and rewards trying new combinations of jobs to explore hero potential.

More Time to Polish

Any and every game can use more time. While developing HOBL2 part-time means it does take longer to get things done, it also reduces the pressure to release the game by a set deadline and allows more time . That doesn’t mean HOBL2 will be in development limbo forever, it just means it will get the time it needs.

I plan to have the game in early access for about a year, adding content, fixing bugs, polishing the experience and most importantly getting real player feedback.

Future development logs will show the current state of the game and focus on more specific development tasks that I’m working on.

Development Log 2 – Was Heroes of a Broken Land a Success?

After breaking down what I think was successful and what wasn’t in HOBL’s design I’d like to take a look at whether HOBL1 was successful as a product. Regardless of how I feel about the project personally, it was meant to be a profitable game that would enable me to work as a full time indie game developer. The simple answer is that HOBL1 didn’t enable me to do so and therefore HOBL1 was a failure as a game product.

I still think it’s interesting to look deeper into why and how it was a failure, because it’s not as simple as “not enough sales”. I also think these stories help inform other indie developers and can help future developers know if a project will be successful or not.

Show me the money!

Let’s get right to the point: Heroes of a Broken has earned $62,039.10 Canadian Dollars in net revenue since it was first available for pre-purchase in April 2013 (it was officially launched in January 2014).

This is number after the resellers (such as Steam) take their cut, but doesn’t include development expenses. Development expenses were about $6,000 to $12000, the exact number depends on whether you want to consider direct expenses only (art & sound) or other stuff like business setup costs, software, hardware, etc. These expenses do not include my time or living expenses. This results in income just over $50,000 CAD.

Where did the money come from?

Sales by Platform

You can see that Steam pretty much dwarfs all other sources. I find it interesting that direct sales are #2 given my lack of marketing or advertising my direct sales channel very well.

My records show 12,454 copies of HOBL1 sold in total.  Steam’s current numbers are 15,240 total copies, with 10,715 being direct Steam sales. The rest (4,525) are Steam key activations, most copies sold outside Steam came with a Steam key. The average price of a copy sold was $4.98, about a third of the $14.99 full price of the game.

What’s the problem then?

Now $50,000 isn’t terrible money, it’s an okay income in many places.  If I lived in rural China I’d be pretty wealthy!  However where I lived at the time (Toronto) the average family income is $82,859.  So it’s not a great income to support a family with, but a decent income as a single earner. It’s much less than I’d make as a full time programmer at a game studio, but given the freedom it might be worth the pay cut.

One obvious issue is this is $50,000 over 5 years. Now that doesn’t sound that great anymore. I had set aside about one years of living expenses to develop this project and it had taken a full year to make, so I was running out of money by the time HOBL1 launched.

Lets take a look at how the sales were distributed over time:

Sales over time

Wow Steam is a big deal, isn’t it?

It took almost 8 months from the launch day until it was available on Steam. Back in the day (early 2014) not every game was simply made available on Steam. There was a curated queue of Steam Greenlight games, and at the time only a few dozen would be added each month. So while sales picked up a lot once available on Steam, it took a really long time to get there.

2 months after launch you can see the income drops to almost zero. When your development funds have been spent and your sales dry up, you’re not left with a whole lot of choice. This type of cash flow problem is common for small businesses. At this point I decided to stop full time indie development and started looking for a job.

Lessons to be learnt

I don’t have any regrets about how HOBL1 went – I’m happy with the game, and I never expected my first full time game attempt to be a giant success, but I did hope it would be able to sustain me while.

Looking back I sometimes wonder, did I do something wrong? Could I have done something differently? Had I known HOBL1 would have done that well on Steam, would I have held out? Who knows. The past is past and the industry changes too fast for the specifics of launching my now 5 year old game to matter much.

What did I learn from this? A million small lessons in business and game design that are hard to summarize in a blog post.

Nevertheless here are some quick TL;DR points on why HOBL1 didn’t make me rich and what I could do better:

  • HOBL1 wasn’t cool enough to be picked up by social media.
    • This is a combination of developer story (I’m boring), look of the game (it’s not terrible, but not amazing) and lack of exposure (I was new to the indie dev scene, nobody cared about me or my games)
  • HOBL1 is in a poor market that will never (regularly) see great success
    • Turn-based first-person dungeon crawlers died 20 years ago. Legend of Grimlock was a fluke not a rebirth of the genre.
  • I suck at marketing and new to entrepreneurship
    • You can’t ignore it and you can’t ignore advertising even if you don’t want to do it
    • Creating HOBL1 in the first place is proof I suck at marketing because I chose to enter the minuscule market that is retro first-person dungeon crawlers
  • Don’t spend 12 months on what should be a 6 month game, it’s bad for your wallet

What does this have to do with HOBL2?

Quitting full-time development is the main reason HOBL2 has taken so long come together. Part-time development can be a very slow process, but full-time development is too expensive and risky for me to want to attempt again at the moment. As long as you are patient and tenacious enough part-time is much less stressful.

Since the numbers from HOBL1 aren’t terrible, and there seem to be a reasonable number of people who enjoyed the game, I think a sequel has a chance for success. I feel if the game was a bit tighter, more polished, marketed and available more widely from day one it could have been successful. I hope to take my failures with HOBL1 as lessons learned and apply them in HOBL2. However the indie game scene has changed so much in 5 years it hard to say what lessons learned are still relevant.

But Enough about money, the next post will be about how I plan on addressing the design issues from HOBL1 in HOBL2.

Heroes of a Broken Land 2 – Development Log 1

I’m  planning on discussing the development of Heroes of a Broken Land 2, covering the various design decisions that go into the game, the work that’s already completed and future development plans.

As this is a sequel I thought I would devote the first few posts to Heroes of a Broken Land 1. Specifically what I think went well, what I think didn’t go so well, and how I plan on addressing the flaws on HOBL1 while keeping the sequel true to the goals of the original game. Let’s start by looking at what I think did or didn’t work in the design.

What went well

A retro blend up of strategic town building, exploration and turn-based dungeon crawling in a procedural world.

Genre Blending

I think the high level design – strategic world map with town building combined with retro styled dungeon crawling was a good overall design. I think I pulled off the mix fairly well, providing a nice break between dungeons with world exploration, and controlling character development through town building gave the player a good feel of progression and control. I think multi-party dungeons also brought a unique twist to the game the few dungeon crawlers have tried.

Simply put I’m pretty proud of the game as a whole that was developed. I think it was innovative and interesting and am personally quite happy with what I was able to accomplish as a solo indie developer.

Streamlined Gameplay

While HOBL1 was inspired by the “games of old” I wanted to modernize the interface and remove tedious time sinks. Some examples of this are the global inventory, shared between multiple parties to avoid the tedium of returning to town after each dungeon. The auto-movement and auto-exit dungeons when cleared options from the mini map helped remove some pointless activities.

I tried to not waste people’s time so they could focus on the fun and interesting parts of the game. I think I achieved this and kept the “retro” feel while modernizing the UI.

Combat Pacing

I think I nailed the combat pacing.  For the most part battles were quick but deadly, you had to think about your next action, but not too much.  I knew there would be lots of combat in this game and I didn’t want each battle to become a long slog.  This also carried over into the decision to have almost all attacks auto target based on player and monster position.  That decision was a bit divisive, but I think it worked out well and kept combat moving fast.

Main Gameplay Loop

Basically the following sequence of activities was fun:

  1. Explore World
  2. Find Dungeon
  3. Loot Dungeon
  4. Upgrade Town
  5. Upgrade Heroes
  6. Repeat

Each activity wasn’t too long or too tedious or too complicated. This was core to making the game engaging and was really the result of hundreds of small design decisions made through development.

What didn’t go well

Mid/Late Game Balance

A lot of what I think went well above started to fall apart later in the game. Some of the fundamental rules and mechanics didn’t scale properly. Monsters got stronger faster than characters, this worked at lower levels because hero equipment would even the stats but equipment stopped scaling too early. This wasn’t the only issue, melee didn’t scale as well as magic making certain builds weaker over time. The result is the pace slowed down at higher levels, which wasn’t intended.

The whole class system kind of fell apart too. Letting heroes learn any skill via skill books was fine, it’s fun to upgrade your heroes. However letting heroes to learn any skill without limitation basically broke the class system where eventually you could afford to learn any skill for anyone. This meant that as heroes increased in level they tended to generalize rather than specialize.


The game is quite repetitive.

While the individual steps of the gameplay loop were basically fun and well tuned you still repeated them a lot, and they didn’t really change that much. A patch released about a year after the launch of HOBL (version 1.10) brought a ton of new monsters and some other content reducing the obvious repetitiveness of fighting 100 rats, but really if you played enough you’d have seen everything eventually.  Many other games do have this same issue, and if the core gameplay is engaging enough this doesn’t really matter, it’s still less than ideal and detracts from the overall experience.

Procedural generation was meant to help reduce the repetitive feel by creating unique worlds and different dungeons play.  But at some level it’s essentially generating more of the same. Some fault lies at the limited content – there were only 3 or 4 types of dungeon art, so everything was bound to look similar, but the generation algorithms were limited and were basically generating very similar mazes each time.

Quests and Narrative

HOBL was a very mechanical game. There wasn’t much story other than the intro and a handful of quests. Sure there were some special dungeons and a few unique encounters, but they didn’t really show up until the endgame.

Without a higher level narrative or even strong theme tying together much of the game it can make much of the gameplay feel pointless to the player.  Sure, there were some limited world events (little stories and mini-quests) that would pop up and provide some text and such but they were also quite limited. Almost all of these quests ended up as a “go and kill everyone” dungeon crawl. There were some reasons for this, some technical and some due to limited time and resources, but ultimately the reasons doesn’t matter: Narrative was a weak point of the game.

The unfortunate result is much of the gameplay loop lacked any non-mechanical purpose. No plot progression, no character revelation, no unfolding story. For many people that play RPGs the story is a big part and HOBL1 failed to deliver in this regard.

Game Length and World Size

So one nice thing about a procedural generated world is you can make it any size you want. One of my original goals for HOBL1 was to enable the creation of small game so you could finish a complete RPG in a a 4-6 hours instead of 20+ hours. The problem with this goal is I never really tested it until most of the game was completed and I was happy with the pace and core mechanics.

Then I tried a small map.

10 hours later I had to go to bed and was nowhere near completing the game. Not even close.


So that was a total failure.

Sure if you like 20-100+ hour games HOBL can still be a great experience, but the start-to-finish pace was totally broken. It was also at that stage in development almost impossible to fix without re-doing so much work, especially since I was quite happy with the dungeon crawling and combat pacing.

Also, I’d like to point out that if you’re a solo game developer testing a game that takes 20 hour or more to complete is a daunting task.


So that’s enough rambling for now.  Next post I’ll discuss whether I consider HOBL1 a success or not, and talk a bit about it’s development highs and low and even the almighty $$$