XCOM Inspired Fantasy Game

[Yankes]

That always happens with promising games

Probably people define to ambitious scopes and can't deliver it. Maybe better approach is do MVP and then adding on top of this new functionality.

[Nikita_Sadkov]

Probably people define to ambitious scopes and can't deliver it. Maybe better approach is do MVP and then adding on top of this new functionality.

Small team projects are also very dependent on each member. They wont survive "the bus test". I.e. if bus hits programmer, the project is done, if bus hits artist - same thing. On large AAA projects you have several programmers, so if lead programmer gets ill, others would still be able to carry the project, although with a few more bugs. They also have some art style guidelines and technical specifications. Here is for example art guidelines for Ultima Online: https://gallery.ultimacodex.com/ultima-online-kingdom-reborn-art-guide/

Indie projects are also worked on by unpaid people, so there are high chance of key team member losing interest in the project, especially if it takes too long to complete.

I personally don't have team members. Although I worked with freelance artists, and it was annoying experience, since external artists can't do anything without being micromanaged, even if you provide them with exact technical specs and examples of what to draw. Many artists also have troubles drawing isometric art - creating sideview platformer game art is one thing, while isometric graphics requires actual art skills, especially animating it (usually it is first pre-rendered, and then painted over), and gamedev artists frequently have no proper art education. They also mess up anatomy badly, like drawing creature tails growing out of their anuses, instead of spines. I'm no artist, but I have no such troubles, but yes I've basic math education. Anyway, I had to manually fix stuff after them.

Guess things are different when you have a professional full time artist on a team. But I heard full time artists are very lazy, since they get paid anyway, even if they do almost nothing. With freelancers you just change them, if they fail, but you can't expect of them much creativity.

Still original XCOM had rather basic and cheesy animations. XCOM Apocalypse used raw renders (they had no time to retouch them into pixelart), which looked just horrible in game, despite creature designs themselves being cool. And for Might & Mayhem they did claymation, which gave passable results, since sprites were large enough.

[Nikita_Sadkov]

As I mentioned, this is my personal project. While I have no team members and don't have to be responsible before anyone, I still hired freelancers in the past. I had some horrible experience working with Russian ones. For example, I have a Witch character sprite. The idea is that she is half human and half medusa gorgon. Obviously a play on the bipolar disorder stereotype. So I commissioned it to to several Russian artists in row. They all claimed to have pixelart and animation skills. Yet the best they were able to produce is the following:



Back then I've shelved the sprite, since it was not immediately needed in the game. But recently I had to finish it, which I did myself:


Have to remind you, that I'm no artist - I'm a programmer and I dislike drawing, yet I was able to do it better than a professional Russian artists with art school behind their back. Guess programming is a universal skill, allowing you to fill in any role, since you already know about light light propagation and animations from your 3d graphics experience. At one gamedev forum I've noticed a math professor guy doing okay isometric pixelart sprites for his games, while most artists usually have problems with isometry, especially animating it, while in Kyiv I met a girl who did Ada programming in university, but now does art for living (since nobody in Ukraine needs Ada programming after the fall of USSR). So yeah, if you want to become good artist, care to learn the frigging geometry at school.

Now you may wonder what was wrong with the original Witch sprite. Obviously animation is non existing, but artists also totally botched the palette, proportions and and art style of my game, despite me providing them existing sprites as example and explaining about proportions and the palette to use. I use that DOS gamma-level palette, inspired by games like Doom and Warcraft to get the retro feel. In fact, I took Warcraft 2 palette for player team colors as the reference point The sprite is also very tall and fragile looking (in fact it is taller than elf and orc sprites), while game sprites have look sturdy looking (think Warhammer pieces) and easily discernible in the whole mess happening in XCOM-style games.

On the other hand, I worked with American and Mexican freelance artists. There were no problem with them. All animations were good. They were newbies yes, but responsible ones. Guess gamedev is hard only when you have to deal with my compatriots, because I actually wasted more of my time explaining Russians what to do than saved by their unhelpful help.

[Nikita_Sadkov]

Experimenting if it is possible to have hexagonal map, but with with nicer boundaries. Also, time to say farewell to the Freeciv tileset. Also fun fact: these hexes correspond nicely with isometric cubes.

[Nikita_Sadkov]

Larger sprites are bit easier to discern and click at and I don't need to have separate set of smaller sprites, which is pain to maintain. But the grass texture is a bit messy downscaled from 256x256, since low frequency details became high frequency.

[Nikita_Sadkov]

Now there is a tricky part. The hexes in the tileset I'm using are not actually isometric, while buildings on top of them are indeed isometric. That is because isometry implies 45 degree angle, while hexes are straight top-down. Most artists and gamedevs don't notice it, since it can look fine. So we have games like Heroes of Might & Magic and Battle for Wesnoth using perfect hexes. Cant blame them, HoMM was produced by a hobbyist gamedev, who cared more about good game design, while Wesnoth is made by a hobbyist programmer, who wanted to make a clone of an old Japanese game, Master of Monsters. In the original Master of Monsters, player pieces were more like card tokens on a tabletop board, so they were looking fine, but Wesnoth tried to imitate Warhammer look and feel, so isometric angle is explicitly implied. Still Wesnoth doesn't use the pure isometric projection, but the so called "military projection", where angle is less than 45 degrees.

Then we have Fallout and Age of Wonders, which actually use properly angled hexes, because people behind them were very professional. Although Age of Wonders doesn't use the pure isometric angle, but something between the isometric projection and military oblique projection (i.e. the one used in Warcraft 2 and Ultima Online). Similarly to Age of Wonders, Baldur's Gate games too use their own unique angle. Although in BG's case that probably strives from the game's engine being originally created for an RTS, so they wanted more pure top-down angle. Germans from Blue Byte also used proper hexes in Heroes Online, although art-direction wise it was far inferior to Van Caneghem games or even Blue Byte's own games, guess they outsourced it to some freelancers.

Anyway hexes for the true isometric projection always look like this:


Should I squash hexes in my tileset? Well, such angle gives 2-times larger vertical resolution - two times more stuff on screen! I've a restriction in that I want to keep the world map small and fitting single screen, since main game happens in the site exploration phase, so squashed hexes could be useful if I need more hexes on single screen. Unfortunately all the terrain sprites are made to stand on the pure hexes. They can't be squashed, only resized down, making them too small.

[Nikita_Sadkov]

Just a few hours are required to implement hexagonal tileset. I lost like 1.5 hour, due to Symta being underdeveloped. It is a bit hard to use language without interactive shell to inspect the cause of bug inside the running program. Interactive shell requires JIT, and I never got to it, knowing that implementing and maintaining it would require a lot of work, so I don't want to do it until the language design is set in stone. The language itself needs a lot of improvements. It would be a challenge to implement them, while also moving the game to the new language version. Since the few features are total game changers, and would eliminate large sets of bugs, but require changing syntax and scoping rules.

But I doubt the progress would have been that much faster, had I been using Common Lisp, instead of making my own language. Then CL is a bit clunky and non-portable.

Anyway, here is the version with squashed hexes. Yeah, it doesn't look good, but there are two times more space and it plays nicer the isometric unit sprites from site exploration part.

[Solarius Scorch]

I'm not a big fan of hexes, because you can only move in a straight line in 3 directions, and everything else is a zigzag. But you seem to have pulled it off amazingly. It all looks so great.

[Nikita_Sadkov]

I'm not a big fan of hexes, because you can only move in a straight line in 3 directions, and everything else is a zigzag. But you seem to have pulled it off amazingly. It all looks so great.

The problem with continuous world is that when you add obstacles it gets really confusing, where and how player can move. Most pathfinding related function also get out of control. It was playable but I got uneasy feel from it. And I'm the one who develops the game, knowing every little bit of it. Common player will get frustrated to no end with all these guard ranges and continuous related stuff. With cellular world everything comes in naturally and the code also becomes several times smaller, than the code for continuous world.

If you dislike hexes, then there are also Dirichlet tessellation, allowing to have arbitrary cell shapes. In fact, hexes are just a special case of Dirichlet space partitioning. I know exactly two games, which use Dirichlet for cells. First one is Russian game, Eador - some Heroes of Might & Magic clone, with emphasis on RPG elements, but I haven't played it. Still original Heroes 3 used Dirichlet to create distinct areas for each player, which were then filled with mandatory or arbitrary objects: i.e. each player must have a sawmill and an ore mine - one of the more dubious van Caneghem's decisions, but well, people used it to create some cool atypical maps, where say wood is scarce (there were historic real world scenarios with not enough good wood to build ships).

The other one is Europa Universalis, which tries to be as realistic as possible, but retain large basic cell size, therefore implements arbitrary country borders, instead of subdividing countries into hexes. Dirichlet tessellation can be useful if you want to generate a realistic political map for the XCOM-like plane, but for a simple fantasy game world map, it would be an overkill.

Anyway, I've decided to use squashed hexes, but allow sites take more than 1 hex, like in the classic Panzer General games. I've also used the grass texture as is, without downscaling it. Since the game has comical style, it is okay for it to have exaggerated non-realistic proportion (i.e. grass blade being the size of mountain). At this scale grass is relatively low frequency and looks fine. But forests and mountains need to be fixed using some separate method, since downscaled and squashed they look just horrible, like literal piles of dog feces.

[Nikita_Sadkov]

Now it looks more like it.

[Solarius Scorch]

Yeah, I get the idea from Eador and EU. It's a good system for games oriented towards provinces, but... that's pretty much it. If you want some other focus, it just doesn't make sense.

But this reminded me of something. When I was around 14, I made a home-made Transformers board game (it was damn big, every Cybertronian I could find any info on had their own stats), and the map was composed of intentionally uneven tiles. The general idea was that flat, easily traversable terrain was composed of big tiles, while difficult terrain was more densely packed. Every unit could move for a given number of tiles per turn, therefore open plains allowed fast travel, while mountains or bogs would be slow to traverse. However, shooting ranges as well as flying movement were expressed in cm, not fields, so terrain density didn't affect them. This system was surprisingly good, I am still quite proud of this game 25 years later, so I thought I'd mention it.

But if we talk even tiles, then hexes are fine. I like squares better, as they don't feel so jarring to me (as long as you can go diagonally and such movement costs more), but maybe it's just me and my fixation on X-Com-like things.

[Nikita_Sadkov]

The general idea was that flat, easily traversable terrain was composed of big tiles, while difficult terrain was more densely packed. Every unit could move for a given number of tiles per turn, therefore open plains allowed fast travel, while mountains or bogs would be slow to traverse.

I'm pretty sure that is called quadtrees. It is in fact used for pathfinding in continuous space and for algorithms like ray tracing.


Now with large city sprites and some variations for mountains it looks a bit better (and definitely order of magnitude better than the Freeciv tileset with cockroach sized sprites). The hex shapes along the shore are actually a bug, but I think about leaving it alone for now, because it hinted me about the idea of shaded grid blending nicely into tileset, instead of the of the usual out place grid drawn in some annoying color.

[Nikita_Sadkov]

Now hex worlds have appear to have only one proper way about laying down rivers and roads. First you imply there is some there is space between hexes, now rivers can go along along hex edges, never approach hex centers, while roads go though cell centers, so units spend additional move points, when trying crossing into hex divided by river. That means units can follow roads, and cross rivers, or follow river along the edge. Very small number of hex games uses this rule, and they are all relatively modern, like Age of Wonder and Blight of the Immortals.

Most games, like Wesnoth and Panzer General, use half broken approach. For example, Wesnoth doesn't have small rivers, only large 1-hex sized ones. They don't look nice, but that was the original Master of Monsters design, which Wesnoth cloned. Later 1992 Master of Monsters, Rings of Twilight, actually implemented small rivers, which gone through centers of hexes, with the possibility of them messing with roads was prevented by the fact rivers came out of vertices, while the roads always crossed hex edges. Panzer General rivers were similar to later Master of Monsters ones - they also came out of hex vertices coming through hex center, but roads also came out of hex vertices, which was really dubious decision.

Original Japanese Daisenryaku (Panzer Genral is actually its faitful clone), one of the first computer hex strategies, just used large hex-sized roads, but 1991 version of it used proper road and rivers, although both connect though the edges, coming though hex centers, giving raise to non-uniformity of another kind. And then some hex games, like Armello, don't have rivers and roads at all.

[Yankes]

Then I some time ago playing with design of game (similar to Master of Magic), I come to conclusion that both walls and rivers should be placed on edge of hex.
Only exception would be rivers that are very big but then it will be not "terrain" but "water" tile, and normal units could not enter tile with big river.

[Nikita_Sadkov]

Then I some time ago playing with design of game (similar to Master of Magic), I come to conclusion that both walls and rivers should be placed on edge of hex.
Only exception would be rivers that are very big but then it will be not "terrain" but "water" tile, and normal units could not enter tile with big river.

It all depends on your game's mechanics. It is still possible to resolve roads/rivers clash several ways. For example, if river always comes out of an odd hex vertex, and roads always out of even vertices, then there wont be any inconsistency.

Rivers in the center of hex take more space, while river going along the edge allow placing anything in the center, like i.e. there can be a fortification surrounded by rivers from all sides. If rivers are allowed to go through hex centers, then that fortification would be sitting on top of a river. so it would get messy to decide, if it stuck in water, or supposed to be on some island inside river, or on one of the banks. That is important, if you have bonuses/penaties associated with rivers. I.e. in Panzer General traversing river incurred movement penalties and units on river hexes were vulnerable to attacks. Original Panzer General had such rivers because it is easier to implement them. Although it varied implementation. In PG1 engine rivers connected though corners, while in PG2 they connected though edges. PG2 also had some nice tileset at strange angle, which while not isometric still implies squashed hexes, but PG2 for some reason havent used them, using usual hexes.