It’s been an exceptionally long time without any communications and I deeply apologize for that. A lot of things have been going on.
TL; DR: Hegemone Pass has restarted development since the beginning of the year… but it was for the best, since we’re now working on a game that we’re liking a lot and progress is SPEEDY, EFFICIENT and
ON-SCHEDULE. It runs on Heaps.io, a 3D engine: the game will use the 2D aesthetics for the characters (2D sprites) and environment (textured models) but play and feel like a 3D game. We won’t make the June 2020 release date from the Kickstarter, but it was unlikely given the timeline of events since then. It is also being developed simultaneously on PC and for one console, and for only one console until release.
So, what happened during this… year-long absence?!
A Timeline of Events
Let’s go back to the start of these events, the failure of the Kickstarter campaign.
|June 2019||The game’s Kickstarter was a failure. Of course, the first thought that came to mind was that it was just “unlucky”. But deep down, something did feel wrong about the game. |
Instead of pursuing the course (and vision) set by the Kickstarter, we chose to reflect on the game and start experimenting with many, many, many different concepts.
So, here’s one example of the many battle systems that we iterated on: one that focused on managing a large party and being able to position them “anywhere” on the timeline. Not everyone could act in a single turn due to every action using the party SP that regened at the start of each turn.
And scratch that, because a week later, this turned into a timed-based affair where you selected any character on the 9×9 grid by holding the directional stick, and pressing a corresponding ABXY button to an assigned technique of theirs.
Then, we experimented with various kinds of… mechanics.
We had a fog of war, an alignment system, choices, collectable/disposable allies, objectives and side quests within a mission, a chain of eight characters following you around…
Throwing all kinds of ideas, just to see what would stick and what wouldn’t.
Nothing stuck (other than some lessons learned).
During this time, the battle system was iterated about 5-7 times: some were alterations, others were complete make overs.
|September 2019||One of the last battle systems that was being conceived was an platformer battle system in which you’d be able to freely move on a flat stage, restricted to your party’s area, with the usual platformer controls, and there were turns: when it was your turn, after choosing your action, you’d be able to siege the enemy side’s area and use the techniques will the foes would try to dodge your attacks in real time by jumping. This was a failure. At this point, the code base was heavily modified to have code from all kinds of changes where it was hard to work with.|
I could have reverted the changes with git, but for some reason, I just avoided the project. It was left in the dust. IRL work was picking up and was a big source of stress during this time.
Hegemone Pass was ready to be considered abandoned, until…
|October 2019||One of the two console makers mentioned in the Kickstarter sent me their devkit, despite it being a few months since our last contact (I’ll tell you the console after it gets “officially” announced).|
It’s weird what a devkit can do to you. For some reason, suddenly, I was pumped to get working on the game again.
But then the codebase issue came up again, and even after reverting to the Kickstarter codebase, something was wrong. To keep it brief, the code was not playing nice. Weird and frankly frustrating bugs started appearing, and it was clear that the game needed to be reset to zero, take key elements of the code that worked and re-write the rest with some experience.
|November 2019||With the opportunity for change, I’ve decided to look at other engines, and more particularly, other engines using Haxe, since I’ve gotten quite familiar with it.|
One day, I decided to try Heaps.io. At the time, I hated it, for it made no sense to me, it didn’t hold your hand, or even having an understandable documentation to go with it (I read somewhere it was considered “spartan“, maybe it was on the GitHub or the forums, but I forgot, but that’s a badass way of calling a game engine).
So instead, I made from semi-scratch a different version of the game in HaxeFlixel, reusing the usable parts of the code, and creating from scratch the broken parts. We ended up with a smoother battle system that was purely turn-based, but the purest of pure turn-based, with no bells or whistles. But one thing was for sure, standard turn-based combat was the way to go. (And I liked the battle animations, they were smooth and full of tweens). But the field gameplay felt horrible and boring to play. Worse of all, the game refused to run on the devkit (for… several reasons ^v^).
So, I looked back to Heaps. Porting it to the console was, to put it bluntly, a breeze (after the initial setup hurdle for an inexperienced developer like me). And it was the only option to go forward.
|December 2019 – January 2020||IRL Work was the worse in this period, for it was the most intense this season. It was quite hard to sleep and I had truly little free time for the game.|
During the little free time I had, I started working out the 2D engine.
No good, when it comes to 2D, Heaps will not hold your hand: HaxeFlixel is your best friend to get a 2D game running without thinking of physics, collisions, and a camera system… Try as I might, it was going to be hard to do platforming without a ready-made camera. And doing so much of the level collisions on my own felt a bit intimidating. I got to the point of doing basic (and broken) collisions with tiles from a level from a Tiled Map, but I don’t even want to talk about the physics of it all.
2D was not the way to go. So, let’s use Heaps’ more developed (and cooler) engine, the 3D engine.
So, I’m going to have to model… everything…
So, I made a model. It’s not too great, but we’ll do it from a top-down perspective, we’ll go with a low poly trend, and splash a bunch of shaders to mask the flaws-
Oh, Blender 2.8’s FBX export of the animations is totally rejected by Heaps.
Well, any animated model is now out of the question.
So, we return to sprites?
(Good, because I’m bad at 3d animation)
|March 2020 to now…||The epidemic that hit the world forced me into confinement. I lost my job because of this crisis, but I’ll manage (for now). But in a weird way, I’ve been at my most productive in this crisis.|
A lot of features are already in the game, including but not limited to: exploration, npcs, cutscenes, battles, battle cutscenes, attack choreographies, menu system, a huge chunk of the database’s fields, levelling up and enemy loot, smooth tweens on all the UI, and, most importantly, a purpose for the game.
As it turns out, working on the game has become more fun than it has ever been. Something about being able to move your character in a three-dimensional space, with analogue movement, and being able to jump on about anything, feels satisfying.
We’ll be keeping a lot of information secret until the time comes for an announcement, but in the meantime, here’s what can be promised or is already cemented in stone:
- The battle system is a purely turn based affair like originally intended. No timelines or weird shenanigans.
- Exploration is in 3D and you are still able to jump.
- The game is going to be linear, but with some room for exploration on the path. However, the game is not divided into missions anymore, and you are always moving in one way or another.
- The story is a much more refined version of the story that was being advertised: it is also a bit less direct about things.
- The sprites are not billboard sprites. Billboard sprites are the sprites that automatically rotate based on the camera to always be facing you. While it does make the characters look flat at certain angles, the advantage of not using billboards is that… it makes the game feel like a 3D game.
- There will be camera work for the exploration that acts more like early 2000s 3d cameras, with fixed areas the camera is allowed in and giving no manual control of the camera. This lets us cheat on environments and allow us to keep the sprite illusion possible, since we can also determine the rotation of the sprites to adjust to the camera. Playing with a 3d camera is so much fun.
- The leader system, stealth, flowers, and other unneeded mechanics have been removed.
- We did something unconventional (but still traditional) with the stats allies and foes have, which affects how the battles play out, and solving a key issue some JRPGs can have. Hint: Simplicity is getting rampant out there, oversimplifying every little “hard” edge, so we went the other way, while making sure it’s simple to understand. It also creates strengths and weaknesses for each character and foe.
- There is no more weakness/resistance system, at least not natively, for it deteriorates the battle experience and restricts your freedom by punishing suboptimal play and enforcing a specific way to play.
- But there is a hidden weakness/resistance system, and it is tied to the stats we mentioned early: it does not affect anything, and there isn’t any weakness/resistance specific code in the game. It is purely in the game design, and not forced.
- Each character has their own MP now, but we solved a problem regarding making battles fun and interesting, without it devolving into who can spam the strongest move every turn. This solution also affects the enemy team.
- Each character has their own level and experience now and is not shared anymore. Shared levels and EXP are a nice quality of life improvement, but are not compatible with our next design decision…
- There is now a talent system that is a bit like Heroes of the Storm, specifically created for each party member.
- We have kept the 1UP system.
- Characters have HP, MP… and Armor Points.
- Cutscenes in 3D are more engaging than in 2D thanks to being able to have some actual camera work.
We’re going to stay quiet for a bit more time. While a lot of things are now set in stone, a lot is still early in development.
With this latest version of Hegemone Pass, we’ll be embracing more of the traditional console RPG experience, with slight changes to keep it unique. No more changes to the direction. Promise. We’ll be seeing it through to the very end.
Random Closing Thoughts
I’m not sure what to write, so here are some random thoughts about the new development procedure.
- Modelling props is surprisingly easy (when you are used to Blender), especially when using Sprytile, since it deals with the hassle of UVs and tiles for you…
- …but Sprytile is not your friend if you want to build anything that tiles for performance, like a flooring, since it creates four vertices (minus adjacent tiles that it merges the vertices with) per tile. Ideally, I’ll need to get a tiling shader on a flat plane done.
- But I’m grateful that Sprytile exists because otherwise I would not survive dealing with UVs.
- Using HIDE IDE, the all-in-one editor for Heaps.io, is extremely useful: it has a level editor, a particles editor, a model viewer, an FX editor, and a Castle DB database editor, all this while being rendered using Heaps itself, so that what you do should look 1:1 from editor to game… Assuming you know what the saved values you need to pass from editor to the game correspond to.
- However, since it lacks documentation, looking through the source code whenever you don’t understand something is crucial. For example, did you know you need to press CTRL to add a keyframe in the FX editor? Or that the spotlight only works in the PBR renderer?
- Since Heaps, Hide and CastleDB are all made by the creator of Haxe, the source code has some cool tricks in the code that one can learn from.
- Strangely enough, Heaps has a Tiled level importer built-in, but you’ll need to parse the l3d files from the Hide Level editor by yourself (but don’t worry, they are JSONs).
- If you have a Haxe project using CastleDB, don’t go parsing the data yourself and just use the macro. It is incredibly useful.
- The Hide IDE version of CastleDB can export localization strings from any text that has been labelled as localizable into an XML, which is quite handy. I still need to go and parse that data, but I’ll do that later…
- Don’t make your skybox cast a shadow: if you’re asking why your directional light isn’t casting shadows properly, that might be reason.
- If you are going to use Actuate, make sure you edit the code to make it run at the framerate of your game… For some reason, it defaults to thirty frames per second in non-OpenFL projects.
- A mostly pure white sky for the Asphodel Meadows is not easy to work with for the PBR environment.
- Hide IDE behaves better using the basic renderer on my graphics card: using PBR, opening certain prefabs or maps after opening another will simply crash all the 3D engine views in the editor.
- I’m grateful for all the features HaxeFlixel has built-in, but there is a satisfaction in rebuilding the tools you once had all by yourself.
- I switched from an Android phone to a second-hand Lumia 950. With a less attractive phone, I’m more focused on my laptop than using a phone that takes my attention away. And besides, I also installed the Windows on Arm project, and despite its slowness on the standard 950 due to the CPU not being fully functional, I was able to install Haxe, VS Code, and in theory I could code even on my phone with a Bluetooth Keyboard and mouse.
- Visual Studio Code is surprisingly good with the Haxe extensions! I much prefer it over HaxeDevelop.