Tag Archives: Game Development

Starhawk

Posted on by — No Comments ↓

As of tomorrow, May 8th, 2012, you’ll all be able to buy your own copies of Starhawk! I think you should do this.

Starhawk!

I’ve been working Starhawk since I left Stardock almost three years ago and moved out to Utah (and then to Austin). It’s been weird to freely talk about the game at all, but it’s even weirder to see the game in stores, ads, and the fact that people are a mere fourteen hours away from buying it and playing it themselves.

My focus on the game has primarily been mission design/implementation, cut scene design, inner loop tuning/balancing, and writing a whole lot of LUA script for our missions, tools, and other systems. All things considered, I ended up working pretty heavily on five of the missions in the campaign. I also ended up doing a final (and in some case, last) pass of refinement/camera movements/scripted sequences throughout every mission in the campaign in the final weeks of development. It’s been a great project and we’re all super proud of it and hope y’all buy at least a few thousand copies per-person in your family.

More importantly, though, is that I think our team here at LightBox Interactive has accomplished truly impressive and my coworkers are all totally ace.

Balance Source Release

Posted on by — 2 Comments ↓

Around a year ago, I released the first of what became four straight particle-only games in Unity. The game, Balance, was both my first attempt at a more rapid design and development cycle as well as an attempt to treat a game as a very focused expressive piece (kind of like a short story). Balance is also still my only attempt to make a one-button game ever and, aside from Broken, it is my favorite of the games I’ve worked on independently.

Anyway, point is: someone recently asked me if I would release the source for any of these recent games, so I am! All of the content that I think is necessary to build the game (under Unity 3.0) can be found here. I also uploaded a new build of Balance with a couple bug-fixes and an improvement to the postprocessing effects.

This release does come with the obvious caveat of: things are ugly. I treat the programming of my independent projects like one would a rough sketch; too much thought into architecture and system design generally just impedes progress when it’s late at night and you’ve been drinking, so I just generally roll with it. I don’t think this is as big an issue with Balance as, say, Broken or my current project, since Balance is a simple game, but who knows! Do let me know if there are any issues or if I neglected to include some critical file or what not. And if this actually proves useful to anyone, I’ll do similarly for Doubt and In the Wind in the future.

Broken

Posted on by — 5 Comments ↓


Broken is my newest game; you can click the above image to check it out. Alternatively: here. There’s also a Universal Mac OS X build and a Windows build.

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:

Next Up

Posted on by — No Comments ↓

I haven’t neglected this site, I’ve just chosen to go from a weekly entry to writing lengthy posts on more interesting, more well-considered topics. I’ve also been working on a few new projects. The next of which is this (and, no, there are no compression artifacts in the image):

And aside from Halo Reach, ClaDun: This is an RPG! is probably going to end up being one of my favorite games of the year.

The Particle Trilogy

Posted on by — 1 Comment ↓

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.’s Got Stories (and Stairs to Connect Them)

Posted on by — 9 Comments ↓

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.

Caper Corp. – Blueprint

Posted on by — 1 Comment ↓

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):