As a little break from Caper Corp., I finished a making a new video game this weekend. This one is called In the Wind. Much like Balance and Doubt, In the Wind’s entire visual style is driven by particle effects. Well 2D text too, but that’s only because making particles to represent text looked ghetto at the size I needed the text to be. In the Wind brings an end to the particle trilogy style of games I started back in December. This game would have been completed back in January or so, but unlike both Balance and Doubt, In the Wind was started more because I liked this color composition:
Unfortunately, that was really all I liked about the game that I was thinking about making, so it never really got beyond some movement physics, a wind effect/simulation, and the tree. My goal with the game was to always convey a “natural economy,” in that everything in the game was able to act because of the energy the center tree provided, and the player’s goal was to just feed more and more energy into the tree. It was an okay idea, but I never really had the thematic commitment to it that I did for the other two games. My goal with the particle projects was: no more than seven average days of work (so an hour or two after work and then maybe a weekend afternoon) and a set of systems which mechanically conveyed a single, coherent theme. For Balance and Doubt, I had the theme and the systems down for what I wanted to convey and, between the two, Balance is the only one that really succeeded as a fun little project (though I still have some love for Doubt, despite that). For In the Wind, I never really had that and, as a result, despite the second wind I got that drove it to completion, the game kind of waffles. The other problem was that after a night of work on In the Wind, I was already prepared to go back to work on Caper Corp., so it was this weird divided interest.
Still, I was able to get In the Wind done in a fashion very similar to the other games in the series: a Saturday after returning from a run I realized I had to scramble together all of the final elements (usually some systemic touches, audio, and a starting/ending screen), upload it to my site, post to Twitter, and get some quick feedback, incorporate those changes into a new build, and voila. New game.
Working on these three games with the self-imposed constraints under which they were worked on was a fun little endeavor. It was nice to do something a little bit different and to establish a visual style that was (hopefully) uniquely mine and explore some one-off systems. And now it’s back to Caper Corp., which should have another entry forthcoming at some point in the next week or two.
Final games in the particle trilogy (because they’re not real games if they’re not part of a trilogy):
So my new game is done. Click the image to play:
This was kind of a strange project for me for a few reasons, not least of which being that I actually got it done in a timely manner. When I finished Magnetic Butterfly, I noted that the game took me about six-seven months to finish despite only taking about a month of active development, so it was nice to actually finish Balance in a timely fashion. I also believe that the short development time helped me focus in on translating the initial emotion/inspiration for the game into the final game without losing a lot in between. One of the down sides to the rapid development is that I’m fairly certain the scripts which make up the project are readable only by me, which is okay, and probably ludicrously inefficient, which isn’t as okay. That said, much like when I was working on Asplode!, I seem to be much more productive and creative with what I do when I treat the writing of game logic as the equivalent of a sketch.
The two primary constraints I had for this project were that the game had to use only a single button for input and that I had to adhere to the thematic inspiration for the project with no mechanics which worked against it. When I decided to do a one button-game, that included the constraint that I was also not going to allow movement support of any kind. It would have been easy to make a game, or even this game, work with, technically, one-button input and mouse scrolling or something, but that seemed like it would be cheating. To work the game’s theme into the mechanics and the one-button constraint then, I decided to severely limit a player’s agency in the game. The player cannot move of his own volition, he can only rely on any number of other entities in the game world to guide motion. This logic ended in the “attraction” mechanic that the game is based on and while the spawning of the pegs in the game world is random, players are not completely without agency to, roughly, guide their movement through the game world.
Ironing out the attraction logic was, without a doubt, the most difficult part of the project. The peg spawning is random, and that’s intentional and desirable (from my perspective), but the player should always have a rough idea of what will happen when he starts attracting to pegs. This was easy enough to smooth over when I had it so that the player could only attract to one peg at a time, but not only did that not feel right or interesting but it didn’t support the theme. Adding logic so that the player could, potentially, be attracting to every peg in the scene almost instantly felt like the right move both as a design and aesthetic consideration. Some early play-tests from friends, however, found the movement at this point in the project completely frustrating. One testimonial went: “this game is monumentally frustrating. I think I hate you for it. you should seriously be punched in the junk.”
That reaction made me revisit the movement mechanics of the game one more time (about four or five hours before the game was “done”). Initially, all of the pegs the player was attached to had “strengths” and these were modulated by their distance from the player. The issue was that the strengths varied so wildly and the distance modulation was so progressive that it was possible for the furthest peg to have the most pull. When I revisited this logic, I reduced the range of strengths (which now only vary by +/-0.1 units as opposed to +/-1.0) and also made the closest peg have a clear domination over any of the secondary ones (its strength is increased by 75% and the secondary have their strengths reduced by 50%). This change, alone, made the movement mechanics far smoother.
The biggest failure of Balance is the concept of the player’s “energy,” and it’s either an issue of an unnecessary mechanic (which is arguable) or simply being a poorly-communicated one (which is a fact). A player has an energy value in the range of [0,1], starting at 1.0 when the game starts, and that value is constantly decaying. The player is gaining energy whenever he is attracting to pegs or takes hearts. When a player is at full energy and is still gaining energy, that’s when the score goes up. If the player is at low energy (and the white ball is at its darkest) and continues to lose energy, the score goes down. I thought about ways to better communicate this mechanic, but it would have necessitated additional visual complexity as either another in-world effect (which would have muddied up the aesthetic) or a HUD element (which I absolutely did not want). I decided to leave it in the game for the release, as I think it has some promise, it’s just broken in its current state.
More than anything else, I think Balance helped me solidify what I think will be my game “style” for a couple more projects. This project my first real attempt at “expressing myself” through a game and either for that reason or the hyper-abbreviated development cycle, it was a lot a fun.
The video game designer has an idea. It sprung out of a song on his iPhone as he was walking to a greasy burger joint. And for that one moment, the entirety of the game was perfect in his mind’s eye. Just that one moment.
Precious minutes later, as he picks through a bag filled with small, greasy french fries, he tries to piece together the pieces left from that initial moment. He takes a single fry, one far too small to even be worthy of dipping in ketchup and moves it through a series of nearby fries. As a visual reference, it’s lacking. The runt fry is eaten.
As the designer walks back home, he attempts to flesh out the image in his head. It’s a game about about attraction, balance, and love. He knows he doesn’t have the time, interest, nor artistry necessary to make these ideas have a one-to-one correspondence with the sources of the idea. Not that it matters, he thinks, that relationship should remain as loose as possible. His style, if it can be called that, allows for and encourages as abstract a representation as necessary. He refines an earlier thought: not attraction, he thinks, but physical attraction. He realizes that clarifies nothing. If he still had the fry, he would move along a straight path until its proximity to another fry caused it to curve in that direction.
When he gets home, he finds his laptop to try and make his fifteen minute old idea into a game. After the software update. While the update downloads and installs, he sets up a music playlist solely containing songs from the band that was his inspiration. He sets it on repeat. If he knew which specific song in the list of names was the one that triggered this whole endeavor, he would set that on a one-song repeat, but that was effort.
Software update finished. Erm. Now to get the patch to the software update. A response to an important message in one of the designer’s inboxes might as well be written now.
Forty minutes later and utilizing Version 2.6.1f3 of his development tool, the designer places a sphere in the middle of empty gray space. He’s unsure whether or not the sphere is the actual protagonist, if it can be called as such, or simply a placeholder. No matter, though, the collision shape will, well, should be valid throughout. He sets up an orthographic camera because, fundamentally, he assumes 3D would take away any of the character to the ideally minimalist aesthetic. The style, if it can be called that, supports this choice. Realizing his
deskcouch lacks proper warmth, a blanket is added to the work area. And headphones. Tinny laptop speakers do no good for anyone focusing on something.
The designer, now comfortable and set to work, sets to work. He takes a drink of the nearby pop that he doesn’t remember ever getting. It’s warm. And flat. And now empty. He sets aside his workstation, if it can be called so, to replace the pop.
Sitting back down, re-blanketing, re-positioning the headphones, and picking the laptop up off the floor, the designer looks at the sphere in the middle of gray 3D space. He feels this is a good spot to save the project and scene and does so under an appropriately vague name in a folder amongst five other similarly-named unfinished projects. Looking back at the scene, he figures he needs to establish some world boundaries. He tosses in four planes in the scene where he thinks, approximately, the view boundaries are. He tries to setup mesh renderers so he can validate this in-world, but, well, orthographic view. And planes. “Balls,” he says aloud. His cat, sleeping nearby, opens his eyes and looks in his owner’s direction. The cat remains unmoving, yawns, and closes his eyes.
“Well,” he says aloud still, “this’ll do for now, I’ll just–” the nearby phone rings.
Ten minutes later; blanket, headphones, and laptop, re-oriented. Pop empty again. “Fuck it,” the designer says, grabbing a nearby Xbox controller, “Instant Netflix it is.”
Two hours later. He picks up the laptop from the floor, opens it up, and sees the sphere, still sitting in the gray void with plane collision meshes surrounding it on four sides. Knock on the door.
The designer walks opens the door to the apartment, aspects of his workplace strewn about the living room. The sun outside has set. The designer looks at the laptop sitting open on the couch, the screen darkened after an hour of inactivity. The cat walked to the door to greet the designer. The cat rolls around the ground around one of the designer’s cast-aside running shoes.
“God dammit,” he says.
A run, a shower, dinner, errands, and two or three hours later, the designer sits back down on the couch. He puts fifteen minutes of research into various functions for the development tool. The phone nearby buzzes, any associated sound muffled by the over-sized headphones the designer has on. The designer picks up the cold phone and sees a text from a friend asking if the designer saw the ‘amazing’ episode of a show from earlier in the week.
Looking the show up online to watch, the designer finds it. It’s a double-length episode.
An hour and a half later, the designer closes the internet browser he used to watch the show. The development tool takes focus. The designer looks at the white sphere sitting amidst the gray 3D void, nothing else in the scene other than planar collision meshes.
He opens up a text editor and starts writing.
Over the last few years, Relic has been crafting and evolving their very unique take on the real-time strategy genre with every new title they have released. Their shift in focus from a game like Homeworld to their, now, action/RTS genre blend was most apparent in Warhammer 40,000: Dawn of War (2004). Dawn of War introduced the concept of cover as an actual game mechanic that players had to think about and plan a strategy around. The game also provided players with a lower unit count than most other strategy games released at the time while also treating infantry units as somewhat customizable squads rather than individual units. Dawn of War also was the first of Relic’s games that really attempted to differentiate itself from the conventions of the real-time strategy genre at the time by reducing the gameplay emphasis on resource management.
Unlike games like Warcraft, Starcraft, and Age of Empires, Dawn of War treated one of its two resources as a capturable commodity. The map designers placed several important requisition points at key locations around a game map and these capturable points were the only means of harvesting requisition. Once a resource point is captured the flow of a given resource was dependent on nothing else but time (and maybe an upgraded listening post on the capture point). There were no workers to manage and not supply flow to contend with, simply a group of “hot points” that littered a game map. There were, however, constructable power nodes that players had to build in order to acquire power — a design mechanic that felt out of place in the scheme of the game. Relic’s next game, Company of Heroes, took this design methodology one step further and made the source of all resources a capturable point on the game map that had to be claimed and then, in some cases, enhanced through the construction of a building atop the point.
Dawn of War 2 makes resource “gathering” such an integral portion of the game that, moreso than Company of Heroes, multiplayer matches are a constant struggle for each team to keep both its resources points and the capture points which govern the fate of each teams’ “ticket” — whoever has the least number of these capture points will see a slow reduction in their team’s ticket count and the first team to reach zero loses. It’s a geographical tug-of-war where players shift from one thoughtfully-placed point of interest to another. This is, no doubt, a game mode that any player of multiplayer first-person shooter games over recent years is familiar with; in particular, the primary game mode of the entire Battlefield series. What Relic has essentially done for the multiplayer portions of Dawn of War 2 — even more so than they did with Company of Heroes — is to bring the intensity of a good match of Battlefield to the real-time strategy genre; a game I experienced last night actually had my two allies and I come back to win a match after being beaten from 400-some points down to four points.
Resource management aside, Company of Heroes’ general gameplay progression still owed a lot to the typical real-time strategy formula. The base-building was minimal, but the construction of defense structures and some key base structures was still a strong aspect of the game. The multiplayer gameplay in Dawn of War 2 (the multiplayer is completely different from the single-player) gives the player a starting base which consists of a headquarters and a single defense turret. Throughout the a match a player can take his headquarters from level one to level two, then level two to level three. That’s the extent of the base-building.
I was skeptical about the radical shift in game design from Dawn of War to Dawn of War 2 but, after a handful of games, it was absolutely the right choice for the franchise.
Everything about Dawn of War 2 revolves around a player’s ability to choose a handful (or so) of unit types/squads and closely manage them to fit a player’s specific strategy and the best strategy given the layout of the map terrain at any given time. In the beginning of a match, properly-chosen infantry will dominate all battles. The map’s structures and defenses will be in-place for various squads to find cover behind, there are points all over the map which are unoccupied and begging to be captured, and there are no enormous vehicles or mega-units that infantry will eventually cower in fear at the sight of. The beginning of a game of Dawn of War 2 is a very unique, short-lived section of the game where infantry rule the terrain. Which players can properly set-up their emplaced units (heavy bolters, plasma squads, etc.) to watch over the light ranged units (scouts, light infantry) as both ranged squads work to suppress enemies so melee units can move in for the kill will find great success here.
Once each player’s hero unit starts gaining some levels and purchasing upgrades and the vehicles and mega-units start popping up as a part of each player’s employed units the composition of a Dawn of War 2 match changes. The vehicles and mega-units can topple over even the best of the cover that infantry were previously using to great effect. Now the game becomes a war of attrition as each team works to build the perfect combination of infantry, vehicles, and mega-units as each side works to either defend their currently-held resources and capture points or go on the offensive to take new points from their enemies.
It’s the effectiveness of the back-and-forth of point capturing and defending that works so well in Dawn of War 2. In Company of Heroes this gameplay was great for its time but the maps required players to treat the map geography territorially; this design focus forces players into a “hunker down and defend” playing ideology which didn’t seem terribly convenient for the kind of gameplay the point-based Company of Heroes modes encouraged. Dawn of War 2 gives players maps which place important the primary three capture points in very difficult-to-defend areas. This simple change in design of multiplayer maps ends up creating an entirely new game flow. Players simply cannot go entirely on the defensive in Dawn of War 2, the maps either don’t allow it or the structures which segregate various components of the map can end up being broken by a number of mid-to-late game units.
One of my favorite features of Dawn of War 2 crops up often during the mid-game portions of a multiplayer match: the ability for players to take certain infantry squads and set them up to be makeshift defensive emplacements. In a recent game I expended a great deal of time and resoruces to take back a crucial capture point that my team needed to recapture in order to come back from almost certain defeat. Once I managed to get this point back I built a squad of heavy infantry who wielded a gigantic plasma weapon that, essentially, ruined squads of infantry and did significant damage to vehicles and hero units. I sent this unit to guard the capture point I just took back from the opposing team while the majority of my army went off to help my teammates; I set the plasma squad up behind the only remaining segment of full cover in the area and for the next five minutes of the match this squad annihilated any unit that approached the area. Once the opposing team was wise to my plasma gunner they sent in a large army to take back the area, at which point my army returned and side-swiped them.
The dichotomy that exists between melee and ranged combat in Dawn of War 2 feels like the most problematic area of the game. At times it feels like the effectiveness of melee units is “random” — it’s almost assuredly governed by a very complex set of armor/weapon mechanics but these don’t seem to be made obvious or easy-to-understand for players. Sometimes a melee unit or commander can walk right up to a ranged enemies and thrash them in less than a second. Sometimes a melee unit will get suppresses by melee fire and end up being slaughtered by enemies as the melee unit attempts to make its way to its ranged assailants or retreat from battle entirely. I imagine that these mechanics will make themselves more known to me as I play through more and more multiplayer matches but, as of now, it seems poorly explained.
The interactions between some of the vehicles and mega-units seems to be even more perplexing. Some infantry units fare very well against the enormous walker units and some squads of infantry get ripped up by the same walker units in quickly and violently. I had similar problems with the original Dawn of War, though, so these should be things that players can just pick up through time and experimentation with the different races.
Dawn of War 2 isn’t a typical real-time strategy game; in fact, I am even hesitant to call it a real-time strategy game in the classical sense. There’s no base-building and no resource gathering in the way that Warcraft and Age of Empires have conditioned RTS gamers to expect. Dawn of War 2 is, by far, the best incarnation of the Action/RTS hybrid genre that I’ve played to-date and all I have been playing are three maps from the freely-available beta. My cautious anticipation for the full game has become a pervasive level of excitement.