OpenXcom Forum
OpenXcom => Offtopic => Topic started by: memmaker on March 30, 2020, 01:31:03 pm
-
Yes, yet another turn-based, squad tactics game ;D
I saw the really great thread of nikita_sadkov and thought I might post my own little side-project here. This is in no way as complicated as his project is or openxcom.
I will start off with what I do not want to do.
This is not a X-Com game and not a simulation.
No 3D or projectile ballistics.
No isometric graphics.
No complicated animations.
Inspiration for this project comes from the tabletop game "Space Crusade".
Also I saw a stream where someone was playing the video game adaption of the board game on the amiga and mentioned how cool it would be to have that on his tablet.
This lead to the main goal: A "Space Crusade" style (without the GW IP!) tactical board game for mobile devices with a hot-seat mode.
I also had modding in mind when starting this project and so I blatantly copied the YAML file modding mechanism from OpenXcom because it is so damn clever ;)
Since I want to do game mechanic development and not engine development, I am using Unity for this project. I am also more used to C# than C/C++. Still, kudos to all the C++ warriors doing their game engines with SDL.
What is working right now?
- Read rules from YAML files
- Rules for factions
- Rules for units
- Rules for weapons
- Rules for maps
- Rules for deployment of units
- Turns for unlimited faction
- Small unit movement and attacking
- Doors
- Pathfinding
- Field of View calculation
- Basic UI
- Area of Effect weapons
- Weapon targeting preview
- Usability on mobile devices (testing on iPad)
- Basic Hot-Seat gameplay (No win or lose conditions yet ;))
Here are some screenshots of the current state:
(https://iili.io/Jfchxe.png) (https://freeimage.host/i/screenshot-2020-03-30-121504.Jfchxe)
----
(https://iili.io/JfcjWu.png) (https://freeimage.host/i/screenshot-2020-03-30-121529.JfcjWu)
I am currently ironing out the quirks with big unit movement. Most problems are solved, but one is still there.
You can see it in the second screenshot. My big units have a list of relative grid positions (eg. for a 2x2 it is [0,0],[1,0],[0,1],[1,1]) which are relative to the position I use for referencing the unit. Currently my path preview uses that one square and just puts the other relative positions around it and then highlights them all. This, of course, has the problem which is visible above. If I want to move exactly one square to the north, I can't click there, because an occupied position is no valid click target. It is also not elegant, I really want the user to be able to click the tile to the north and the preview to adjust accordingly. I believe OXC has the behaviour I am looking for, so if I do not find a solution myself I might peek at the source ;)
-
Most problems are solved, but one is still there.
You can see it in the second screenshot. My big units have a list of relative grid positions (eg. for a 2x2 it is [0,0],[1,0],[0,1],[1,1]) which are relative to the position I use for referencing the unit.
That is actually a hard problem. My game has no multi-cell units, but it has multi-cell static object, which can have arbitrary form and topology (even with holes inside). You won't believe how many bugs they produced, especially their rotations.
I had moving multi-cell units in the Warcraft 2 engine clone I made previously. That was a bit easier, since there large units were always 2x2, and they used a special large grid (i.e. their grid was separate from the 1x1 units). Just like in the original Warcraft 2. For what I remember, Stratagus engine actually implemented these large units sharing grid with the 1x1 units, and it led to numerous nasty bugs, especially with the original Warcraft 2 maps. Starcraft devs also mentioned in the interview that larger moving units were a special kind of pathfinder problem.
But in your case you do need a shared grid. Typically large units are implemented as a colony of smaller units. That uniformity allows you to reuse most of the code. For pathfinder you will have to check for each subpart, and also for its rotations (if unit is say 1x2 or 2x1 - i.e. some long alligator). Alternatively you can drop the gird outright and work with the "tightness" map, representing how tight is that point in space. Now really tight spaces can be accessible only by insects. Such map can be produced out of the grid. It is more robust and much easier to implement that the actual grid-based pathfinder (think XCOM TFTD novice vs superhuman difficulty).
This is in no way as complicated as his project is or openxcom.
Exactly my thoughts in the beginning! Back when the project had just a basic 2d map and a simple chess-like rules. Keep it up! - we need to advance the genre, since as of now it got flooded with boring Final Fantasy Tactics clones.
My suggestion is to pick some core idea and then prototyping around it until it feels right. Like they did with Faster Than Light.
And maybe some existing engine like Unity. I spent like 1/2 of the time developing the framework (like resource management and GUI), instead of the game. But my case is special since my goal is developing the programming language, not the game. With an established engine you can just use an existing GUI framework and it will have a builtin resource manager.