XCOM Inspired Fantasy Game

[kevL]

pilot wave theory!

(ok ill shutup now -- i heard it has problems)

[NancyGold]

Except when we have wave function collapse that effect is random, and there no way to have "hidden variables". Classic physic is indeed predictable but this is only abstraction over random system :>

As I understand it is random only for the observer, because the observers' measurement abilities are limited. And since observers can't observe the full state, they can't predict the next state. Say there are two cinemas in a town, they show different movies from each other. These theaters reside on two different islands on a lake, now there is just a single boat which can take visitors only to one theater, and the movies in the other remain unseen and the theater may as well go out of the business, but in the end it is the consensus of the viewers which decides what movies will be seen, therefore people see only what they want to see and the future becomes a self fulfilling prophecy. Now what if there are two boats or three theaters, or some islands share a combination of theaters or sub-lakes with sub-boats and sub-theaters on these sub-islands inside the islands on the original lake, ad-infinitum? Is that the kind of multiverse/wave-function sampling we are talking about? In a fantasy game we can have say an "oracle" character, who sees the future. And in a sci-fi game there will have to be an oracle device, operating beyond the bounds of known physics, which allows it to predict the future, that way there could be a way to sample the entire state or just short circuit the time dimension (like H.G.Wells's Time Machine), about which science isn't fully sure what it is, since different events happen at different time for different observers. In other words neither time or space are simple linear euclidean dimensions, although they look like that to us. And it makes no sense to treat them as linear in a fantasy video game with gods and magic directly deciding the fates of mortals. Say a character got cursed by a god? What will that imply? How to describe such curse in game world? Character's "luck" stat got reduced by 5? How should somebody's luck affect the game world? By a dice roll? What about collective luck? Should inanimate objects be "lucky"? I.e. that wall was unlucky when alien plasma shot melted it. If so, given two "unlucky" individuals (XCOM operative and the common house wall), which one will catch the alien plasma shot? I think that is just really intangibly and generic, so introducing a forward log of events sounds like a way to embody it into something both game engine and players can reason about and manipulate (aliens can affect the unlucky house wall's luck, so their shot will hit the XCOM operative). Nobody likes it when their character misses 10 times in a row, and there is a way to solve it - by being explicit about determinism and luck.

Anyway, stumbled XCOM RL dev's presentation. Rogue-likes are a nice a way to get into recreation-type gamedev, without doing it super seriously and learning GPU shaders or doing pixelart / 3d-rigging.

[Yankes]

As I understand it is random only for the observer, because the observers' measurement abilities are limited. And since observers can't observe the full state, they can't predict the next state.

No, your measurement do not have any technical limitations, physic limits what we can measure, we have Uncertainty principle, Bell's theorem, and example of Double-slit experiment where measure change effect of experiment. And whole "no hidden variables" means exactly that there is no "full state" that we do not see, and only thing is wave function and its collapse that is govern by density of probability.

[NancyGold]

No, your measurement do not have any technical limitations, physic limits what we can measure, we have Uncertainty principle, Bell's theorem, and example of Double-slit experiment where measure change effect of experiment. And whole "no hidden variables" means exactly that there is no "full state" that we do not see, and only thing is wave function and its collapse that is govern by density of probability.

The point is that it is just theory, which is based of the local observation. There are no hidden variables, because we never seen them. Like the movie in the theater we never visited, because the boat went to another place today. If one day aliens abduct you and you find yourself on a flying saucer, thousand light years from Earth, you wont have a slightest idea where you are and what is going on on Earth, especially if the saucer has no window (i.e. no proof that the sun is still shining). Basically you are as good as in a different universe. So distance coupled with the light speed limit creates a separate universe. Recently they launched a new telescope and it changed the existing theory, which had holes in it, because the observation became less local. But still there is an optical limit to what we can theoretically see from here. Blackholes too have structure unknown to us, and could as well have their own plank distance, which could end up varying over the space, instead of being constant. But well, they are "black" to us, because we can't observe them directly. Same with the Schrodinger's Cat. We are not yet sure even about our own Sun's structure, because the processes happening inside of it are rather complex. IIRC, there was a paper proving they are turing complete. In other words, there is a life possible inside of the star itself. TLDR: it makes sense to remain open minded, without making any hard predictions and unchangeable plans, so there will be no disappointment when the predictions fail, because we were ignorant about something.

Anyway, here a rogue-like author contemplates on the nature of randomness and determinism in the time travel based games:

[Yankes]

How this even related to for example Double-slit experiment (especially when single photon interfere with itself)?
Every thing is local and can be closed in finite box and separated from rest of universe, and you still have random quantum effects. Or simply checking position of one electron, if you check it repeatably it will always give SAME answer, but if you one time check its speed then next check for position will be have random result, but second check for its position after it will return same value as previous check.

Another fun experiment is light polarization filters that if you put two that are rotated by 90 degree then it will block 100% light but if you put third between and its angled by 45% then whole stack of filters will pass some light. If you add multiple filters angled only by 1 degree to next one then whole stack will block araund 10% light. And more importantly this will work even if you send ONE photon.

And all this is not "theory" this is simple observation that you can do yourself in some cases in your home. Current physic could be wrong about Black holes or beginnings of universe but how this affect observing one electron/photons before you or other closed systems?

And more importantly if even some theory is proven wrong, next one better will include most of old one.
Like Ptolemy solar system was replaced by Copernicus, then by Kepler, Newton and finally Einstein. Predictions of oldest model one are included in newest.
Example could be "Mars do not cross Earth orbit in next 100000y", this is true in every of this theories and will be true in next one too.

Same with current physic theories that have lot common with Ptolemy solar system that in most cases fit model to data, but any theory that is simply and supersede old one will preserve nearly ALL results of old theory, like Newton physic is effective special case of more general Einstein physic.

btw do not try understand Quantum Mechanic using your own examples that do not match any experiment because you will only confuse yourself.
Take real experiment and analyze it precisely and try build mental model that will fit all observable behaviors. Like in your "example" what is "boat" exactly? what is "theater" or "viewer"? How it relate to experiment results? This is only empty words in this case, unrelated to sub atomic reality.

[NancyGold]

How this even related to for example Double-slit experiment (especially when single photon interfere with itself)?
Every thing is local and can be closed in finite box and separated from rest of universe, and you still have random quantum effects. Or simply checking position of one electron, if you check it repeatably it will always give SAME answer, but if you one time check its speed then next check for position will be have random result, but second check for its position after it will return same value as previous check.

The problem is that you checking the electron state affects it.
I.e. you as an observer reside inside the system you observe.
Think of an XCOM operative, armed with a blaster launcher, in a complete darkness.
Now the only way to see anything is by firing the blaster launcher
That lights up the environment, but at the same time destroys part of it.
And what parts you will see, and what parts get destroyed depend on where you target.
In other words, electrons are so basic, we can't see them without changing them.

Returning to the game. I decided to completely scrap the square lattice and introduce hexagons to the battlescape, in addition to employing my voxel engine. As I mentioned before, square grid wasn't my conscious choice, just a legacy from the time the engine was a Warcraft 2 clone, running on top of Common Lisp. And finally it became so unmaintainable, I need a huge refactor plus redesign.

Back when I began I was really naive and had no idea what I'm doing and why it will be klunky. But as any writer I scrap earlier works and build upon them.

At first I thought hexes will make it hard to have rectangular structures, but there is a really nice solution to that: just allow diagonal walls. And voila! We have all kinds of shapes combining nicely together, without any hacks!! Hexes will really simplify the code, making maintenance easier, since I will use the same rendering code both for world map and for site map. Hexes by their sole nature make game world look more organic without any effort. And the new cell format will be closer to the XCOM one: walls plus core. That will save screen space, and allow to easily represent stuff like secret caves behind a waterfall.

I want to also scrap the entity system, since now it has separate entities for world map and for site map. That is really hard to develop, really bug prone and restricts what i can do with the game. Instead I will introduce to have a separate entity list, with an ECS system, where components will be activated when the entity will be given a context. I also want to accommodate for complex stuff, like controlled determinism and time travel. And existing system was proven to be inadequate for that.

Voxels are fast enough even in software on 2GHz CPU, and 3d further simplifies both the code and the graphical asset production. Fully destructible environment is nice too I.e. a magic blast could evaporate parts of the wall, without me drawing the destroyed sprite for each asset. Then I can also easily burn the grass, or tree folliage. Voxel will give player ability to easily zoom in and out, rotate, and a ton of other cooler effects. It is also possible to have pixel perfect voxel sprites, for the chosen angles. The only tricky part about voxels it is removing the occluding terrain. But it is also the trickiest part about 2d isometry. And in 3d there are many more ways to solve it.

I will have to adapt large portion of existing 2d terrain tiles and that will require improvements to my voxel editor. That is really tricky too. I.e. I will need normal mapping with the normals actually displacing the voxels. But other tiles, like soil and grass can be generates automagically.

It is really a shame I have such a horrible planning, but I can either make a just an okay game, or a good game. And to make something good, I have to scrap the stuff making it not good enough. Whne I just began, I knew nothing about voxels and how they can improve everything. My voxel editor initially was just a helper tool to produce 2d sprites. Now I'm fairly experienced with voxels. I wont be able to make more than one game in my life, so why not make a good one? Especially since I got a lot of skills with voxels and hexagons. I have already scrapped the old humanoids, because they were okay, but not good, and limited what I could implement and show, while my pixelart skills improved enough I could draw better ones (which are also dynamically assembled, so allow more animation states). Same way the current engine and lattice limits what I can do. And I really hope I can do something that will be worthy of the classic games I took inspiration from.

[NancyGold]

Picking the grid format, and it is the trickiest part.
Usually one goes from isometry to hexagonal isometry by first extruding the iso diamond into cube.
That cube is reinterpreted as a hexagon.
Then one squashes the hexagon by 2 to get more RPGish view, where character faces can be seen.
This hexagon is guaranteed to tile pixel perfectly.
But for my assets the hexagon is too big and it makes hard to adapt the existing cubic tiles to hexes.
Now it is not really required to squash that, and since lattice form has nothing to do with the art perspective,
For example the original Fallout used square tilemap and just piled in hexes on top.
Heroes of Might & Magic games did the same. There hexes are really tall, so characters wont obscure each other.

But in my case resulting hexagon is either too big or doesn't allow adapting existing tiles.
So I'm entertaining  the idea of allowing several characters onto a tile.
Think Ogre Battle like squads.
That opens for number of gameplay possibilities as well as increasing the game speed.
I.e. player will be incentivized to move 3 characters at once, instead of disjoint characters.
But it will make such grouped characters more vulnerable to area of effect spells.
The idea is really crazy, but I really want to try it, since I'm redoing the game engine anyway.
I.e. a cell with all 3 characters will be immune to attack from behind, while the magic user in it will be able to
cast contact spells without becoming vulnerable to attacks.
Super tricky to implement properly, but I'm looking for an interesting challenge, especially if it is something nobody did before.
Especially since I have a problem where top tier units, like dragon, can kill low tier ones before they will be able to do any damage.
And in square lattice a dragon couldn't really be ganged on, because just 4 melee attack vectors, where 2 are frequently inaccessible
Hexes have 6, and but I really want a good solution of low tier cannon fodder characters, whose names player wont bother even to read, killing a dragon.
HoMM games solved it by limitless stacks, but that is not suitable for a tactics game with unique named characters, no two of which are the same.

[NancyGold]

Rectangular lattice makes it really impossible to represent organic looking structures, likes caves and nature, in a good enough rating.

With hexagonal lattice organic scenes look order of magnitude nicer, but rectangular structures are tricky to implement.
But not impossible. With a bit of effort, one can pass walls though hexes.
Making the organic logic structures with rectangle is a real challenge. XCOM solved it with diagonal walls.
Yet these walls ended up being very thin.
Hexes 3 types of square grids, two isometric looking, and the RPG-maker style.
Hex cities can have buildings at 3 angles, all with standardized tileset.
So hexes are absolutely superior to the rectangular lattice.
They look visually nice and triple the combat possibilities.

Anyway, with 64x32 hexes I still have too much screen space wasted.
I do have XYZ offsetting and placing several objects on a single tile.
I introduced it to break the nasty square lattice look, while placing trees.
But it really clunky and non-uniform.
So hard to use with the procedural map generator placing objects.

32x16 will be too small and I really dislike the idea of having non-uniform hexes.
I can see how it can go wrong everywhere and make pixel art creation harder.
So I will group the objects inside single hex by breaking the hex into 3 diamonds.
So logically it will be diamond tiling, not hex tiling.
Although larger objects will still take entire tile.

I see how this system will allow to implement more nuanced melee combat mechanic.
Even for simple one-on-one duels.
In any case, it will open a space of possibilities, tripling the potential scene complexity and saving screen space.
As I already mentioned, I see how can entire group be moved at once.
Then I also has an issues with cannon plus the gremlin operating it.
As of now I treat them as a single sprite.
But why the cannon can't be operated by any other unit?
Why can't the gremlin be killed and its cannon seized?
Finally 3 smaller trees sharing a hex make for both nice visual look and obstacle for larger monsters.
So there will be a scenario where one can hide from a horse riders in the woods, because horse requires 2 diamonds to pass.
In the end lattice choice is really about interesting state spaces and their presentation to the player.
Of course with voxels one can go without any lattice at all, but at that point it stops being a game and become a simulation.
Requiring the generic and expensive 3d calculation physics and pathfinding.
For voxel I still think raytracing as a monolithic layer, but it will be guided by the tile metadata.
But for that to happen I will really need to optimize the cutting routine to show the inside of dungeons
It is kinda expensive for large size voxel chunks, unless one runs it in parallel on GPU, and I dont have a GPU.
Then again, I'm doing everything slightly differently. Why not implement a non-uniform tiling?
Yet architecturally it will be the hardest challenge I ever faced.
So I need to really perfect the lattice code, or it will be an unmaintainable mess.

[NancyGold]

In addition I'm transitioning everything to use ECS, because a simple class based system is just not suitable for what I want to accomplish. I.e. I have a ton of static objects, but they all use the unit class, wasting a lot of memory and computation resources. I somewhat solved by introducing "active" field, which is non-nil only for objects that need to be updated regularly. But that doesn't help discerning between jut animated objects, but ultimately scenery objects and player controllable units and projectiles. Then I also want to represent the site cells as entities too. So in the end there could interplay between all entities. Like a living person could be turned to stone, and the result will be just another site cell but with an attached history, and therefore be turned back alive with another spell. And it goes very deep, like the ability to assign tooltip to different ingame objects. So simply discarding the OOP is really the way. I haven't went with ECS initially, because it began as a simple RTS engine, which I decided to turn into something more complex, and original Symta had really slow and subpart hashtables, so it was kind of an optimization. So when I began implementing the controlled determinism and time travel stuff, I found it near impossible with the current engine. So it is easier to rewrite everything into ECS, piling up spaghetti of more classes and inter-dependencies. I already had that gene system, which  was a way of emulating ECS, and I actually implemented characters inventory through it, yet it was disjoint from the game world. Usually people built XYZ coords into the base entity, but in my case I need just a raw integer UID, because the entities could be split across different worlds, each having different XYZ. Of course one can have WXYZ, but that will imply that every entity has to be multiworld, but some entities are purely local or have no world at all (i.e. a background process). So I just can't make any assumptions, other than assuming that anything is possible. Unfortunately my brain got poisoned by years of using the OOP hammer, so everything still looks like nail, but in reality OOP has very limited use, concerned solely with providing interface to low-level system objects like images or CPU threads, yet it totally fails at assembling these objects in a compete system, since there are cases where you want to treat both images and threads the same: say you need unload part of the program, together with its threads and images, or when you want to have each thread to have unique icon, or when you want each thread to render unique image, so the thread could be treated as an image. OOP will just lead you astray here.

One can also try implement game engine logic using a prototype based OOP, where objects are just hashes, but it has potential of creating more problems that it solves, since the systems and data will be heavy coupled, instead for being a combination of separate processes, activated on demand. Think each entity being an operating system, with different daemons running concurrently. One can built in everything into the kernel,but the result will be buggy unmaintainable and inflexible mess, since all the daemons have to be in the memory, running all the time. And in game engine we have millions such OS entities, all wasting resources. So ECS appears to be the only correct way to implement any moderately complex video game. But then again, even Tetris today is expected to have nice UI and particle effects, and once you have particle effects, ECS is a must. Absence of ECS was one of the reason I never came to implementing particle effect - adding yet another projectile class was really a chore.

[NancyGold]

Overwatch GDC talk, where the dev explicitly states that ECS is mandatory for properly implementing time.
And it works even with a low latency online FPS, so should good for turn-based games.
Although they also use special scripting language, whose execution can be rewinded.
Can't imagine doing something like their "short replay" easily in a non-pure system, while the game keeps running
I also decided to move from the mutable graph based UI to immediate mode UI.
It is a functional programming approach to UI, where you turn widgets into functions., instead of maintaining an OOP graph.
As a result it greatly simplifies code, especially if you're doing UI in plain C99.
But for high level languages reduction in code size and complexity is astonishing too.
Both technologies are kinda expensive, but I remember hearing that ECS was used already in Thief game.
Then had to discover ECS due to the complexity of the game game logic, compared to simpler games like Quake

[NancyGold]

The project is still alive. I have indeed rewrote the entire UI system to ECS, and now slowly refactoe the engine to be flexible enough. UI really needs to be perfect, since there are a lot of menus and I want them to scale to arbitrary screen resolution, not just 4:3 or 16:9, and to allow users to arrange stuff like minimap anywhere they want. And I want to do that with a very few lines of code. The UI on the screenshot was made with just 30 lines. Would be challenging to do the same even in HTML+CSS. That is very important for prototyping because large portions of the UI gets rewritten continuously, during the game development.



I have also tried immediate mode UI, but found it to be inconvenient as an abstraction, but I do recalc widget rects every few cycles, so buttons and windows could expand to match new textual content.

One huge discovery was that the classic C++ style OOP can be completely replaced with entities (at the cost of performance). One just creates a series of classes which instead of holding the data inside themselves, fetch it from the database. That way an object could have multiple faces, playing NPC in a game world, while being a widget inside UI. I have yet to use the very advanced ECS features inside UI itself.

Another discovery was that hexagon compatible tiles can be implemented without redrawing any assets or even moving to hexes as main tile unit. But one has to implement non-uniform tiling by breaking basic square 4 pieces, and each of these 4 pieces into triangles. Now, I can use the same drawing routine, just assembling the original tiles out of triangles (if they support organic view), and 4x4 units will be allowed to take slight diagonal move. Now I can seamlessly map the world map hexes to the site map gird, while also allowing more organic looking tilesets where needed.

The time scheduling system is also being rewritten to be more robust. I found XCOM style entire party turn system is too rough and rigid. It is unable to capture a lot of stuff I want in my game. Only the Final Fantasy Tactics/rogue-like style scheduling could allow for:
1. Split of a second actions. For example, a unit has flying on a griffin steed got kicked out of the griffin by a tornado spell. In single part turn that unit will fall to the ground and die. Yet if griffin can react quickly, it could catch the rider back, or some unit on the ground could cast a feather fall spell. Same one could have a chance to save a drowning unit.
2. Seamless movement, when we control just a single unit, while other units follow us in some formation or got order to move on their own to some far corner of the map.
3. Ability for several players to move their units at once with little slow down (as long as players keep moving their characters)
4. Ability to quicker react to enemy movement.
5. Ability to avoid waiting for all the boring AI movement stuff. Think huge cities living on their own while you move your squad.
6. Ability for time magic to control time precisely.
7. Ability to turn on real-time mode with optional pause, when you just wait for your units to finish their tasks, or want to allow fast paced multiplayer. Age of Wonders tried to solve that with simultaneous turn mode, but that led to a total mess worse, where luck and fast clicking decided who win the game.
8. Much easier to implement AI. Although one would still want to have some rough long-term planning and goals for each unit.

One can still implement XCom style scheduling on top of the rogue-like one. In fact one can implement anything on top of it. That is how they turned initially turn-based Diablo into a real-time game, without rewriting the entire engine. Yet it is very hard to convert initially real-time or non-granular turn-based scheduling to support the granular mode.

I really enjoy how rogue-like scheduling works out in the games like Monstania or KeeperRL: one can be very tactical at some point, while at other points one can use the same scheduling mode while exploring a city with NPCs walking around. The total opposite would be Paradise Cracked - a Russian made XCOM clone, which had city explorations using entire-squad-at-once style scheduling. Each turn player was forced to watch each single NPC and vehicle to move across a huge map. That was the thing killing otherwise fun game. The only downside is that roguelilke scheduling (especially with large world) can be resource intensive to maintain illusion of fast response. So say Dwarf Fortress has really high CPU requirement.

I now believe that time-scheduling the is the most important thing about the game mechanics.

BTW, I now LP various obscure mostly turn-based games and XCOM mods are on my TODO list. Message if you want your fav game to be lets played. Just note that I wont LP popular, action-heavy or very uninspiring stuff (think football managers or standard JRPGs), since my goal is to discover more unusual games.