Project Hornet

It has now been three months since I started out with my decision to learn making videogames. Since it was clear from the start that little, if any, actual work with Godot would be done during peak season at work and while looking for a new apartment, the game currently existing only as a bunch of scribbled notes is still right on schedule. But moving into my new place is now planned for late June, and I'll be taking my summer break in July. After which I'll be going from a 48-hour work week to a 35-hour week.

Very excited about finally taking a crack at learning the most fundamental basics of Godot. And then, eventually, getting to the point where I can start attempting a first prototype for an actual game. Though I have to say, I've already been having a blast for the last three months working on just a general concept for what kind of game I want to create, and how it's roughly going to look and play like. I very seriously considered for a long time making a small, first person, open-world RPG like Morrowind with strong influences from Thief and System Shock 2. But ultimately decided against that because that plan, while probably feasible to pull off, could well commit me to working on one game for something like 10 to 15 years. I think I would much rather be able to make a small game every two or three years, get it out to people to play, and then apply everything that I have learned in a new game, set in a different place, with new characters and conflicts.

However, one of the things I noticed is that, with all my ideas for settings and stories coming from my decades with pen and paper RPGs, all of them would work very well as turn based, top-down, party CRPGs. Like Fallout or Jagged Alliance 2, and similar to the not turn-based Baldur's Gate and Knights of the Old Republic. And they would also work with mostly the same RPG mechanics. Which led me to further revise my plans for the next step of game development.

The Hornet Engine

In videogame development, the term game engine has a pretty clear meaning. Godot is a game engine. But in pen and paper games, we also frequently use the term engine to refer to sets of game rules that define the basic structures of what statistics make up a character, how the success and failure of actions are determined, how characters take turn during fights, how combat works, and so on. The most widely used RPG engine is the d20 engine that originated in Dungeons & Dragons 3rd edition but was also used in countless other games in the 2000s, like the Conan d20 game, or the WotC Star Wars RPG. Which of course means it was also used in the videogames Neverwinter Nights and Knights of the Old Republic, which are adaptations of those pen and paper RPGs. But there's also the GURPS engine, which originally was planned to be used in Fallout until the licensing agreement fell through and it was replaced by the SPECIAL system. And the Storyteller System of Vampire: The Masquerade and a whole host of other spin-off games, which was adapted to videogames in Bloodlines. Or the Year Zero engine from the Mutant, Coriolis, and Alien RPGs, which unsurprisingly appears in the videogame Mutant Year Zero: Road to Eden.

The idea for the Hornet Engine is something that exists between these two concepts of game engines. The plan is to design a set of RPG rules for character stats, skills, and turn based combat to be implemented in Godot 4. But it also includes designing and programming the UI, pathfinding, and NPC AI. Basically everything you need to have a game in Godot, except for the assets. Which is 3D models, textures, levels, NPCs, and dialogs.

These are of course all things that have to be designed and coded to make any kind of RPG in Godot. And which make a lot of sense to create at the start of the development before continuing on with building all the actual content. So this doesn't really change anything from the development process for any turn-based CRPG. But my plan is to design all these things specifically with the intention to be reused for follow-up games. So that after the first game is completed, work on a second game would mostly consists of texture replacements and creating a few new monster models, and then it would all be building new levels and encounters, and writing new dialogs.

For creating the first game, there would be no real additional work compared to creating any new game from scratch. Just spending bit more thought on future proofing some things, like keeping in mind features that could be added for a later Space Opera game, but won't be relevant in the first Sword & Sorcery game. A Space Opera game won't need an Alchemy skill, but it would need a Computers skill. I know this in advance, and so it makes sense to program the skill system and UI to easily disable skills or add new ones at a later point. But I think it would cut down development time on follow up games substantially.