Our main goal is to invent a new game that will be a spiritual successor to KaM. Bring it up to date with new gameplay mechanics and graphics. Where do we start?
Reusability
KaM Remake has an excellent code-base, so, we are planning to reuse it as much as possible. Some parts will have to be thrown away and new ones added instead. The biggest advantage is that we already have a thoroughly tested and well working code of an actual game. Why not use a 3rd party engine? In short – we want to study how making the game works, and we already have an “engine” specifically tailored for many of our needs. Naturally -we take that as a base and start working from that. Programming is not our weak spot.
Revamping
Such a huge change in direction has it’s benefits too. While upgrading the code we can re-think many of design decisions and refactor them. Clean up the code. Improve algorithms. Simplify otherwise complicated solutions that were made to mimic KaM behavior.
Multiplatform
These days it makes sense to keep different platforms in mind. Since 2013 Delphi code can be natively compiled to run on iOS and Android. At the moment tablets might not be our direct goal, but who knows what comes in 2-3 years.. Besides, writing multi-platform code from start is much easier than introducing multi-platform into an existing codebase. Luckily we already had some rudimentary paths for Linux/MacOS builds and biggest parts that need adapting match with those we need to replace: graphics and UI.
Choosing tech
Biggest difference comes from moving to 3D. KaM Remake rendering is separated from games logic, so that means we cut out one system and put a new one on it’s place. Forgetting about OpenGL legacy “immediate mode” and jumping right into modern “Vertex Array Objects” and shaders. Targeting Open GL ES2 means render will run the same on PCs and tablets. Writing 3D environment is a huge amount of work which I’m going to cover in next articles.
What about important things – gameplay?
Tech details are boring, what about the actual game? Here’s the catch, planning the game on paper without being able to test it might be very misleading. So first things first – we need a working environment in which we can spawn objects and see how they interact. Consider it a blocker. Gameplay rules can be invented or looked up and will change a lot during balancing, but inventing the way rendering implementation compatibly works on multi-platform is much more uncertain.
