XCOM Inspired Fantasy Game

[Nikita_Sadkov]

Cool! But it looks like you put lib directory instead of src or a link to github into the .zip

Edit: ah, now I get it. It's your own runtime and your own lisp. Very cool.

Yeah I'm a big fan of Lisp, so I decided to write game in Lisp. Spell of Mastery is actually my second game. The first one was Warcraft 2 engine implementation in Common Lisp (SBCL). It was fairly complete with working AI and all spells implemented: https://www.youtube.com/watch?v=-k8jkeFfnl0

[Nikita_Sadkov]

Implemented fire, lightning and explosions burning grass and flammable objects. Also added a bugfixes to the demo at https://nikitasadkov.itch.io/spell-of-mastery-demo

Remaining major features:
1. Collapsing structures. This one require introducing material strengths. Metals can have large overhangs than soil.
2. Water/lava dynamics. Moving water is actually an important tactical feature. Say flooding a cave full of enemies. Or in multiplayer maps player can create bottleneck by flooding trenches. Fantasy setting makes it easy to introduce such feature, because there could be say a flood spell.
3. Passable objects blocking vision, like smoke screen or tall bushes, which could be especially useful to burn down.

[Nikita_Sadkov]

Ok. Done implementing fog/tall grass blocking vision. Also fixed a ton of bugs. As always, comments and suggestions are welcome.



The Fog of War regeneration mechanics is actually allows some choices with various drawbacks. For example, FOW can be regenerated at the end of players turn, at start of player's turn, both at the start and at the end, or when any unit finishes movement. Deciding how to implement FOG of war, I made a pros/cons table (such tables appear to be a common game design instrument).

End of Turn:
- Pros:
  - Player doesn't see enemy movement in territories he left.
  - Player can still see enemies which killed his units or casted Mist.
  - Player can see all terrain he uncovered during this turn. Makes it easier for player to remember stuff. Especially if player loads the game after few days.
  - AI handles it easily, noticing positions of your units.
  - Intuitive.
- Cons:
  - Effects like Mist wont blocking vision won't be immediately noticeable.

Start of Turn:
- Pros:
  - Effects like mist blocking vision will be immediately noticeable.
- Cons:
  - Player can see enemy movement in territories he left.
  - Player can still see all enemy movement in mist until the start of his turn. That will be just an annoyance.
  - Really hard to make AI handle it.
  - Non-intuitive.

Both Start and End of Turn:
- Pros:
  - Some combined pros of both approaches.
- Cons
  - Really hard to make AI handle it.
  - Non-intuitive.

Each time unit finished its movement:
- Pros:
  - Very intuitive.
  - Spells like Mist immediately take effect.
- Cons:
  - Less tactical depth: player cannot move a scout close to uncover enemy units, then move that scout away and nuke the enemy with some area of effect spell, that would otherwise harm the scout.
  - Computationally intensive on large maps.

[Yankes]

Some thoughts about mist and fire. Overall I think its look bit out of place and do not fit good rest of graphic. It look bit too much diffused compared to rest of sprites.
Overall graphic is nice looking pixel art and this effect look like from some 3D game.

[Nikita_Sadkov]

Some thoughts about mist and fire. Overall I think its look bit out of place and do not fit good rest of graphic. It look bit too much diffused compared to rest of sprites.
Overall graphic is nice looking pixel art and this effect look like from some 3D game.

There is a number of reasons I decided to use non-pixelart effects.
1. Alpha channel allows to easily show objects inside mist and fire. And blends nicely with any object, as opposed to say dithering. In XCOM artists had to keep flames really small and close to the ground to avoid obscuring units. You just don't get that massive firestorm effect burning trees. Same with mist, which should be the height of a unit to actually block sight, otherwise it will look silly.
2. It is a common practice to use alpha-channel true-color effects in modern pixelart turn-based games, and even in some older, like Age of Wonders (it combines index painted pixelart with pre-rendered graphics), Master of Magic, Magic & Mayhem and Mage Knight Destiny Soldier for GBA.
3. Full color gradients and transparency make special effects stand out.
4. You just cant nicely model mist and fire using pixels. Especially with large sprites. It will have a lot of ugly dithering, and nasty gradient jumps. I also found it much harder to produce good looking pixelart effects.
5. There is a good amount of ready to use true-color stock art effect templates, both free and commercial. Just load them into particle editor and create what you need. In fact, I had to convert a few pixel art effects I took from OpenGameArt into continuous color, because, while the effects were okay, they were looking just wrong with that dithering.
6. I still use pixelart for a few effects, like the magical goblet for bless spell.


Also, there is an indie game called, Waves of Fate, they do use pure pixel art effects in it (down to scary dithering in place of transparency), but it looks okay due to generally non-realistic art style: https://store.steampowered.com/app/467270/Weaves_of_Fate/

Then again, many older pixelart games, like Final Fantasy Tactics, combine everything that works. Although I always thought that FFT's 3d landscape is the ugliest part of the game, after the pre-rendered intro cutscene, which was outsourced to that infamous Russian studio, which made Zelda Phillips CDI games. Still FFT's 3d magic effects were really beautiful, and impossible to achieve with pixelart.

[Yankes]

You did not get exactly my point. I fine with transparency and special effects on graphic, some thing I did:

https://openxcom.org/forum/index.php/topic,1532.30.html
https://openxcom.org/forum/index.php/topic,322.msg4504.html#msg4504
https://openxcom.org/forum/index.php/topic,2059.0.html

I once made default fire semi-transparent in some old branch of OpenXcom.

My point was that graphic used for this effect was too much blurred compare to rest of graphic. Transparency can have impact on this but I do not think this main reason.

[Nikita_Sadkov]

My point was that graphic used for this effect was too much blurred compare to rest of graphic. Transparency can have impact on this but I do not think this main reason.

Well, it is a fog, it is supposed to be blurry and annoying to players. There are a few spells, like tornado to get rid of it.

Also, implemented rain effect, which would reduce sight, extinguish fires and prevent fire spells from being cast at outside locations. I'm unsure how much and when rain should go. Maybe the rain could be that one place where RNG will be allowed? I really want to avoid RNG and make game as fair as chess, but making it rain every 31st turn would look silly. Obviously rain should be controlled by biome, so there will be no rain in the desert, but a lot of rain in rainforest. Should rain spawn mist? How to spawn mist in deterministic way, without RNG? Then again, what do I know about raining? Or maybe making rain into a spell, casting which would change weather?

[Nikita_Sadkov]

Dynamic water - done. In future I will also add lava, which would set nearby objects on fire and cool into stone under rain or in contact with water.

Still these liquid interactions are rather tricky and allow for a lot of possible implementation, with various drawbacks and game design shortcomings.

[Nikita_Sadkov]

Ooookay. One huge update. Dunno if you people can implement the same in OpenXCOM  I'm sure in one thing, with XCOM style map cell format you will have to use different approach.

Version 0.9a changes:
- Smooth fog of war, due to multiple requests. For some reason people were really annoyed by contrast square fog tiles   

Version 0.9 changes:
- Dynamic Water.
- Cataclysm spell to flood your enemies and open a passage through waters. Finally you can play as Moses!
- Tornado spell, which scatters units and removes mist.
- Proper time system, instead of abstract turns. Now every turn models real life hour.
- Night time: every 8 turns out of 24 turns day, from 22:00 to 6:00. Undeads have more defence at night, while units without darkvision have reduced sight.
- Rain, which extinguishes flames in outdoor areas and prevents the use of fire spells, like firestorm and fireball. Units inside rain get -1 to sight.
- Proper wood bridge tile, instead wooden floor.
- Fixed fog sight bug, when cell below or above give units cant be accessed inside fog.
- Fixed bug with invalid empty check, affecting several spells and leading to potential crashes when one creature teleports into another creature.
- Fixed crash hiding drowning unit.

[Solarius Scorch]

Does it mean we can blow up parts of the map to drain water?

[Nikita_Sadkov]

Does it mean we can blow up parts of the map to drain water?

Yup. It would also allow randomly generating puzzles, if water reservoirs are placed randomly. Although soil is really explosion resistant material, unless it is really heavy explosion leaving a crater, so currently I have limited terraforming only to the imp unit, which also digs passages, builds ladders and bridges. In XCOM game that would be a soldier with a shovel (I'm surprised OXC havent implemented trench digging yet). The flood/cataclysm spell was a little overpowered, so I had to reduce ranger and implement accretion time, so AI will have a few turns to move out of the way.

Here I imp below digged under the river, redirecting the flow and drowning in the process.

[Nikita_Sadkov]

Done collapsing terrain, killing units caught inside and giving fall damage to the ones standing on top. Still needs some proper animations. IIRC, collapsing multi-floor buildings were major feature of XCOM Apocalypse. I haven't seen them in any other game.

[Nikita_Sadkov]

Original XCOM engine had somewhat intricate sprite format, requiring artist to carefully split sprites into into multiple cells. That was especially annoying with larger objects, like trees or tanks (dunno if Gollop had some cool algorithm to do that automatically). I just use free form sprites, leading to more complicated draworder algorithm, especially when most humanoids have a height of 2 cubes. I also limit movement direction to north,south,west,east, which requires me to draw sprites only in two directions. Still a lot of routine work.

[Nikita_Sadkov]

Some interesting notes from original XCOM Apocalypse developer:
http://www.terrygreer.com/xcomapocalyse.html

The editor was an updated version of the one used for the earlier xcom games.

Every tile was designed to occupy a volume of space. Many tiles had multiple versions showing a succession of destroyed states.

In the description off each tile there was a series of properties such as ‘health value’ and ‘destroyed tile type’. when the health value was eroded away the tile would then be replaced by the ‘destroyed tile type’ (which in turn could have its own health and destroyed type). Chains like this could be as long or short as required. Tiles could of course also bed invulnerable.

This approach meant that potentially anything in the map could be blown apart and destroyed. This was made even more true in Apocalypse as tiles could also be flagged as supportive, and if a supportive tile was destroyed then those above it could also fall.

 

Tiles were complex data structures. Each one also had a reference to line of sight definition – this was a simple 4x4x4 grid – a sort 3d texture – where each cell was either solid or empty. There were a relatively small number of these solid line of sight definitions, but enough to approximate the 3D shape of any shape of tile created. This meant that the world was effectively broken into a 3d voxel grid where weapon fire could be accurately ray-traced. It was a ball ache to set up initially, as every tile had to have a line of sight definition assigned, but really made life easy later on as collision in game then became automatically generated from the map editor.

It was a genius approach, especially in the years before decent 3d raytracing – and one of the key identifying features of an xcom game. Players always loved being able to snipe enemy forces from right across the map through a couple of windows or blown open walls. It’s also a technique which I think useful to reinvent for use in conjunction with true 3D worlds and can think of lots of good mechanics you could use them for.

 

While some mission maps were hand crafted (especially apocalypse and the end missions of every game), many other mission maps in XCom games were made procedurally (especially in the earlier games).

 

The procedural rules would:

  1. Decide on the location type (e.g. farm, port, city etc)

  2. Then, using a look-up table specific to the location type selected a look up table would let a number of small hand crafted sections be chosen at random (though rules would restrict how often each piece could be chosen).

  3. Mix together these sections (with simple rules that specified which sections could be adjacent to which other sections).

The result was a vast number of possible layouts – for all intents and purposes near infinite, and unique to each user.

The procedural nature of these maps made the games feel more personal to each user.

The recent remake eschewed this approach and instead went for a large number of hand crafted maps instead, although with random starting points (which was a shame).

Sadly I don't have screenshots of the tools we used for these isometric games

Were these tools ever made public? Or maybe their code was left in the game's executable?

[Stoddard]

many thanks for the link.

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

editor: no, while i'm sure it's still out there somewhere, it's hopelessly outdated anyway. we have MapView

the rest is documented in ufopaedia.org and the source code.