Now on an arcade cabinet at the Game Center!
Tag: Phalanx
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.
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:
- A piece can move if the space it is moving into:
- is currently empty, or
- will be empty this turn (e.g., because the piece in it is leaving).
- 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.
- 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.
- 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:
- The game loops through all the pieces that want to move.
- All those that are moving into an empty space do so.
- All those that definitely will not move (e.g., pieces blocked by water) are marked as not moving.
- 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.
- 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:
- 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.
- In addition to the input manager, build a system that reads move records, sending “inputs” as the game timer reaches their associated time stamp.
- When there’s a great playtest game, put its record into the record player.
- 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 . . . .
Phalanx–Now in 3D
At the beginning of the summer I decided to re-reimplement Phalanx, both to resolve some code architecture problems and to practice some 3D modeling. Since then I’ve been working on it part-time, investing a few hours into the game each week when not on other projects.
I’m broadly pleased with how things are coming along, but have found the camera to be a real struggle. At high angles the game loses a lot of visceral appeal; too low and it’s impossible to take in the playing field. The camera angle you see here is a functional, but unexciting, compromise.
Currently Phalanx‘s new incarnation is to be released at the end of August, with an appearance on the arcade cabinets at the NYU Game Center. In the service of that goal, it’s time to go back to the grindstone . . . .
In the Lab: Porting Phalanx
I’m very proud of Phalanx, but the specific changes and improvements that people have suggested for the next iteration aren’t easy to do in HTML5. Furthermore, Phalanx’s assets are starting to be a bit much for web publishing; there’s already noticeable lag as the game loads, and every further bit of juice is going to make that worse. Those two factors are driving me to re-implement the game in Unity.
As I do so, I’m taking the opportunity to clean up Phalanx’s code. During the rapid prototyping process that brought the game to life I was focused on “does this work,” and not especially concerned about optimization. While it’s not a taxing game to run even in that non-optimized state, there are some areas–particularly in how pieces determine whether the space they want to move into is open–where there’s room for improvement. This is clearly the right time to take care of them.
Needless to say, the changes in architecture have produced a new round of logic errors. 😉 Such is the way of things, I’m learning.
If you need me, I’ll be in the trenches . . . .
Phalanx: Dear Me
Dear Me,
You got a lot of great feedback today. That means it was a good day for the game!
Now, 48 hours from now something is going to be broken again–probably a lot of things. You’re going to be hip-deep in trying to get your code to work. There’s no reason to deny it; that’s always how this sort of thing plays out.
When immersed in the code like that it can be difficult to remember what the real goals are, as distinct from what the very next step of get-this-to-work requires. Ergo, I’m noting the feedback here, where you’re sure to look. 😉
- Bodies are distracting; look like they should still be something the player can interact with. Either get rid of them entirely or make them more obviously not like active pieces.
- Animation for dying that then goes away?
- Small sparks indicating where formations have hit each other head-on.
- Board colors are too intense; looks like a camo pattern, or just like digital blur. Do something different; perhaps muted colors with a layer of grass at the bottom?
- Only highlight the last formation created; highlighting all of them becomes less useful over time.
Good luck!
– You
The Law of Game Design 