PlayTechs: Programming for fun

Saturday, March 10, 2018

I marked it as an Incomplete in the 7DRL challenge because it is very short and doesn't feel much like a Roguelike. The closest thing to it is probably Unexplored, an action Roguelike with a similar top-down view. Unexplored has some nice dungeon generation techniques. I felt like its combat was underwhelming, though.

Sword Horde was an attempt to work on group movement and formations. I didn't get very far on that because I needed a core combat mechanic, which is something I'd been putting off for a while. It was good to spend some focused time on developing the core though. With some tuning I feel like this could be a workable base for a bigger game.

I had talked with a friend about Dynasty Warriors since that is the main franchise I can think of that handles a hero versus an army. I have played a little bit of Dynasty Warriors over the years but probably not more than a couple of hours. Consequently I was working mainly from my own imagination and from previous combat prototypes that I've made.

Some of the ideas that were on the list and didn't make it in:

Enemy types. The obvious things: a boss who's bigger, slower, hits harder, has more hit points. A guy with a shield on one side. Projectile launching guys.

Formations. I was thinking the guys would be in groups of three or four, with a marked leader. Any group with a leader would attack in a pattern. If you kill the leader the guys attack in a less coordinated fashion until they can hook up with another leader. Whether patterned or chaotic attacks would be harder to handle is unclear; ideally the former though.

Combos. This is the core of Dynasty Warriors and I did not get this in at all. It would have been relatively easy to do a combo meter and have some area-of-effect attacks that you can discharge when the meter fills to certain points.

One of the things that has bothered me about these kinds of games is that the player has free run of the whole battlefield. There's very little feeling of enemies denying access to spaces. My initial experiments were aimed at trying to produce a well-defined territorial boundary that would move as you fought the battle. In the end I scrapped it and let the allies run around on the battlefield with you.

I suppose one of the problems with having a well-defined front is that it reduces the dimensionality of the encounter space. In a 2D-surface-based game you have a line where the action is occurring. With ranged weapons that might be a little less of a hard line, but it's still a smaller space for action, and at any given time you're not using the whole space. I think the idea of a battle front is still useful, though, to try to guide the player toward the action.

Figuring out how to make armies look like they're fighting but still keep the player as the driver of the action is an interesting challenge. In the little bit of Dynasty Warriors I've played it felt like they were lazy on this front. Guys are mostly just standing around when I come upon them.

Combat targeting is a hard problem to solve. I have some ideas of improvements that could be made but it's hard to know what will work until you try it. The characters kind of flip themselves 180 degrees if they think it will help them swing at a better target.

Combat flow is hard, too. Sword Horde makes use of Gabriel graph structure to decide who is eligible to do a running-charge attack at the player. Only people who have an unobstructed sphere of space between them and the player are allowed to attack. Once they have started charging they keep charging, which can mean they are trying to find their way through crowds to get to you. But the initial decision is based on clearance.

The biggest problem, I feel, is that it's hard to predictably avoid getting hit accidentally while swinging at someone. I did a lot of tuning—adjusting elasticity and friction, mass and moments, sword lengths, attack timings, attack steering directions, stun durations—to try to come up with something that would reliably separate the characters after a hit. It's not really there yet. It seems like maybe it's close. All of the afore-mentioned parameters interact with each other, though. I spent a ton of time instrumenting and testing the charge attack.

You can see some of the thinking in the debug display above: the orange guy is moving toward the pink disc which is offset to the left side of the yellow player (because orange is planning to make a counter-clockwise swing). The player's not moving, so its predicted position (the tiny pink disc) is centered in the yellow disc. The orange guy is predicting that based on where he wants to be and how fast the distance is currently closing, he should launch his attack when the gray disc touches the yellow player disc. If the player were to lunge toward the orange guy the gray disc would expand accordingly, triggering the attack earlier.

Friday, March 9, 2018

It ain't looking great. I've got the thirty seconds of fun (as Jaime Griesemer said once about Halo) but that's about it. There is still a fair amount of tuning to do on that thirty seconds, too.

Today's work:

Link statically to the C runtime library, so I don't need to have people install the DLL

Fool around with an enemy territory mechanic, with friendly soldiers and enemy soldiers marshaling on either sides of the front

Simplify the debris system

Add a player health meter

Tune the runnning-charge enemy attack

As part of doing the health meter I ended up learning about OpenGL scissoring, so I could ensure that if the window was resized you wouldn't be able to see outside the play area. I'm using the area outside to spawn in enemies now so I want them to move in across the edge.

There is still a lot of tuning and bug fixing on the core combat feel, without going into new features like a boss or combo attacks. The game really needs things like the latter to give the player interesting things over a longer time scale. I also don't have any text rendering (or texturing) capabilities right now. So the game's very bare-bones.

The territory was kind of a waste of time. I'd thought perhaps it could help serve as a place for the player to retreat to for a breather, or could give a medium-term goal of pushing the battle front to the right. But it doesn't really add anything in its current form.

I'll put the game up on Itch.io at the end of the day tomorrow for anyone who wants to try it out. I'm not sure if I'll enter it in the Roguelike challenge for judging; it really isn't a Roguelike in any meaningful sense. At least I've gotten a chance to work on some things I've wanted to flesh out for a while, and it forms a good basis for further experiments.

Wednesday, March 7, 2018

It's looking increasingly unlikely that I'll have anything even remotely resembling a Roguelike by the end of this week. On the plus side I've got some cool crowd motion.

This morning was spent working on the enemy steering behavior so they would behave better in groups. It's all a bunch of damped spring type things that generate forces on the enemies. There is a force toward/away from the target; a much smaller lateral force to bring orbiting to a halt; and forces to repel enemies from each other. The neighbor repulsion force never has any component pointing toward the target, though. This keeps large groups from compressing in on the target, and reflects how people avoid each other; they mostly only pay attention to the people in front of them. Finally, the desired separation distance between neighbors is a function of distance from the target. This lets groups move close together to approach the target and then spread out when they reach combat range.

The afternoon was spent trying to improve the player control scheme, with only minor success. I tried a couple of schemes. One involved “dragging” the sword like a water-skier behind a boat. Another went for simple dual-stick control: one stick to move and another to swing the sword. I've always thought about trying this, so I'm glad I did, but it really doesn't work. It takes too long to move the right stick for the speed of gameplay I'm targeting, especially if you have to swing it through an arc.

In the end I settled on a couple of refinements to the prior scheme, which involves auto-targeting the nearest enemy and then swinging the sword into a forehand or backhand stance relative to that target. I've got some adjustments to help minimize rotation when switching targets; it will switch from a forehand stance to a backhand and vice versa.

Tomorrow I will work on enemy windups and attacks. With luck I'll have a simple combat game by the end. Maybe with a boss enemy who is bigger, more dangerous, etc.

Tuesday, March 6, 2018

I ended up pushing through and keeping the Chipmunk physics engine in place. I'm glad I did. Once I'd managed to get back to where I had been in terms of the movement feel I was able to quickly get the sword contact working, which would have been quite a bit more work to do myself.

It took a couple of tries to figure out the best way to handle movement. The Chipmunk forums suggest tying the main physics body to a kinematic body via constraints, and then setting target velocities on the kinematic body. I found it was much easier to just use forces and torques. The things I'm doing aren't stiff enough to require anything more complicated. I ended up sub-stepping the physics sim anyway, to enable better sword collisions. It's running at 240 Hz right now. We'll see whether that holds up as I add more people.

I'm still behind where I wanted to be. It's not technically a game yet because you can't fail. It's starting to be a bit of a fun toy, though.

Tomorrow I'm going to turn this into a real game. The enemies will try to fight back. There will be more than one, which means I have to revisit the player control scheme. Right now the player character orients toward the closest enemy. Pressing the button swings the sword between forehand and backhand stances, but with the re-orientation to face new enemies that can do some weird things. It also doesn't really say what to do when there are no enemies around.

Monday, March 5, 2018

My goal has been to start with basic movement and one-on-one combat and expand outward from there. By the end of Sunday I had a decent-feeling movement and sword-swinging action. I didn't have any collision between swords and people yet, though. The thought of doing that myself was somewhat daunting so I decided to bite the bullet and switch over to a 2D physics engine. I've used Chipmunk in the past so I went with that.

What followed was the usual wrestling with Git to get the project set up. Eventually I did, and converted things over. But I haven't been able to recreate the feel of what I had. In particular, the AI movement is really loose now.

I think it may be quicker ultimately to go back to doing things myself, implementing sword collision myself. I'm weighing it. I need to get on to group movement patterns and challenge gameplay.