Finally, a new image!
This isn’t really a screenshot of Star Revolution. It’s a screenshot of a prototype of the tactical combat system I’m working up. I’m going to actually release this prototype when it’s completed (I’m hoping by the end of the weekend) and let you guys rip it to bits for me. If you’ve played any turn-based tactial games in the past (Jagged Alliance, Final Fantasy Tactics, Front Mission 3 or 4, Advance Wars, etc) you shouldn’t have any trouble figuring out how the system works, but I’m hoping that the changes I’ve made will make combat go a little faster and look a little more fluid.
I am amazed. You are somehow able to accomplish development despite your ownership of Oblivion. I haven’t gotten a single thing done since I installed it. Bravo!
Um…yeah. See, about that…instead of finishing up the combat prototype on Sunday, I played Oblivion for about eight hours straight instead.
Basically, I’ve hit a design snag and I’m not sure what to do about it. How do I handle diagonals?
1. Don’t allow the player to move on diagonals. This sucks. The arena is 17×17 tiles. It should take about 23 moves to move diagonally from one corner of the arena to the opposite corner. If I don’t allow diagonals, it takes 32 moves, which is 7 too many.
2. Allow the player to move on diagonals with a cost of 1. This also sucks, because now moving from one corner of the arena to an opposite corner only takes 16 moves, which is 7 too few.
3. Allow the player to move on diagonals with a cost of 1.5. This also sucks, because I’d have to throw the “phased movement” idea out the window and go with a completely traditional action-point system, and I don’t wanna.
4. Switch to a hex grid. This also sucks, because hex grids don’t fix this problem nearly as well as their proponents claim – yes, they are better than square grids, but you will still take too many turns to get to a destination hex unless it is directly on an axis with you – and in the absolute worst case, it’s no better than a square grid! Hex grids are also a pain to program.
5. Sigh. Get rid of the grid entirely, and use floating-point two-dimensional coordinates and vectors with interpolation to do the movement. This is what I had intended to do in the first place, but…well, it proved kind of hard to program. I thought I could simplify things for the prototype, but that is causing new problems. So…
So I don’t know. I will probably either say “Screw it, the prototype doesn’t have to be perfect” and go with option one or say, “We were going to use it anyway, let’s do the gridless movement” and go with option 5. I haven’t decided yet.
I say get the prototype working, possibly without diagonal movement, we’ll all play around with it and see what happens.
At one point, I had a pen and paper model that basically said it takes two steps to move one tile. And diagonals therefore took 3 steps. But when you break it down into steps, the temptation is to start dealing with “off feet” and the like.
I’m in favor of the floating point option. The advantage of this is that eventually, you can dump the tile-based terrain and have more 3-D landscapes (with terrain objects and the like) without changing your movement code too much.
I’d like to note that I like the tile grid a great deal, and I only mention 3-D landscapes because it still seems like a back of the box feature for people.
Or, you could alternate. The first step in a diagonal direction takes 1 move, then the next diagonal step takes 2 moves, then back to one for the next diagonal, etc.