What happens if you take a classic gem-collecting boulder-dodging action puzzle, make it turn-based, and add in roguelike elements like skills, monsters, and procedurally-generated levels?
This is a prototype (mostly getting game systems working with placeholder or simple art) which I toiled away at for the last 30 days. Currently, it includes almost all the core systems:
What's missing? My favourite roguelike element: the ability to spend gems to buy permanent upgrades and unlock new skills.
My current vision is something like a cross between Boulder Dash and Hades. You pick from an assortment of unlocked and upgraded skills, make a run, die, upgrade and pick an entirely different set, and try again. I planned 100 levels across ten different biomes, each with their own unique set of monsters and environmental dangers to deal with.
If you like what you see, sign up to our Revue newsletter to get weekly updates! In the coming days, you will also get instructions on how to access the playable prototype of the game!
Want to make games faster, bigger, and with better quality, while investing the same amount of time? It's possible, albeit with an unintuitive solution: a custom game engine. I'm here to tell you why you can, and should, build a custom game engine.
It's 2021, and lots of strong, general-purpose game engines abound: from Unreal to Godot to GameMaker to Construct, tools exist for beginner and experienced developers alike. Why bother making your own game engine?
It's a great learning tool, sure, but a better reason exists: you can customize your game engine to your own personal style and workflow.
A great example of this is RPG Maker, which specializes in making JRPG games. Using RPG Maker, you can - very quickly, and without much coding skill - create large-scale and complex JRPGs. RPG Maker includes events for all kinds of common JRPG things (dialog, shops, inns, quest NPCs, etc.) which makes it very, very fast to build, compared to building something from scratch.
Even if you think this isn't a great idea, I guarantee you will learn a ton by doing this. If you're convinced, read on.
You're not planning to build a general-purpose, large-scale game engines. Those are difficult, and require lots of different skillls which you may not have.
First, identify an existing game engine, framework, library, toolkit, etc. that you use and like. What's great about it? Importantly, what's not good about it? Where can you improve upon it, or what pain-points does it inflict on you that you wish you could work around?
Once you identified your starting-point, you can even build on top of an existing game engine. This way, you create a standalone library, or a thin "layer" that makes some tasks easier. It could be as simple as scene management, or as complicated as common code for a roguelike.
Whatever your goal, pick something small and achievable as the first step.
Now, the most important part: do not build your game engine or framework in isolation! You will end up with bloated features that are difficult to use, and code that nobody uses. Instead, design a small standalone game that you feel really excited to build.
The key: build your game in tandem with your game engine. For example, if you need outlined text, add some code for that to your game engine, then add it to the titlescreen, options screen, or whatever location in your game that you need it.
This keeps your code useful, streamlined, and well-tested to begin with; it greatly increases the chances that you can ship something useful at the end of your game development cycle, whether the game ships or not.
Work on your game framework with that cycle: add code, test it, implement it in your game. Rinse, repeat.
If your game framework extends beyond a simple library, you should consider the user workflow carefully. How do users use your framework? Do they link a DLL, or copy/paste code into their project? Do you need to provide a template project with some starter code, or simply a spec for a JSON file?
Looking at this early on makes it easier for users to eventually use your game framework.
Testing your game framework is really important. As it grows, you will find it increasingly likely that you accidentally break things in other places and not notice. I highly recommend writing unit tests and/or integration tests for every single line of code you write. This makes it very easy to make changes: you simply run the tests, and they identify anything broken you need to fix.
I applied this process to a number of game frameworks over the years (mostly abandonware). One of them, Puffin, actually shipped to production (I finished it and launched the game and the framework). It didn't meet my long-term needs, but it worked well enough.
Here's a quick summary of how that came to be:
Ultimately, Puffin didn't meet my needs; in particular, the choice of an ECS architecture didn't mesh well with Godot-style nested scenes and subscenes.
I may revisit Puffin in the future, and I certainly learned a lot about development through this experience. I hope you, too, will find the time and effort to build something, big or small, to help you build games you like faster and better than whatever you're using today.
Introducing Crystal Caverns, a match-3/roguelike hybrid with persistent upgrades. In the last two months, I took this game from a rough prototype to what you see in the video. At present, the game includes:
Battles appear bare-bones at the moment, but include some depth: - Players can attack, critical-strike, boost defense, poison enemies, drain, and heal. - Monster attacks affect the board in various ways (currently, they just eat random tiles).
That includes enough of the core game to improve upon.
Next month, I plan to turn my attention more towards the roguelike side of the game: generating dungeons with monsters, finding treasure (including persistent treasure), and balancing exploration with progression.
Hello! Long-time readers of this blog may notice a couple of changes:
I decided to redo the blog to make it mobile-friendly, and to hange the content - instead of game development notes and game design articles, instead, I plan to focus on my games.
What can you expect going forward? Weekly posts show-casing the best of whatever current project I'm working on.
Old articles will stay available for a while.
Tags: .NET Core, Architecture
So you want to localize and internationalize your web application? There are a lot of considerations, but here, we briefly discuss just the translation part.
This post covers a couple of the architectural/design options and discusses their respective trade-offs. While this is a bit specific to .NET, other languages no doubt provide similar concepts, with various levels of API support (e.g. language stored in cookies)
.NET and .NET Core provide some infrastructure called "resource files" (
.resx) extension). These are XML files which you can edit directly in Visual Studio; at runtime, they compile down to a binary format. They generally recommend creating a few resource files (one per back-end controller or shared module). Advantages of this approach include:
The disadvantages of this format include:
Overall, I think this approach works well if you plan to update translations periodically and don't need an external translater. (If you do, and they're not a coder, you'll need to make additional tooling to export/import the strings in a format they can understand.)
One common alternative approach is to store the translations in a database (relational or otherwise) and simply load/display them at runtime. This confers some additional advantages over resource files:
However, it contains some additional downsides:
I think this approach suits situations where you absolutely must be able to see updated translations reflected immediately, or where you have non-technical translators who need an easy way to be able to update translations.
If you know of any other architectures/designs, drop me a note on Twitter and let me know!