NextGame has got some growing pine trees today.
This was not a small bit, here’s why:
Gallery has been added – there you might see pictures from the articles and hopefully some new ones will be added soon.
Today I’m going to explain how overlays are intended to work in NextGame. In NG terrain consists of 3D tiles that are morphed to follow the heightmap. Overlays are 3D models of special tiles “upgrades”. They are morphed too and are placed on top of the ordinary tile. Another important aspect is that they are aware of neighbor tiles and automatically select best shape to combine with each other.
Converting games from 2.5D to 3D is simple – make a terrain, put some 3D houses and units, setup perspective projection camera. Game logic still remains the 2D. Starting from the top – is it really that simple to make a terrain in 3D?
Today’s went under the “Throw away old stuff” flag. Since the code is our property and art assets are mostly not, they all have to go. The process has started a few months ago already, but today it was mostly finished.
The game looks really empty at this stage. There are no replacements yet, except for a few elements. It is a fresh start, like an empty canvas ready to be filled with new stuff.
So what’s been thrown away – read under the cut:
Tileset surfaces got some improvements. Now they are stored in XML instead of hardcode (which allows for handy editing in a Notepad). Of course XML is slower to parse, but for development we need it to be easy to edit. Improving performance in a code that runs only once on game loading can be done much later 🙂
Second big improvement is a pop-up window that is instantiated by tileset surfaces class:
To be able to edit many of the settings in a developing game we need a tool that allows to see the changes live – and that’s the one. Pop-up is closely tied with it’s owner class, so no other element of the game is aware of its existence (that’s a good OOP approach). When changes are made in that window they trigger OnChanged event to which we connect the function to flush the caches and make the game recalculate tiles geometry (Surfaces affect that mostly). The pop-up looks and works exactly the same in the game as on this screen above.
In the future such pop-ups will carry the role of “on-the-fly” editing tools for the game. So e.g. UnitsTasks pop-up will allow to change settings such as work duration, produced ware count, etc.
3D models have many advantages over 2D sprites, (and drawbacks too), but when it comes to little details, 3D has a neat one – we can change how a unit model looks and that change is propagated throughout the game immediately. Take for example Serf, e.g. we want to give him a mustache – we change the 3D model, hit “reload resources” button, and voila – all serfs in the game have mustaches when walking any direction, carrying any ware, eating any food, just everywhere.
Spent a few hours on refactoring the code to modern Delphi standards. The language has noticeably improved in last decade. New iterators, generics, lambdas, other fancy buzzwords. It appears though, some of them are very handy and speedier!
Added a new section, there are few questions there yet, so feel free to ask what interests you in comments!
With this short note I’m going to start posting updates on project development, big and small.
Last week I was redoing the tile morpher algorithm (once again) and it seemed that this time it will finally work (not for the first time as well). I took a break after I could not figure a trivial math task – how to interpolate between sides of a square … was just too tired perhaps. Anyway, today I was formulating the problem once again, and simplest solution just popped into my head. So now tile morphing seems to be working nicely.
Couple more tests and related issue with mirroring height nailed as well. Quite a productive day I’d say:
