Now on an arcade cabinet at the Game Center!
Now on an arcade cabinet at the Game Center!
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. 🙂
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.
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:
To implement those rules, the game proceeds as follows:
This algorithm consistently produces the correct results, but the performance hit is rough. Is there a better way?
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 . . . .
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:
Voila! Exciting attract mode matches, all thanks to good code architecture.
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 . . . .
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 . . . .
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 . . . .
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. 😉