XCOM Inspired Fantasy Game

[Nikita_Sadkov]

it only emphasizes why great games are not ever done by big or even medium-sized studios.

Yeah. That Terry Green also designed other cool and innovative games, such as http://www.terrygreer.com/xenomorph.html (a System Shock style game long before System Shock). https://www.youtube.com/watch?v=QKVNnnqyuZY

It was an obvious inspiration for System Shock, down to soundtrack.

[Nikita_Sadkov]

Implemented different biomes. Because you cant have lava without snow

Things to do:
- Cell temperature, melting ice/snow and setting objects on fire. Then things like lava and fire could just increase the temperature of creatures caught inside them.
- Air/oxygen. Closed rooms with creatures lose oxygen level, making non-undead creatures to die.
- Lava damaging flyers staying over it (should come with the cell temperature).

Well it is hard keep todo list from growing, because many features come naturally. You need lava damage and convection, you have to implement air and cell temperature. Lava should be really hot inside closed spaces.

[Solarius Scorch]

Dude, you are insane in the best way possible.

If only you considered dice rolls...

[Yankes]

This is too insane

[Nikita_Sadkov]

Dude, you are insane in the best way possible.

If only you considered dice rolls...

I do consider them as an option, something like hardcore mode.

Anyway, further work on gas diffusion would be introducing the scent propagation: each scent has a umber of components, and different units emit different proportion of these components. So if you have say a dog on a team, it may sniff the scent of the alien hidding behind the corner. Or you may use it for the usual diffusion based pathfinding, which would reduce the otherwise complex pathfind problem to just O(1). And the scent diffusion is an embarrassingly parallel problem, so in real-time setting one can easily run diffusion on several CPUs, or update diffusion it once in a few game cycles, when there isn't much going on.

[Nikita_Sadkov]

Implemented halved tiles. When designing an isometric engine, there are numerous decisions one has to make:
1. Will the engine allow truly 3d world without hacks? Like i.e. room over room.
2. Would the game world be cell-based, continuous or combine both approaches?
3. For cell based worlds, one has to pick unit-sized cell. Like i.e. 32x32x32 cube of 1x1x1 voxels.
4. What would be the cell format? Are walls going to be embedded into tile as well as floor or use separate tiles?

For example,
1. Magic & Mayhem has cell based world, but uses 32x32x16 cells. That approach is simple and robust, but requires splitting everything into such very small tiles or use some ad-hoc hacks for topologicaly sorting larger tiles, so they won't be ovedrawn with tiles behind
2. Original XCOM uses 16x16x16 cells and embed walls and floor into these cells, making it very involved to say trace a bullet path, while walls look really thin and units cramped into walls. Now cels can block vision from one side, while allowing to see from another.  Such approach also greatly impedes dynamic effects, like water flows. XCOM also allows fatter walls, further complicating engine. Yet it is very efficient, because it greatly cheapens topological sorting and extends map size, because walls are stored as part of cell and sorted with it.
3. Furcadia uses approach similar to XCOM, but walls can have any height, yet they still look very thin.
4. Ultima 8 and Faery Tale 2 use continuous world approach with cell sized tiles.
5. Final Fantasy Tactics allows only varying floor height. Many similar games are lazily implemented by making each tile type into a long pilar, which is just moved up or down to accommodate for height, instead of introducing proper tiling and draw order sorting.
6. Diablo have just floor and objects on top of that floor. The simplest type of isometric game to make.
7. Stronghold used some very complex approach, basically splitting every building into very small cubes, supposedly automatically. All these crenelations on towers properly obscured units. One of the more complex isometric game engines. Still unsure how the implemented pathfinding.

Anyway, picking base cell size doesn't really limit tile size, with some hacks one can implement finer 16x16x16 tiles in 32x32x32 engine.

[Nikita_Sadkov]

XCOM like Fantasy game which came out two years before XCOM, but I bet you never ever heard of it:
https://www.mobygames.com/game/four-crystals-of-trazere
>Armies of mutants are marauding through the land and it's up to the heroes to scour the cities, dungeons, and wilderness looking for clues to the source of the evil. The party moves from location to location on a strategic map avoiding (or ambushing) enemy patrols and armies while trying to find the clues and items they need in isometric dungeons and cities. The game also features an intricate magic system that lets players design and customize spells.

The game has very involved magic system, where player can adjust spell area of effect, time and range. I.e. instead of a single shot dispel cast, player can have a dispel field, removing enchantment from creatures entering it. Really neat concept although hard to balance and implement properly. I had an idea of refactoring spells into such system, after getting over with the basic game.

[Nikita_Sadkov]

Another feature - colored lights for various effects. It is probably possible to ray-trace sun's position and shade terrain behind walls.

[Nikita_Sadkov]

Some tricky hacks are required to implement even the basic lights in an isometric engine. But lights are a must in a game heavily focused on magic and throwing fireballs, which would look very bland as static sprites.

Although the basic formula is very simple:

Code: [Select]

lighten T E = T + T*E/Factorwhere T is the texture's light receptiveness, and E is the light's energy. Of course you need to apply that formula to each of the RGB components, unless you have the stylish black & white soviet TV. I heard they still use B&W TVs in Russia

Alas I never got why applying light is multiplication, not addition. Guess that is some complicated physics shit with typical square law.

That guy from Stencil forum actually raytraced lights: http://community.stencyl.com/index.php/topic,41034.450.html

surprisingly his code is efficient enough to run even in browser, although slowly. At that level you can just use completely raycast engine. Then again, even my hacky code uses some degenerate form of raycasting. There just no going around traversing space, when you need to draw lights.

[Anon011]

Very nice game Nikita, I like it so far.
Will you make a Russian localization for it one day?

[Nikita_Sadkov]

Very nice game Nikita, I like it so far.
Will you make a Russian localization for it one day?

The programming language I use doesn't support unicode.

[Nikita_Sadkov]

Another tricky design decision: how to implement floating islands. The most robust way appears to be implementing special floating property for tiles. That way it could also be associated with some control structure, allowing it to move in 6 directions, maybe even landing and crushing units below. It would be near impossible to implement even a remotely challenging dueling AI in this setting (given that we still struggle to implement competitive AI for Starcraft), therefore such maps should be kept to XCOM style exploration, puzzles or multiplayer. Although I've plans implementing dueling AI, like in Magic & Mayhem, but on simpler arena maps, and giving AI some bonus, like several lives and more spells.

For now I've redrawn a public domain fir tree: https://opengameart.org/content/pine-tree-16x16

I dislike drawing, but not getting away from it, when there are no suitable free assets.

[Nikita_Sadkov]

Ok. Resized the tree to match the game proportions, and drawn another fir tree. These trees are a bit out of angle, and it can be fixed by scaling it by Y and adding a few backside slopes to branches, but that wont really make it look better - pure isometry is little bit too boring.

Also, in case of XCOM and Magic & Mayhem engine trees, the lower branches would be occluding the stuff on the ground, like the corn. While graphically correct, that isn't really a good thing, because occluded thing can be say an important key, fallen out of a dead monster, and because occlusion requires properly shading the object below (bright corn under branches will look incorrect).

[Yankes]

I for long time think amount 2.5D graphic engine. This mean that each screen pixel have not only color but depth too. With something like this drawing order will be only secondary thing. You will check for each pixel you draw if you it behind or on front of background pixel.

With something like this you could add shadows too, special surface that have two depths, if background pixel have depth that is in this range we change shade of this pixel.

Overall each blit function will have not only `x` and `y` but `z` coordinate too.

[Nikita_Sadkov]

I for long time think amount 2.5D graphic engine. This mean that each screen pixel have not only color but depth too. With something like this drawing order will be only secondary thing. You will check for each pixel you draw if you it behind or on front of background pixel.

That is called z-buffering. It is slower than draw-order sorting and doesn't solve the problem of higher layer popping through the layer below, or floor in front of a sprite cutting legs off large characters (that is why XCOM tanks are split into several cubes). Here is an example from Daimonin of what happens with naive approach (notice the cut off dragon legs and the poor botched wurm)


To solve the problem you need actual 3d transformations,  and mapping each sprite as texture to a polygon. I actually tried doing it in software and it is orders of magnitude slower than topological sort. Although Ultima Online did it somehow in 90ies. I.e. it needs OpenGL, which requires 32bit textures in precise 512x512 pages, forcing to pack all graphics into such pages, which requires writing very tricky packing algorithms. In addition OpenGL doesn't support paletted textures, so no way to recolor units or do color cycling, so you need write a lot of tricky shaders to support that. And you will still need to sort transparent surfaces, which is especially nasty, when most of your sprites have some transparency. It is also harder to control 3d polygons. For example, same cell may have a pebbles sprite, a unit standing on top of said pebbles, a weapon that unit is holding and some effect, like explosion or fire over that unit. These elements should be drawn in that precise order, it would be silly if weapon gets drawn before the unit.

So yeah, OpenGL and any 3d brings in more problems than it solves. And of course say good bye to portability, because each graphics card does something differently.