Turn based strategy game (UPDATE 06/19/18)

Hi folks

This is my first post

I've started on a turn based strategy game. I figure its possible to do a 3 units vs 3 units given the limted amount of sprites available. So no epic battles but seems like 6 units shooting and bashing eachother should be enough to be challenging.

I've built most of the game engine, but it's still a far cry from being finished. I figure it would be nice to get some feedback half way through

It has some interesting things like a shortest path algorithm and a line of sight algorithm

https://github.com/paulmaaskant/guardia ... ctions.txt
https://github.com/paulmaaskant/guardia ... r/game.nes

Last Update (08/01/18)

- introduced the deployment roster screen
- introduced the JUMP actions
- revised rules around attacks

all feedback is very much appreciated! Hope you like it!

This looks really cool. I like the 3/4 perspective, and I think the setup has a lot of potential. I like that the mechs overheat after firing too much.


Some small suggestions:

Have you considered making the d-pad axis "diagonal" with respect to the screen? i.e. up goes along the grid up-right, and left goes up-left? I think that might feel a lot more natural than the staggering horizontal motion and corner-hopping vertical motion it currently has. It would also make selecting the facing direction easier, i.e. just press the direction you want, rather than the trying to stop the rotation in the direction you want.

The text appearing 1 character per frame is really slow when there's a whole screen of text. I think it would be appreciated if holding a button would accelerate it to e.g. a line of text per frame instead.

I'm not sure if you can see it in NTSC, which will normally have the bottom 8 lines of the screen hidden, but the vertical scroll seam is visible there. Since you're using single-screen mirroring with the HUD overlay, you could actually hide the seam up there instead if you wanted to.

The bullet effects currently have way too many sprites in a line at once, I think. It totally cuts out the picture of the mech on that scanline, at least when firing horizontally. Could probably get by with only 1 or 2 bullet sprites that move quickly?

Thanks for taking a look rainwarrior.

And thanks for the suggestions!

Great first post!

The game looks like it could be really fun, and i'm a big fan of isometric gaming.

This is a minor thing/maybe not even a thing that probably only came to my mind because i've spent a lot of time with making nes music lately, but i was thinking... what if the cursor movement speed (and it's subsequent sfx) was an integer with an even division-relationship with the tempo? Would that result in a (slightly) more "harmonious" cutting of bgm notes than when cutting them at off-beat intervals? It's not even a nitpick (it is fine as it is), just something is started thinking about.

The green phosphor rain in the background might be a bit distractive when it goes on all the time. Maybe it could be limited to some circumstance?

One more thing: you might want to turn off sprite rendering until the HUD split? The HUD doesn't seem to use sprites at all, and if a mech goes up there it will overlap it. Conversely, a mech sprite at the bottom of the sprite cuts off way early: it would be nice if you could see the partial sprite all the way to the bottom of the screen (and maybe important to know they're there for tactical decisions).

I really like that the buildings correctly overlap the sprites, by the way.

You could disable the left 8px to hide the horizontal scroll seam. I'd also like to have diagonal scrolling (with both up/down and left/right pressed).

Thanks, calima & FrankenGraphics. That's some good stuff. I appreciate your help!

@ rainwarrior, I thought I'd start with your suggestion to turn of sprite rendering until the split. However I then realized that I rely on sprite 0 to trigger the split. So I'm guessing your suggestion only works if I trigger the split another way. Right?

This is amazing, great work so far!



If you really wanted more than 3v3, you could probably draw the non-active mechs as part of the background. It would take a huge change in the engine, and would require a bunch of complicated background tiles to make it work, so I'm not remotely suggesting you should do it, but just wanted to throw it out there




This would be the feedback I'd leave as well. That and the sound for selecting an action sounded more like a "cancel" sound than a "select" sound to my ears, which confused me a few times.

That said, again, I'm really impressed. Good work.

Ah, yes you can't have a sprite 0 hit if it's disabled. There are other ways to do it, though. (You could hide the sprites above the line "manually" and do something about the 8 rows where they might overlap the edge, or use an IRQ for timing, or cycle counting, etc.)

Thanks gauauu, appreciate your input! That's a very interesting idea!

I've implemented two suggestions so far

d-pad controls for the cursor are now aligned with the grid coordinates. Since I have grown accustomed to the staggered navigation I have to admit it does not immediately feel more intuitive. It might, after a while. Interested in what you guys think.

With respect to the direction facing: one of the obstacles I've created for myself is that the grid is hexagonal, so I need to support 6 directions. The d-pad is great for 4 or 8 directions. That's why I stuck with the clock - counter clock controls up till now. But I will take rainwarrior's suggestion and see how it works.

Second, I've built in a speed mode for the text screens. Pressing A again and it will speed up from one tile per frame to one line per frame.

Thanks!

I haven't tried the demo yet, but from what you said it sounds like there's a status bar on the top and a playfield on the bottom. Apparently it's NES standard to leave sprites above the status bar in those cases. However it's also standard to have sprites hidden behind it when the status bar is on the bottom.

The only game I remember seeing with sprites hidden below a status bar at the top is Castlevania - Bloodlines, but it's not a NES game. I found this to look super-weird.

Ah! You know, I actually didn't read it as hex. I can see now that you've put 3-corner markings to kind of indicate this, but I think just the straight diagonal lines of the map itself suggested to me that it was just a 3/4 perspective square grid. Visually these two systems would put their cells in the same place, but of course hex has 6 connections instead of 4, and now I understand why it's a control design problem with the d-pad.

The controls I suggested strongly de-emphasize that vertical connection. I can see why that's not desirable.

I suppose an analog control might be ideal, but since that's not available maybe another alternative: give the user a cursor that they directly move in screen space (starting from centre of the cell to move from?), and the current selected tile is just whatever is currently under the cursor. That would probably also work for facing too.

I'm trying to think of any games I know of with a d-pad + hex grid, but can't think of many. (Mouse control comes much more readily to mind for hex games.) Nobunaga's ambition did it like your first version, staggering when moving left to right. There's Godzilla, where left and right are do-nothing leaving only 6 directions; I don't really like how that feels, personally, but it's at least another option. There's another called Conflict where you select a unit with the "cursor" idea, but then moving the unit becomes a rotary control + chosing to advance.


As far as visually understanding the hex grid nature, I see that you list the cell distance in the corner, which is useful now that I'm looking for it. Maybe some way of highlighting the current path directly on the playfield could help too? Hard to think of things that would work well on the NES, but for example you could have a coloured hex-shaped sprite that animates along the current path? If you drew that sprite last (i.e. under everything else) and only one tile per frame it would be like a flicker-transparency. Could even change the colour of the sprite where the path breaks from walk to run, but of course having enough palette space is always a problem on the NES.

Yes, it's quite common on the NES to just not solve the problem.

However, in this particular case we have 4-way scrolling. Sprites-over-the-HUD cases are easy to minimize in a horizontally oriented game (and often desirable), but when you can vertical scroll I think it's a lot different. Actually, the only NES game I can think of right now with vertical scrolling and a top HUD is Battletoads, but it doesn't even try to hide sprites up there.

It's very easy to find examples in the 16-bit era though that do have 4-way scrolling and hide those sprites (e.g. Super Metroid, Contra Hard Corps, Gunstar Heroes, Shinobi III, could probably find tons more...)

Teenage Mutant Ninja Turtles II: The Arcade Game has a top status bar and briefly scrolls diagonally.

On second thought, the distraction i experience with the background rain is maybe not due to its constant duration, but rather the intensiveness of the animation and how it has a 1x1 tile report. A looser intensity may also help masking the map clashing on a psychovisual level, at least a bit.

I noticed you have BMO doing a cameo in the sprite sheet

On the sprites per scanline discussion:
Not all units need to be 2 tiles wide, necessarily. A simpler tank, plane, hovercopter or reconnaissance unit could perhaps fit in one tile (if a unit is flying, another tile to mark the spot with a shadow would help). It could perhaps be a nice contrast to the size of the mechs, although the buildings are already doing that. It's a challenge to come up with a good looking 1 tile wide unit, but it is doable, if you ever want to.

@ FrankenGraphics

Yep, BMO helped me out when I was figuring out how to control multiple mechs on the screen and switch control between them. I might need him again in the future

Great point on the one tile units. Once I have a working AI I will create more unit types I will try it out. I like the idea of flying units with a shadow. It also depends on how much memory I've left to keep track of them.

btw if you press select in the title screen you can see the animation of the unit types (b toggles types, a makes them move).

On the subject of AI, this is going to be my logic:

; 1 select the most attractive player controlled target
; consider all player units
; lowest score wins:
; (100-ranged attack hit probability) + target hp + distance
;
; 2 determine available options
; - ranged attack 1 on target
; - ranged attack 2 on target
; - close combat on target
; - charge target
; - move / pivot towards attack position on target (this is complex)
; - cool down
; - move towards defensive position (this is complex)
;
; 3 score all available options
; - based on relevant factors (AP, HP, expected DMG etc)
;
; 4 some randomness: pick best option 70%, second best 20%, third best 10%

The challenge is to minimize the number of times that you need expensive subroutines such as calculating the shortest path and calculating if there is line of sight.

So for example, once the AI decides that the best available action is to move to an offensive position, the AI will need to find a grid node that puts the AI controlled unit close enough to the target that it's within its range, has line of sight to the target and is reachable from the AI units current position.

Would appreciate any insights folks have to offer

@FrankenGraphics
The rain is less intense. I started using 4 tiles instead of 1. You were right, this is better. I feel I should be able to pixel a more convincing rain but maybe its just not possible with only 4 frames

@rainwarrior
I took a first stab at showing flickering waypoints to show the movement path. It's a nice feature, thanks for the suggestion

Even with the slow NES processor, you can probably get away with a lot of slow calculations since it's a turn-based game. An extra half-second of processing during an enemy's turn is an eternity in terms of processing time, but wouldn't impact the game much at all.

That's a really good point. With a little luck/effort, you may be able to silently perform the calculation all while signing the turn transition to the player. I'd just recommend keeping the transition as short as needed be and let the calculation spill over if it needs to. That would appear as the enemy thinking/deciding. I imagine that should be less jarring than dragging out the transition sequence visually/functionally.

(Old) chess games will often make you wait while the computer is thinking. Playing some of these oldies in emulation might help get a feel for how long is too long. Besides the fact that i could never beat a particular game when set at its hardest difficulty, i also avoided that setting because the cell phone in question took way too long.

Hm... How do you hide sprites that are touching the HUD? The only way I can think of is putting 8 empty sprites at the row of the HUD. Is there another way? Disabling sprites in PPUMASK at the correct y-pos, maybe?

I believe that was the initial suggestion

This is good! I think this really helps a lot to teach the player how pathing works, and how the hex grid is connected.


I briefly suggested a couple of possibilities in my earlier post but here's some more explicit explanations:

• Using an IRQ to enable sprites via $2001 at the correct scanline is probably the easiest way. This game in particular seems to be using mapper 25, so IRQ might be an option?
• Manually remove sprites coarsely above the split point, and then put 8 hidden sprites on the bottom row to more finely block sprites that overlap there.
• Write a cycle-timed NMI routine and just create a timed wait until the split point to enable sprites.
• Just move the HUD to the bottom and continue to use sprite 0 hit.
• Just don't bother solving the problem.

TBH, in this particular game the main problem I am seeing is that the sprites disappear before the should be hidden by the edge at both the top and bottom; on both sides this creates situations where it can look like nobody's standing there on cells at the top of the bottom of the screen-- bad information if you're trying to make a tactical decision! The same thing happens at the left and right edges too, actually.

Hiding them above the hud is just something I'd probably pursue for visual consistency but it's not really a gameplay issue? There's another visual issue at the left and right edges too, i.e. if a mech moves from offscreen they will appear briefly at the wrong side while moving across the edge, but at this point I'm assuming it's all subject to change/revision anyway. The left and right edges tend to be tricky on the NES, as I'm sure everyone's aware.


Actually, on the subject of things happening at the edges it might be important to note that a lot of TVs, especially older ones, will cut off some of the edge. Everything at it is currently seems to go right to the edges, like the pilot's face, and this could be a problem. Nintendo and other console publishers have always given guidelines about keeping anything important (especially text) away from the edges of the screen by a small margin, and they still do so even now in the HDTV era. See: Wiki: Overscan

Thanks for putting in the time to help me rain warrior. I very much appreciate it.

Yep, mapper 25. I started with mapper 23 but that didn't work on my powerpak.

You are right that its all subject to change at this point. To keep up the momentum I tend to leave features in a "good enough" state and then move on to the next thing. Perfecting and refactoring things takes forever

I will try to use the IRQ solution. I still have to familiarize myself wit the workings, but it sounds promising. That will take care of the top/bottom cut off.

Currently the game does a very crude cut-off based on the screen coordinates of the grid position (iow not even sprite coordinates) and only for the mechs. I will have to bring it down the the sprite level anyway, because most of the effects (including the new waypoints for movement) completely ignore the left/right. Shame on me!

As for tactical decisions, you are right that its key to know where the other units are. And probably not only the ones that are right on the edge. I have thought about how to inform the player of the location of other units on the field (without having to scroll over the map). One of the things I intend to try is markers at the edges of the screen, but until now that has gone into the category 'perfecting things' .

It is possible to hold B to scroll the map while choosing a facing direction. At least that way you know from which direction you can expect the enemy to show up.

Thanks for the link. I think I did come across it some time ago (I spent a serious number of hours on the wiki and this forum before before I got my code to work to do ... well ... anything ). The challenge is that there is so much information that needs to go into the HUD, while trying to keep the three sections clearly defined (player - action - target). I expect I could make the "action" section less wide have some margin on the edges.

Ah, I understand now why you cannot use a SPR0-hit to check for the end of the HUD... That was the missing link.

Just a small progress update.

I've added a simple AI! I have not incorporated all the factors that I would like the AI to consider, but I've started on the framework and I think it will do nicely. Turns out that computation time is not really an issue at all. The AI will skip some frames while deciding on the next move, but I think it is hardly noticeable (as some folks had already suggested in an earlier post). It starts to feel slightly more like a game now

UPDATE

- Rewrote the engine so that all grid node meta tiles can be controlled individually. This allows for cool stuff like showing debris where units where destroyed permanently, or mark specific map nodes for game effects.
- Each unit is now displayed as part tile/ part sprite, which allows the game to show a lot more units. Up to 16 units, to be exact.
- Added missile attack animation (wpn 2)
- Worked on the map tiles
- Worked on the AI and game mechanics
- New object model

the link is in the original post

all feedback is very much appreciated! Hope you like it!

I'm still working on this game, although I am losing some of my original steam. Next step will be to have a TEAM configuration screen, where the player can combine mechs, pilots and weapons him/herself.

I've been playing a lot of "BattleTech" and "Into the Breach" (both excellent) and took some inspiration from both of those games.

Last Update (06/19/18)

- Added more of everything: new attack (surge laser), new pilots and new units
- Added an event mechanism, e.g., to initiate HUD dialogs upon certain events ; taking a bytestream as input, so that it can be different each level.
- Changed the game mechanics (inspired by the excellent recent game BattleTech), especially the BRACE and EVADE point mechanisms
- Re-desgined HUD to show more information with less tiles
- Fixed many bugs
- Demo now has a 3 versus 3 battle. I'm looking for the ever elusive 'emerging complexity' that make games of this genre engaging

This looks great, glad to see you're still chugging along!

Thanks for the encouragement SoleGoose, I appreciate it!

I've been working on a roster screen that allows the player to assemble a team of 3 mechs, being able to choose the mech type, the pilot and 2 equipment slots. It works, but I still need to implement selection restrictions, e.g a pilot should can only be assigned once and unique equipment.

I've also included a JUMP action for the lightest mech available (GEIST) allowing to move over obstacles and gaps. Additionally, a unit that jumped will be better at evading attacks until its next turn, at the expense of generating a heat point and reducing its own accuracy

I have also revised many of the rules around damage / to hit percentages. I took inspiration from the table top game ALPHA STRIKE, i.e., instead of having several weapons that you'd need to toggle and figure out (= not fun), the game now uses the a single damage profile per unit indicating how much damage it can inflict at different ranges.

The damage profile of a unit can be improved by equipping it with items or weapons, e.g., adding a ‘machine gun’ weapon to your unit improves damage to targets that are positioned 2 or 3 hexes from the attacking unit.

This allows for different units with specialized roles, like close combat mechs vs long range fire support, while keeping the complexity towards the player at bay. I also like that it makes movement far more relevant.

Next I will be improving the AI’s actions and many other loose ends, before moving on to the meta game – which involves moving from one mission to the next, XP points, gaining of items and all of that.

Still spending time on this game whenever I can. My plan is to create a story line of four consecutive missions. Currently the demo is set to run the 3rd mission only. I've added many small features, gameplay improvements and bug fixes since my last post, so everything is a little bit better.

I'm also working on the meta game design, i.e., upgrading and changing mechs in between missions. The plan is to work with a single resource;mission time. All of possible actions like, repairing armor, mounting new weapons, changing pilots will cost a certain amount of mission time. The time it takes to complete a single mission is also subtracted.

That way I hope to create an incentive to take more risk during missions; charging forward to complete a mission quickly may reward you with more time for prepare for the next mission, while a more cautious approach may be a more sound strategy now - but it leaves less time to prepare for the next mission.

I've also created a new map (see attachement) and a new mech bay menu.

The controls are still the same
(A) always means continue / confirm
(B) always means toggle / cancel

In the MECH BAY SCREEN
hold & release A to swap equipment
press B to toggle between mech bay 1, 2 and 3
press START to proceed to the mission