Scribes Devlog 1 – Building a Builder
1/31/2024
Hello all, and welcome back to the Scribes Devlog!
Over the past handful of months, I’ve been focusing my efforts in development towards making map-building software that’ll be used in the creation of the world map. Down the road, I intend on including this software as free DLC for the players to use. Unfortunately, since the last devlog I haven’t had an abundance of time to actually spend on development, so the progress made over that stretch is limited.
That-said: I have been able to start picking work back up again over this past month. So, the bulk of the content in this devlog will be focusing on that. The rest will be a basic summary of where the project is at, and some details on the technical side of things to explain why I’m doing things a certain way. So, let’s get into it!
Where’s the project now?
As of right now, Scribes is in an early state. The map builder still realistically needs a couple more months of full development time to be ready for building flavored content (dungeons, story content, etc.). Plus I have to re-write the physics and rendering systems to work with the custom map files.
So far, the editor is capable of placing/erasing tiles, placing/erasing smart-tiles (which automatically slope corners), painting over tiles to change their sprites, paint-bucketing tile sprites, switching between 11 floors, saving/loading editor map data, and pulling from where the map files are stored to display the list of editable files. The editor also draws and layers the tiles using their own sprites, so that the compiled level will look similar to how it looks in the editor. On top of all that, it’s able to maintain a Real FPS (how high the FPS would be if it wasn’t capped at 60) of above 4,000 frames on my PC, so in theory it’ll function well on lower-end hardware (though admittedly I haven’t tested that yet).
Why make a custom map editor?
Scribes is an open-world game. There are no “levels” or loading screens during gameplay, it’s all done in one giant world map. So, in order for that to work at all, the map needs to be loaded in small chunks around the player.
This simple concept is the whole reason I’m building a custom editor in the first place. The built-in level editor in the engine I use loads everything simultaneously, so building a complete world map in it is out of the question. In my editor, I’ve made a sub-region system which splits the world map into 100×100 tile chunks that get queued up and loaded into the game as-needed. This way, the open world illusion is maintained without bursting the player’s PC into flames.
Of course, there are also a mountain of other benefits that come with a custom editor. For example:
- I can make any tool I want to speed up the map-building process.
- I can optimize the editor for Scribes, making it lightning fast compared to the game engine’s built-in editor.
- I can include the editor as free DLC with the game so players will be able to make their own dungeons.
- I can compile the map files any way I see fit, allowing me to optimize how the sub-regions are loaded in while playing.
- And many more things…
Though making the editor has been (and will continue to be) a massive undertaking, I know it’ll pay off in dividends down the road.
So what about the actual game?
Over the past week, I’ve been taking a break from working on the editor to prototype the newest iteration of the magic system. In the older versions, the player would use the wheel system to fill in spell slots, and then push different buttons to cast the spells in those slots. While on paper this sounds plenty practical for a fast-paced ARPG combat system, in practice it has a couple big issues.
The first is that the magic wheel was a complex menu. This isn’t a problem once you’ve familiarized yourself with it, but it poses a barrier to entry for new players. There just wasn’t a good way to tutorialize the magic system without throwing a wall of text at the player, which is just bad design.
The second issue is that the old wheel breaks pacing. To explain, in order to bring up the wheel and switch out your spells, you had to hold down a button and navigate a menu with sub-menus. The reason this is an issue is because it pulls the player’s focus away from the action/why they need to cast that spell. It makes switching out the spells feel like an inconvenience they have to overcome in order to get back to the gameplay. This brings me to the final issue:
The old magic wheel discouraged switching out your spells.
The core idea behind Scribes, the entire reason I set out to make it in the first place, is to capture and emulate how it feels to be a magic caster in a world that’s had magic for hundreds of years. There are a lot of games out there where you play as a wizard/sorcerer/etc., and you can even combine runes/elements/whatever to make spells. However, those games (at least the ones I’ve played) almost exclusively use combat oriented spells. Not to mention the faster paced games usually limit you to a handful of spells at a time, all assigned to different buttons.
In a world that’s developed with magic, you’d think there’d be more uses for it than simply hurting people. So, in Scribes, there are more utility spells than there are those that directly deal damage. The magic system is designed around using multiple spells in conjunction in order to achieve a desired affect. So, the player should not only be able to access any of their spells at a moment’s notice, they should also be encouraged to. Forcing the player to navigate complex menus does the opposite of what I’m trying to do.
So what’s the solution?
The answer to my problem ended being the same answer you usually get when dealing with an over-designed system: Cut the excess, trim the fat, or whatever else you want to call it. In other words, I needed to make accessing the magic wheel, making your spell, aiming, and casting that spell as thoughtless as possible.
In short, this was accomplished by boiling all of those different actions down into one simple action: pressing a designated “magic” button.
In long: I first started by completely cutting out the idea of multiple spell slots. So now the player only has to focus on one spell at time. Next, instead of making the player have to pull up the spell wheel as a menu, the wheel is always up (and optionally visible/invisible so as to not block the view).
To load a magic symbol into the spell, the player simply aims with the mouse/right stick and presses space/right trigger. Doing this twice creates a spell with the selected symbols, and then pressing space/right trigger a third time will cast the spell aimed in the direction of the mouse/right stick. Loading a single symbol into the spell and waiting a couple seconds will cast a modifier spell with an affect related to the symbol. Holding the button for a second when putting in the first symbol will cast a different spell related to the symbol. After each spell is cast, the two symbol slots are cleared to make way for the next spell.
After prototyping this system, and messing around with it for a couple days, I can confidently say that it feels exactly how I wanted it to. The act of making and casting spells feels almost natural since it’s all the same motion/button press. Plus, because of how it automatically clears, there’s nothing stopping the player from casting any combination of spells at a moment’s notice.
The other big benefit is that it’ll be quite easy to tutorialize this magic system. Instead of reading a long-winded explanation on how to navigate the magic menu, all the player has to do is push a single button.
So what’s next?
In the near future, I’m going to be focusing my development time on implementing the base gameplay features along with in-game map loading. The idea is to finish nailing down a feel for combat/general gameplay and establishing how the game handles rendering the environments loaded from the files. Once that’s all put together, I’ll be able to make the system for compiling the editor maps into usable files for the game to load from.
If all goes to plan, I should be only 2-3 months away from being able to implement demo content. Of course, this prediction could just be wrong, but it’s the closest I’ve got to a realistic timeline.
That’s all for now.
If I remember to write one, I’ll see y’all in the next devlog!