I’m going to start up my game of the year posts soon, but I also wanted to post my first screen shot of the new project I’m working on: Civility.
This is going to be a decent-sized project and, unlike my last four, more of a straight-up game rather than another attempt at mechanically expressing an emotion or state of mind or anything like that. Civility is, at the high-level, a customizable shmup set during the “civil war” (thematically and conceptually, not temporally) with the structure of a Monster Hunter game.
It is, to some extent, a game I’ve been wanting to make for a long time but, well, it ended up going in a somewhat different direction than I had always wanted to take that game. Oh well. The metaphor isn’t exactly what one might call subtle. It’s a strangely personal and yet impersonal game and I’m glad I finally got around to making it. And I owe a big thanks to colleague Josh Sutphin for composing some music specifically for the game based on a prototype and some information that I passed along.
And I guess when I said that I was done with the particle-styled games I was, really, just completely lying. I just like the style too much.
Aside from the more narrative/thematic goals I had for the project, I wanted to do something to evolve the style I’ve been working with for the last year while still keeping to the fundamentals of it: abstract visuals and a very dynamic scene. This was also my first project using the new version of Unity, so I wanted to see what kind of visual effects I could work in that I hadn’t messed with before. Strangely enough, the two biggest changes I made had nothing to do with the change in platform at all, just a change in how I composed the scene. The first step was putting a 2D plane in the scene and attaching point lights to every object, then modulating the range/intensity of that light whenever I wanted to draw attention to the object (generally when it was hitting something or when the object was destroyed). The next step was creating a 7.5%-sized render target — which was a duplicate of the finalscene minus some additional post effects — and overlaying that on the final composition for the pixelated look. Without any bloom, the frame buffer acted as a new-retro-styled bloom effect, which I really dug. I then went the extra unnecessary step and added Star Trek (2009)-style lens flares to everything, though, because… Well. That one has no deep meaning. I just thought it looked good. The final real stylistic step was to also apply a noise filter to the 7.5%-sized render target to get a more dynamic background.
One of the goals I had for the new style was to incorporate more pixel art into the game, but I really only did that with the individual heart pieces (the mines are untextured 2D quads too, I suppose). I’m going to be relying a lot more on low-fidelity pixel graphics for my next project.
All things considered, I’m happier with the way the style turned out than I am the actual game systems, but the design of the thing does accomplish all of the “storytelling” goals I had for it. Those goals just happened to turn out to be far more cynical than I was originally anticipating. Still, I’m curious to hear any reactions to the game. The next project, which I’m loosely describing as a “Monster Hunter shmup” at the moment, is going to be a somewhat more traditionally-played game.
One of the experiment that came out of my visual style exploration is the following image; I think this game needs to be made:
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):
Caper Corp. is nowhere near even approaching the mere concept of alpha, much less completion. That said, I like to write about the development of the games I’m working on from time to time. This is one of those times.
Most of the work over the last week on Caper Corp. has been to get stair connectivity working. So, as it works now, I place Stair objects in every floor plan that I make in the editor. The Job system (the Job being my script classification for a high-level caper) then determines what level template to use, and the level system generates a level from a series of floor plans that match that template. Templates being, at the moment: casinos, banks, and hotels (I’m thinking about making “Surrealist” an actual template whose jobs consist of illogical parameters too). Anyway, the level generates the entire building for a job from a series of floor plans. Each floor plan has all of its necessary objects pre-placed by the designer (me) so stairs aren’t created in super absurd areas of the floor. This will result in variations from floor-to-floor, since I don’t want to hold myself to rigid floor dimensions/standards for every floor plan, but I think that’s okay. The stairs are then generated from the lowest floor to the top. Half of the upper floor’s staircases are used for current floor (the lowest) to the upper floor levels, connections are generated, and the unused staircase on the lower level is disabled so the player never knows it’s there. The algorithm then goes up to the next floor, uses all remaining staircases to generate connections to half of the next floor’s staircases. This results in all stair objects being used, remainders being discarded, and a surprisingly simple and error-free procedural algorithm that I wrote in twenty very focused minutes of work one night.
And then an hour or two of bug-fixing the next morning because nothing ever is that simple.
Next on the list, since I’m still kind of making up the actual core game as I go along, was to start adding some of the more heist-y elements to the game to get that game logic in. I know I can do a top-down shooter pretty well since I’ve done it before in Asplode! and all of the subsequent prototypes I’ve made that I never took very far, so my goal right now is to make sure I can do the pseudo-stealth/sneaky stuff. I added a security camera and a light security terminal (and a player spawn point object, but that’s boring). I also realize, now, that I should have added a laser trip or motion sensor or something so I could setup linking triggers/objects with their security consequences. Anyway, I got those three objects in and realized I have like a nine-step process to add new object types to the game/editor, but once they’re in they’re theoretically flexible, so I’m tepidly okay with that. I was actually kind of surprised that they saved/loaded just fine when all was said and done (a revelation which, also, is somewhat concerning) and I was able to make some improvements to the editor along the way.
With the camera in, I need a way of displaying its field of view, so I’m also going to start tackling the lighting system for the game. Ideally, I won’t have to resort to tile-based lighting like most Rogue-likes (and, I think, Monaco), and can instead use the style present in the following screen shots. Problem with this style is that it’s per-pixel lighting and actual shadows are being cast/received, so the potential performance hit may be significant. I’m really hoping that the fact that none of my objects or shaders are complex allows me to use a decent number of lights without penalty. I’ve had to start adding actual height to some of the objects in the editor so that shadows will be properly cast, too, which made for a neat Unity editor shot of my test bank level:
The next development goal is to properly expound on the mechanics of some of the security objects. The first step of this is to start establishing some of the higher-level parameters of the job (the heist) and the integrity of a floor’s security (and that of the building as a whole). This will start getting into the basic logic for infiltrating a building at the beginning of the job which, from where I am right now, is probably the biggest unknown in the game’s development. I don’t really plan on having an elaborate tactics/planning stage like the early days of Tom Clancy’s Rainbow Six, but I do want to simulate that same sense of intentionality to the early portion of each job. Wen a player starts a new heist, I want the various characters involved in the job to all be on nothing more than reconnoissance duty. The gameplay goal being to scope the building out — at least the floors that are readily accessible for the ‘public’ (those whose entry won’t start requiring active infiltration) — and getting operatives in place before actively beginning the caper.
There has been a tremendous dearth of content for my site lately. This is a thing that troubles me greatly. There are reasons for this, of course, busy at work, ladyfriend, some topics I’d like to write about but don’t entirely feel comfortable writing about, and a general lack of inspiration from the games I’ve been playing. This will change going forward, however, as my current games I’m tackling consist of Kane & Lynch (completed), Frontlines: Fuels of War, Haze (completed), and my much-adored Just Cause 2. I’m looking forward to writing about them, but that time is not now.
I realized an hour or so ago that my reliance on Twitter often leaves me talking about things that are actually relevant to this site and, in doing so, never actually talking about things that are relevant to this site on this site. Microblogging killed the blog, or something. This revelation was particularly noteworthy because I started a new project a couple of weeks ago and unless we count my development gallery, there is no mention of this project on the site. This just strikes me as being egregiously wrong.
The new project is what I’ve been billing as a semi-Rogue-like, very barely XCOM-ish, evoking bits of Team Fortress 2 top-down tactical action heist game that I’m calling Caper Corp.. After making a series of smaller, more “indie” games with Unity, I got the point where I wanted to tackle a bigger project. And, unlike most of my independent projects up until now, I want this project to be somewhat less quiet and subtle and convey a more definite sense of character. On top of all of this, seeing Monaco at the Independent Game Festival when I was at GDC this year made me realize just how large a void there is in the list of genres that games commonly draw from. This void is vast, of course, but specifically I want more heist games. And while Monaco is surely a fantastic and incredibly well-made and well-designed game, the actual gameplay didn’t jive with me. So I’m making a heist game. In Unity using some of the 2D/3D stylistic stuff I picked up on working on a prototype called “Men of Science:”
The hallmark of the dungeon crawly, Rogue-like genre of games is their procedural nature. Every experience is different from every other one due to the highly randomized nature of the environments, monsters, items, and so on, so while the core game design remains the same play after play, the environment in which a player explores is ever-changing. In theory, I really dig the sense of unpredictability and excitement that arises out of procedural level generation. What I don’t dig is the amount of development time that would have to be sunk into a procedural level generator for a game which is completely dependent on its environmental dynamics. When a dungeon has weirdly-wrapping corridors with strange connections and randomized caverns, it’s okay: it’s a dungeon. When a six-floor bank or ten-story casino has a completely illogical and incomprehensible floor layout for each of its floors, it’s ridiculous.
What I decided to do for Caper Corp., then, is semi-procedural level generation. Each level has a template: casino, bank, tropical hacienda of an oil baron, etc. Each template has a series of floor types: main floor, basement floor, upper floor, and rooftop. Each of these floor types has a series of potential foor plans. These floor plans are made in an editor. Each floor plan has a definite architectural layout (defined by the designer: ie, me); however, each individual floor plan also has randomized activation of the designer-placed game object on the floor, along with “sets” of architectural features that are enabled/disabled at random. It’s, essentially, controlled randomness. These floor plans are then laid out per the template; a casino has a main floor (chosen from, say, six casino ‘main floor’ floor plans), with three ‘upper floor’ floor plans (from a bank of twelve), and two ‘basement’ floor plans (from a bank of fourteen). Theoretically, even if a player played this exact configuration of casino floor plans in the past, there would still be enough randomness at the floor plan layout level to provide for a unique gameplay experience.
Unfortunately, all of this required me to do work in an area of game development that I absolutely loathe: editor design/development. I finished the first pass of my “Blueprint” tool for Caper Corp. an hour or two ago, though, so all is good. All the editor can really do at this point is paint floor tiles, wall tiles, erase tiles, and save/load floor plans, but that’s good enough for me to start working on the game core and style/art tests, which will start… In about ten minutes. Here are some screen shots from Blueprint (and check out the full Caper Corp. development gallery for ongoing pictorial updates):
Because I have deep-seeded mental issues and sometimes am prone to crazy bouts of productivity, I made a new video game (click to play!):
Much like Balance, Doubt was done in under a week using Unity and an entirely particle-driven visual aesthetic. Since the last couple of games I’ve worked on (Magnetic Butterfly and Balance) were somewhat passive in their mechanics and heavily based on physics and movement, I wanted to do a game that allowed for somewhat more active play. I’ve always had a soft spot in my heart for shooters (both to make and play), but I knew that I didn’t want to make a straight-up shooter. My goal with these week-long projects is to experiment and, along those lines, I wanted to try something slightly different. So was born the ring-based movement mechanism and the “sticky” bullets.
Something I felt worked very well with Balance, from the perspective of someone who knew everything about the game and the influences anyway, was the thematic and inspirational influences in the core gameplay and game flow. For me, Balance worked out as a means of telling a short story through gameplay. What I’m still not entirely sure about is what other people took from the game (if anything), so going on to the next project I wanted to try something a bit more commonly understood. Originally, I wanted to do something more holiday-themed (which is where this image came from), but nothing came out of my gameplay sketches. Then, for whatever reason, the concept of ‘doubt’ entered my head and everything else fell in place shortly thereafter.
My favorite aspect of Balance was the evolution of the game’s aesthetic and the effectiveness of the final result both as an atmospheric and purely visual quality of the game. The particle system-heavy visual style was something that was incredibly enjoyable for me to work on and mess around with and, on top of that, it was an incredibly quick way to get good results in the game (and tweaking them was even easier). Beyond all those points, though, it seems that the biggest benefit of this visual style is the “ink blot” approach to graphic style and design; it allows the game to have dynamic, readily identifiable components that create a very interpretive overall composition. Potentially, what I read from Balance and Doubt is completely different from what someone else may read from it despite so many common atmospheric elements. I’m planning on doing at least two or three more projects in the future which attempt to take the visual style further (and in somewhat different directions).
One thing which has always worked out incredibly well for me is constantly getting friends and colleagues to play-test early builds of the games I work on. Magnetic Butterfly would have been a far, far, far worse game if I didn’t constantly get people’s thoughts on player movement and interaction. Balance’s play-tests also led to a vastly improved movement design. Feedback to Doubt, though, led to two huge changes to the initial design. One of which is that in previous builds, player’s bullets would stick indefinitely to the pegs surrounding the cloud and then a player would have to “detonate” them with a separate interaction. The theory of this was that it would allow players to setup large combo chains which could yield big points and more damage to the doubt cloud. I could never figure out a good risk/reward for this system, though, and the additional button press felt awkward. When a colleague pointed this out, I had a partial epiphany that led to the player only shooting shots that, once stuck to a peg, were on a definite timer before their eventual explosion. Any further pegs that were stuck were dependent on the timer of that first bullet to get a real combo going. While still not entirely ideal (as there’s no reason not to be constantly shooting now), this was a definite step in the right direction for the game.
And, similar to Balance, all builds of Doubt up until the second to last one shared a common misstep (that I still failed to properly remedy): the full width of mechanics which make up the game are still largely non-apparent. Play-testers of Doubt were often confused as to what exactly was “good” to do and what was “bad.” Somewhat hackishly, my response to this was to add floating point notifiers that appeared on-screen whenever an action was executed which resulted in a change of score. Much to my surprise, this actually seems to have worked out pretty well.
Overall, Doubt was a fun project to work on, but I think Balance turned out much better. When I started Doubt, I didn’t have the same focus and clear intent as far as my gameplay and thematic goals when I started and, despite finding them eventually, I think that lack of clarity hurt. I also don’t feel that Doubt is all that deep or fun; there’s no real “strategy” to form. It’s very possible to just hold down left/right and the fire button and end up with a decent score. The one-button game with completely random potentially movement areas somehow required more attention and care to play than the one with full player agency. Still, it was a lot of fun to work on and the one-week limitation worked out well.
Also, thanks for all the feedback and support regarding Balance; it’s incredibly appreciated and all your awesome feedback has given me a lot of insight into what to do (and what to avoid) in the future. And let’s give a big high-five to Josh Sutphin for yet another set of rad music!