It's been a long time since I participated in any time-constrained game development competitions, and with some free time (not really) available this weekend, I decided to attend the Triangle Indie Game Jam in Raleigh. It was a three-night event, so I'll describe the nights in order and then post screenshots of our final product. I'm going to focus more on the process and less on the game, which I will talk about in another post.
Friday:
Friday was 'planning night.' About 7 people showed up and pitched ideas for a game with a common theme: Placing Blocks. I pitched two ideas:
(1) A puzzle game where balls would constantly fall and you have to place blocks to get them to bounce to a goal.
(2) A tower defense/reverse Jenga style game where attackers are constantly weakening your tower, and you have to place pieces to keep it from tumbling.
Between the seven of us, about 18 ideas were pitched. I'm not going to enumerate them all, but in the end, the four that were picked are thus:
(1) A Rogue-Like where, instead of attacking creatures, you pick up blocks in the world and then place them elsewhere to try to avoid/manipulate enemies.
(2) A game where blocks of different colors constantly fall into gates, and you have to open/close gates strategically so that when the blocks pass through, they form an image.
(3) A reverse Jenga style game where you must build a structurally sound tower.
(4) A Lemmings-like where instead of assigning jobs to the Lemmings, you manipulate the environment to get them to appropriate positions.
I decided to go the Rogue-Like route, having a random dungeon generator already written and some interest in the genre. I was joined by Mike Lee and Mike Daly.
Saturday:
On Saturday development started in earnest and lasted from 9:30 AM until about 11 PM. We decided to break the project up into 4 distinct phases of development.
In Phase 1, we targeted standing up a lot of core code, get movement and (super basic) enemy AI in, allow creation and destruction of tiles, and put all the major state transitions (win, lose, main menu, etc) in place.
In Phase 2, we targeted picking up and dropping blocks properly, where blocks would be stored in an inventory. We wanted all the different tile types implemented. We also wanted random dungeon generation and a couple more enemy types. SFX were planned, but we cut those from the phase.
In Phase 3, we planned for race/class selection, limited vision, spells, and music.
In Phase 4, we wanted to implement all the enemy types and make things shine a little more, with multiple level themes and seamless graphics.
After planning the phases, we started some extreme programming for a couple hours, where we all huddled around Mike's computer and outlined the core code. There wasn't a lot - enough to get a solid Rogue-like simulation running, but it was a fair start and got us to the point where we could break up tasks.
Upon breaking up tasks, I initially spearheaded most of the rendering and level creation. As we pressed on and people finished tasks, we just started pulling things off a list that we were interested in doing. It was a fairly distributed bunch, with me on a lot of the rendering/map generation/level progression, Mike L on enemy AI/importing graphics/tile types, and Mike D on actions/menus/HUD. Which isn't to say that anyone had clear roles, since we all regularly grabbed arbitrary items out of the task list.
We blasted through Phase 1; Phase 2 had a lot of work in it, but even it went quickly. By the day's end, we were ramping up on Phase 3 and planning out our next (shorter) day.
Sunday:
Sunday development went from approximately 9:15-5:15.
Phases 3 and 4 blended into each other at this point - we compiled a list of all the things we wanted to get, a wish-list of things we knew probably wouldn't get in, and ideas for how to improve the gameplay. There was a lot of back and forth on how to make the game fun and how to make the concept work, and by the end we had a list of about 20 tasks to knock out.
So we just got to it. Though we prioritized the items, we jumped up and down the list regularly based on what each individual thought was important or wanted to work on.
And we got nearly all the list done. We did have to cut spells, SFX, and a bit of polish, but we spent the saved time adjusting stats and gameplay parameters instead; a rewrite of the control scheme, for instance, though not strictly necessary ended up making the game much more playable.
At 5:15, development stopped and people showed off their projects.
Recap
In the end, our little 3-man team made a fully-featured, well constructed game in just under 24 hours of work. Our code base is terrifying, but that doesn't matter.
Here are some (blurry) screenshots of our finished product!
0 Comments - Leave a Comment
Responding to this post. For the uninitiated, Zach and I frequently have open discussions by way of this blog.
Between iPhone, Android, BlackBerry, and Palm, I'm starting to believe the phone market is pretty saturated. Given Microsoft's previous cell-phone performance, I'm not convinced they're in any position to dent that market. I've toyed with porting Word Duelist over to WP7, but I'm hesitant to start up anything unless they want to give me free hardware. I'm pretty certain they don't.
To respond to the 'indie game mix' question, both XBLIG and WP7 use XNA - though obviously WP7 doesn't have access to as much, and there are mobile considerations that need to be considered (ie tombstoning). The submission method seems like it's changing; believe me when I say I would gladly wave goodbye to the ego-driven peer review scheme, but the new system might be a tad pricey.
But, y'know, if any of my Microsoft contacts (*cough* Matt) want to pull some strings and get me free hardware, I'd gladly take the plunge.
Any market that lacks peer review already has a special place in my heart.
2 Comments - Leave a Comment
It is fairly common knowledge that I currently own an iPhone 3GS. I bought it when I did (the release day) because at the time I thought it was the best smart phone available. I still stand by that thought today (that 14 months ago the iPhone had a very strong lead in the smart phone world). The game has changed since though, however. Android OS phones seems to be cropping up everywhere and a lot of them are very good (Evo4G, Droid/Droid Incredible/Droid X(possible not, I've heard mixed things)).
It does seem like the good Android OS phones aren't on AT&T, however, and I am pretty sure I am stuck with AT&T until I can convince Morgan to get a different phone other than her iPhone(which she had no desire to buy until I bought mine, now she trumps me in usage by orders of magnitude). So sticking with AT&T, and knowing that I have another 5 or 6 months (assuming AT&T does what Verizon does, which is let you cash in your new-every-two plan 4 months early) until I can benefit from reupping contracts instead of buying a phone outright, it seems like I might be switching from iOS.
Of course, we have the Android OS running around looking fairly awesome, but currently the AT&T selection is lacking. I believe Dell is coming out with some smart phones that seem like they might convince me otherwise, however. Recently though, I've been reading up about and looking at a lot of Windows Mobile 7 stuff. I have to say, I am very taken by these reviews. The GUI looks fantastic, and it seems much more robust than the iOS one. A big gripe I have with iOS is that the app icons are static. I would LOVE something more than these silly badges to alert of me things. Something as simple as making the weather app icon display the actual temperature, would be much appreciated. At any rate, I am not sure the Windows Mobile 7 GUI can support this, but it looks like it should, given the "tile" system they have in place. I am not to wild about the complete integration of FaceBook/Twitter, but that seems to be how things are heading right now. I actually prefer the seperate apps for this that I have on the iPhone. I suppose this default functionality could be replaced with applications, but that isn't something I am used to, being an iPhone user and all :-p.
At any rate, Windows Mobile 7 has really piqued my interest lately, and I am desperately hoping for more information/demos of it soon. I think it comes out this fall, so I'll probably jump down to the AT&T store when it does to check it out myself. Same goes for Dell Storm(I think). That phone looks pretty sexy as well.
Also, Brian, the XBox Live integration with Windows Mobile 7 looks fantastic, do you have any knowledge about how it mixes with the indie games section of XBox Live? This seems like an avenue that for your indie games that would probably be easier than porting to Android.
Zach
1 Comment - Leave a Comment
Brian - August 9th, 2010 - Scammed
I have a story to tell. How exciting.
About a week ago I posted a call for an artist for Abe and the Velociraptor. Usual venues - GameDev and the XNA Creator's Club forums. I get a few responses.
The first response was a little strange. When I asked for example art, he sent me the Mona Lisa and a hand holding a mirrored sphere. I initially scoffed and was ready to forget the e-mail (I pointed the ridiculousness out to coworkers that day) when there was a follow up e-mail: "(to clarify) these were hand-drawn reconstructions of the original paintings for an art contest in reconstruction."
OK, I guess that's plausible. That sounds like something an artist might do. So I continue communication.
After some discussions, his credentials sounded OK. He linked me to a very compelling portfolio piece - looked pretty modern and well-done. We had some discussions on art direction; nothing in-depth, but there was two-way communication.
For about a week we went back and forth; a few days in, he hinted that he had a significant amount of concept work done and that he was going to put it online. There were a few distractions (girlfriend involvement, couldn't access the SVN, wasn't familiar with SVN clients), but I mostly wrote those off as this project not being his highest priority.
And then today the big reveal:
He wasn't really an artist.
Yea, you read that right. He was just some bored guy stringing me along. He Wiki'd enough articles to sound vaguely convincing. I can only assume the portfolio piece he sent me was someone else's. And the reconstructions were, in fact, just pictures of original works.
After telling me all this he just... kept talking. Even told me about the game idea he constructed while he was leading me on. Talked about programming and how it might help with his math/physics work. I didn't much enjoy talking to him when I didn't know he was playing a prank - I'd actually commented to Laura earlier today about how I didn't particularly care for him - so after a few minutes I cut the conversation off and went back to, well, playing the ukelele. We'll talk more about that some other time.
So yea. I got played. He wins, I guess? Moral of the story: be more thorough when recruiting artists.
Second moral: Don't trust anyone named David Bandel. Apparently he's developed something of a cult following.
0 Comments - Leave a Comment
It's time for everyone's favorite foray into small numbers:
Trials - 1556
Sales - 25
Total Profit - I don't wanna think about it
Man: Are you Abe "The Rail Splitter" Lincoln?
Abe: Used to be. These days they call me Mr. President.
1 Comment - Leave a Comment
Ever hear someone recite the aphorism, "Life only has value because it ends," or many of its variants? The basic premise being that mortality is the driving force behind why humans do things with their lives.
It's nonsense.
It's clearly lacking foundation. I don't know anyone who's ever known an immortal, I've certainly never met one myself. There has not been a frame of reference for how such a being would exist and conduct itself, so speaking on the topic is speaking from a place of sheer ignorance. We're left with the single reference point, that of the mortal, and we're hopelessly bad at evaluating even that.
Death is not a motivator for accomplishment - at least not for a good long while. It's certainly a motivator for some things like not walking in front of pesky trains, but a "mortality deadline" (har har) is not what gives life value and it's not what compels people to lead fulfilling existences.
How can I say this with such authority? I can't, really; I'm just as lacking in the alternate perspective as anyone else. I haven't spent years of my life conducting relevant research (does such research exist?) or even so much as passed out a questionnaire. I base my beliefs on fuzzy observations, analyses of people I've known and read about. Instead of even pretending to claim I have hard evidence, I'll ask a series of questions for you to contemplate, and then I'll swing back around to reinforcing my points:
If death never loomed, would technology never progress? Would people be satisfied chiseling rocks all day because, hey, they've got so much time to chisel rocks? Or would they still move forward to find better ways to spend time?
Has the inevitable death of a young person compelled them to do something extraordinary or was it not even on their mind? Did Gandhi or Bill Gates or Napoleon think, "I'm probably going to be dead by 80, maybe I should get to work," or did they realize the need for a change and act on that?
Is there a discernible change between the fulfillment people get from their existence when they are young versus when they are old and the "deadline" is looming?
I submit that in any of these cases, mortality changes very little. People are compelled to do things and live their lives and assign values to their existence because those things are there to be done, and that would not change whether the person lived to 70 or a billion or forever.
You could argue that in the face of immortality, there would be a major societal shift in the way life, accomplishment, and value are perceived and that could very well invalidate any of the above. And I would argue that you have absolutely no idea what such a shift would look like - you couldn't even being to piece that topic.
And please, don't attempt to extrapolate a poor, anecdotal analysis of short term deadlines and turn that into a comparison on death. They're fundamentally different beasts.
Yea, that article inspired this post. So what?
2 Comments - Leave a Comment
I wrote up this pitch document late last night for a new game idea. The premise is that Abraham Lincoln travels back in time and meets a velociraptor, and the two fight crime together.
I don't like to brag, but it's solid gold.
Bugs remaining: 3.
3 Comments - Leave a Comment
I'm sitting up avoiding sleep for no bloody good reason, and I realized that the site's six year anniversary passed without mention. If you look at the 'Archives' on your right, you will notice that they go back as far as May 2004, and May 2010 recently passed us by. For newcomers and people with bad memory, the site is actually considerably older. A good chunk was lost in a tragic WVU-servers-suck accident, thus the exact birthdate is lost to time.
Before I go on: six years.
And still no more readers than we had on day 1.
It's traditional - and by this I mean it may be traditional, but I honestly don't remember - for me to recap the year's major events. A good portion of this year is blurry, though, and it's too late for me to go rummaging through the archives. I'll recall what I can and interject wild fallacies where appropriate.
(1) Zach gets married. I don't know if he actually mentioned this anywhere. I think he did.
(2) Zach vanishes off the face of the earth. His last post was over four months ago.
(3) It is discovered that Zach was eaten by a boar.
(4) My employment at Emergent ends.
(5) My employment at Sparkplug begins.
(6) I release two games on XBLIG and one on Android.
(7) I get super rich and start living on a yacht.
(8) The yacht is attacked by pirates and sinks. I rejoin my life as a land-lubber and live in a cushy apartment in Durham.
(9) I discover a board game obsession. I take over hosting of the weekly Chapel Hill/Carrboro board game night.
(10) Ricky signs on as a co-author to the blog.
(11) Ricky vanishes. We are questioning local boar for answers.
(12) Indie films! Small affairs to advertise one of the XBLIG games, but fun all the same.
(13) I break down and join Twitter. My mother is forever shamed.
(14) I watch lots of movies but review little. Still afraid of that one time six years ago when Zach snapped at me. I still maintain I am right about all the movies I've ever discussed, however.
(15) Don't think for a moment that, although I had fun with Inception, I can't pick it apart to death.
(16) I become a writer for 4 color rebellion.
(17) Kinda. I wrote one article with the promise of more, and no other articles have materialized. I still maintain hope.
(18) I start playing the Ukulele. That is not a lie.
(19) Was it this year that I started playing the drums? Time kind of munges together, but that sounds right.
(20) I form a rock-jazz-fusion band called Wicked Kite Flier/Girls in Skirts on Bikes. We tour the nation and various other nations. The word for that is "international."
(21) I learned to cook a handful of meals.
(22) Lots and lots of technical posts. Seriously, too many.
I think you get the point. A lot happened. Or not a lot happened, but I can stretch it out and insert lies to make it seem like a lot happened.
And now it's time for me to stop avoiding sleep. Good night, and let's hope for another action packed year full of suspense, intrigue, and intensity.
I really wanted to end this post with a mock TV show trailer phrase: "And this year. Someone. Will. Die." But I don't want to jinx it. Please nobody die.
3 Comments - Leave a Comment
Though all of Iron Heinrich's gameplay takes place on a 2D plane, the entire rendering system is 3D - think Viewtiful Joe or Shadow Complex. This allows us a visual style that isn't possible with 2D, and it also affords us lighting, shadows, camera tricks, and other neat things. It is, however, much more complex.
There are plenty of points of complexity, but in this post I'm going to focus on the material system. The material system is designed to allow the artist, Nate, to setup the visual style of characters and levels.
Requirements
The goal of the material system are as follows:
(1) Completely data driven. If Nate wants to change a shader or a shader parameter, he shouldn't have to talk to the programmers at all.
(2) It must support setting shader parameters that are hand-specified by the artist as well as parameters that the engine delivers.
(3) It must support multiple render passes to make things like full-screen post-fx simple and, again, data driven.
What it will not support:
(1) Dynamic shader generation. There's plenty of work that could go into writing uber-shaders or fragment based shaders, but our shader requirement is minimal (we hope), so for now Nate will be driving those all by hand.
(2) Rapid iteration - Nate will have to restart the application to see his material changes. We may be able to shoe-horn this feature in, but it's not in the design.
Materials, Material Passes, and Render Passes
There are three primary players in the system, which I'm going to overview briefly and then talk about in more complexity.
Materials are the top-level item, and each model has its own Material - for right now only a single Material, though that may change later. At their core, Materials are just a collection of Material Passes.
Material Passes are where most of the data gets specified. These specify the shader effect that gets used along with any parameters.
Render Passes represent each pass of the renderer. During a Render Pass, the Material Pass of the same name is evaluated. Render Passes themselves control the render state, the render target, and the current camera that gets used.
Now let's talk about each component with a bit more depth.
Materials
There's not much more to say about Materials. They are a collection of Material Passes, which do all the heavy lifting.
Material Passes
Material Passes do the bulk of the work. During the evaluation of a Render Pass, Material Passes of the same name as the Render Pass are selected to be executed - only if they exist. If a model doesn't have a Material Pass for the current Render Pass, it won't be rendered.
The Material Pass specifies two primary things:
(1) The effect (shaders) that will be used.
(2) The parameters that will get passed into the shader.
#2 requires more elaboration, since Material parameters take on a lot of forms. In general, there are two kinds of Material parameters:
The first kind is a hand-specified value. This could be a uniform float, the file name of an input texture, or a matrix of some kind. They're typed key-value pairs, where the key is the name of the shader parameter (the uniform) and the value is, well, the value.
The second kind is an engine-specified value, what I call an 'auto' parameter. This could be a dynamically generated texture, the current camera matrices, or the name of a light. These are just names of parameters that the engine handles, and when one is seen the renderer retrieves the appropriate value and passes it on.
Render Passes
A Render Pass is a single run at rendering the scene. During a Render Pass, the scene collects all the Material Passes of the same name for rendering, sets up the render state/render target, and renders all the models that have the appropriate Material Passes attached to them.
Render Passes keep track of the following:
(1) The render state. These are various parameters that are used to do things like turn on/off culling, change blend modes, etc.
(2) The render target. This is a named target that can be rendered to and then used later as a parameter specified in a Material Pass.
(3) The size of the render target. We don't want to always draw to screen-sized render targets, since sometimes that's a waste of memory.
(4) The camera. Each Render Pass can render from a different camera. This is necessary for doing things like good water rendering.
Use Case #1
That's a big wall of text and no doubt hard to grasp, so I'm going to provide a couple use cases so you can see how this all plays out.
This first use case will be rendering a scene to a color buffer and then applying a post effect to do a blur. It's not terribly hard:
We have two Render Passes with the following parameters:
Render Pass RP1:
Render State: Default
Render Target: TextureA
Camera: Default Scene Camera
Render Pass RP2:
Render State: Default
Render Target: Screen
Camera: Orthographic Screen-Sized Camera
At this point, the entire scene is filled with normal entities. These entities all have very generic Materials, where each Material has a single Material Pass - named RP1, which designates that generic rendering will occur during the first render pass.
There is also a special item in the scene - a full-screen quad with a Material possessing a Material Pass named RP2, indicating it will only be rendered during the second Render Pass. This Material Pass has some special parameters:
Texture: TextureA
Effect: BlurEffect
Thus, after the entire scene is rendered, the quad will be rendered to blur TextureA (and since it is part of RP2, the result of that blur will go to the screen).
Use Case #2
This will be a toon effect and has the following Render Passes:
Render Pass RP1:
Render State: Default
Render Target: TextureA - a color texture
Camera: Default Scene Camera
Render Pass RP2:
Render State: Default
Render Target: TextureB - a normal texture
Camera: Default Scene Camera
Render Pass RP3:
Render State: Default
Render Target: Screen
Camera: Orthographic Screen-Sized Camera
The Materials are largely the same as the first use-case. Even the full-screen quad is nearly identical, though it gets passed in both TextureA and TextureB and has a different effect.
Conclusions
The system has room for improvement. A shader fragment system would be nice but is a bit beyond our needs. It also necessitates writing Materials just to throw in test objects, which can be cumbersome (we have a 'test' Material to slap on for those instances). Binding Material Pass Names and Render Pass Names together is perhaps a bit of a mistake but works for our needs. Documentation also needs to be in place to remember all the different effect parameters and such.
Flaws aside, the system has been treating us pretty nicely. Nate can autonomously add complicated shader effects and change the rendering system at his whim. Later, it shouldn't be hard to write tools to make the process even smoother.
I hope you don't mind, we've reinstated your license to kill.
0 Comments - Leave a Comment
Brian - July 24th, 2010 - Dollhouse
Another Joss Whedon show I like. How shocking. <-- That's sarcasm, just so we're clear.
I wasn't expecting much out of Dollhouse. The premise seemed shaky at best, and Eliza Dushku's performance in Buffy was stomach-wrenchingly abysmal. Though I am a huge fan of most of Whedon's works, the existence of Buffy Season 6 and Angel shows he is fallible, and thus I waited a good long while before bothering.
I shouldn't be surprised that my expectations were wrong. Scratch that. My expectations are generally solid. All the same, they were wrong here. It's one of Whedon's best works. Not Firefly quality, but on par with the memorable Buffy seasons.
Like all of Whedon's successes, the show understands the necessity of creating good characters. It's hard to do any proper development when half the cast takes on a different persona each episode, but the supporting cast picks up the burden splendidly. Topher, the charming mad scientist, spearheads some excellent comedy in an otherwise somber toned show. Adelle does stalwart matron without missing a beat, and Ballard (at least initially) perfectly executes the struggling FBI agent fighting against all hope. Dr. Saunders and Boyd are both somewhat flat, though they serve their purpose adequately.
The dolls themselves are largely forgettable, even Dushku's character - Echo never quite established enough of a personality for me to care about her, and her original self wasn't particularly notable or likable. The standout here was Sierra, who took on some interesting personas and beyond that was a well-developed, interesting person. Plus she had an accent a good majority of the time, which always makes my heart do funny things.
Moving past the characters, the story itself was admirable. There were some expected twists (November's initial role being the most obvious), but happily a lot of cliches were avoided. I was especially pleased that there were absolutely no government conspiracies. The first season's antagonist Alpha was inventive and menacing. The LA Dollhouse's growth and its response to the Rossum corporation played out naturally, and it never felt like anything was forced/rush. Aside from the end, where the "villain" is revealed - his motives were a tad contrived. The leaps into the future were beautifully done and managed to provide some closure to a show canceled before its entire story could be told.
In general, I would say there were a lot of top-notch story arcs, with my only real complaint here being the lack of strong villains - they're revealed too late to properly antagonize and typically do too little. This is something Buffy did very well, so I'm a bit surprised Whedon didn't carry that trend forward.
In terms of production quality, the show doesn't have any hiccups. Some of the fight scenes are done extremely well, with Ballard hurting a lot of poor folk. The smattering of special effects were fun, and the "forward leap" episodes did a lot with a little.
I recommend this show. It probably won't make a Whedon fan out of someone who didn't like Firefly, but those someones aren't very smart anyway. It stays true to his general quality of work, and although it's not his best, it's not far off.
Oh, and Eliza Dushku does a much better job of acting. It's clear she's grown quite a lot.
Have you seen my cabinet of inappropriate starches?
0 Comments - Leave a Comment
