Phalanx: Platform-Driven Performance Issues?

Oddly, the current build of Phalanx works fine on my Mac laptop . . . but stutters on my PC desktop. The stuttering is occurs when the CPU is in heavy use. I’m surprised to see that, since the PC has an i5-4590 processor; it’s pretty beefy CPU-wise. It’s certainly as powerful as the laptop is.

I checked around a bit, and it doesn’t seem like Unity (the engine behind Phalanx’s latest iteration) is known to have performance issues on PC. If anyone has insights, or things I might look into, your thoughts would be gratefully received. I’ll keep up the sleuthing on my end. 🙂

In the Lab: Phalanx 3D

I’d like to say that I have a grand new conception of game design to offer this evening, or at least a fresh insight. Unfortunately, I spent the day figuring out which of several rules for colliding phalanxes was best–not by doing something new and different, but by brainstorming and iterating, as one does. Then I ground out the relevant code: planning the architecture, writing, re-writing when I realized that my design wasn’t going to produce the gameplay I wanted, and finally debugging. No new techniques, just the usual approach.

Sometimes game design is a matter of keeping one’s nose on the grindstone.

Seeking a New Algorithm

I’ve run into an efficiency issue while coding the new version of Phalanx. While it’s not game-breaking, I very much want a game that’s meant to run 24/7 on arcade cabinets to be as easy on the hardware as possible. Thus, I thought I would raise it here, in the hope that someone might have insight.

Phalanx is played in real time on a board.

Screen Shot 2016-08-12 at 11.46.48 PM

Although the game is played in real time, it is effectively divided into turns–one turn per frame. In each turn, the movement rules are as follows:

  1. A piece can move if the space it is moving into:
    1. is currently empty, or
    2. will be empty this turn (e.g., because the piece in it is leaving).
  2. A piece cannot move off the board, or into a space containing water (the blue area in the middle), either of the goals, or another piece that is not going to leave this turn.
  3. Pieces move in number order, starting with player 1’s pieces and then proceeding through player 2’s pieces. (This is terrible, and messing with the algorithm is a good time to change it.) In the event of a conflict during movement (e.g., two pieces want to enter the same space), the earlier-moving piece takes priority.
  4. If a piece is part of a formation, the entire formation cannot move if any individual member of the formation cannot move.

To implement those rules, the game proceeds as follows:

  1. The game loops through all the pieces that want to move.
    1. All those that are moving into an empty space do so.
    2. All those that definitely will not move (e.g., pieces blocked by water) are marked as not moving.
    3. If a piece wants to move and is blocked by something that might get out of the way (e.g., another piece that hasn’t had its turn in the loop yet), that piece is skipped for this loop.
  2. The game repeats step (1) until all pieces have moved or been marked as not moving.

This algorithm consistently produces the correct results, but the performance hit is rough. Is there a better way?

 

All The King’s Theories

One of the great joys of game design is that there’s always something new to learn. There are so many fields involved in creating a game intended for public release that no one person can master them all. It’s always possible to find something new to explore.

Today, for example, I did a lot of audio mixing. Having no particular audio experience, I had to learn the skills involved from scratch. Needless to say, I touched only the surface–but even what I was able to learn in a workday was fascinating. The audio in the new version of Phalanx is better for having learned it, and future projects will no doubt benefit as well.

I don’t have anything especially insightful to say about audio mixing. I’m simply struck by how neat it is that I got to spend some time studying it at all. On the list of things I never thought I’d get to try . . . .

The Unattractive Process of Attract Modes

Today I did the attract mode for the latest version of Phalanx wrong in two entirely different ways. Fortunately, a conversation with a colleague taught me the right method in the end. Lest I forget in the future, here it is:

  1. Code your game so that inputs are stored, along with a time stamp. Preferably the inputs should be handled by a manager devoted entirely to them; it then sends the data to an intermediary, which in turn helps it get to everything that needs to know what the inputs were.
  2. In addition to the input manager, build a system that reads move records, sending “inputs” as the game timer reaches their associated time stamp.
  3. When there’s a great playtest game, put its record into the record player.
  4. Set up your game so that the intermediary reads from the input manager, your attract mode so that it gets “inputs” from the record player.

Voila! Exciting attract mode matches, all thanks to good code architecture.

Phalanx3d’s Attract Mode

With some additional feedback put in and a touch of bug fixing, Phalanx3D was ready for another round of playtesting at about noon today. That meant I had time to work on an attract mode–the sequence that plays while an arcade game is waiting for coins.

Traditionally attract modes have featured the game being played comically poorly. Fighting games show off combats in which the martial artists don’t seem able to touch each other; shmups neglect the unique mechanics that make high scores possible. At times one wonders how these displays ever manage to attract anyone. 😉

Originally I set out to replicate that cheerfully terrible play, if only as a matter of historical interest. Attract modes are always like that, after all. Shouldn’t I nod to illustrious arcade forebears?

I couldn’t reconcile myself to the obvious design weaknesses of that approach, though, and I’m now thinking that using the attract mode to teach the game properly is a better bet. That will mean pre-recording solid games that can be used to demonstrate key aspects of play. My expectation is that that will be done by the weekend.

We’re still on pace for a start-of-school release. Further news as events warrant . . . .