Student Postmortem: Postmortem pt.1

Original Author: Tyler Coleman

Hello everyone! My name is Tyler Coleman, and this is my first post on #AltDevBlogADay!

Rather exciting, isn’t it?

For my maiden post, I reviewed the Ara Shirinian’s Gamasutra post on the Game Developer Magazine postmortems over the past two years. Seeing the data for AAA and professional budget projects piqued my curiosity, so I set out to determine if there is any correlation to student projects.

In the first part of my analysis, I will cover team size, development time, and tools. This analysis will cover the general information about these projects. In my second part, I will cover What went right/What went wrong, as well as Lessons learned.

 Team Size


Student Postmortem Team Size

Student Postmortem Team Size

The average team consists of 9 people, with the majority of teams having 4. There are also a few reports of teams also consisting of contractors or part time workers. These averaged at around 5. A few outliers, such as Master Plan, had a team size well over 25. There was a broad range of team data, which will be further analyzed in my next post. The majority of members held more than one hat on the team, which is to be expected at the team sizes shown.


Development Time

Student Project Development Time

Student Project Development Time

The average development time is 8 months. The majority of projects last 7 months. I expect this is linked to the fact that most of these took place over the course of two semesters, or one semester and the summer break. There are a few that took over a year, with Gemini Rue coming in as the longest, with 3 years. There was also many projects that did not directly state their development time, so they were not included in this data.

I also did a scatter plot of team size & development time. There is no correlation between the size of team and the time of development.




Student Project Technology Chart

Student Project Technology Chart

The technology used in these games is very broad. The majority listed using an internal engine, or one that was unique to their project. This includes games such as citizenMOB, a game utilizing the J2ME SDK for an ARG. The fact that many student projects built their own engines is very interesting, as well as those that did not list any technology. One interesting aspect of this data is the change over time. Out of the most recent 10 games, almost all of them use some form of game engine or library. The games in the beginning of the data rely almost solely on internally developed engines (or otherwise didn’t list one).


I expected far more projects to be using externally-developed engines. The fact that so many projects used DirectX and OGRE is a surprise for me. I expect that there may be more of a shift towards external engines, as more colleges are now aiming at developing design and art degrees. The concern here is that many newer students may not learn the core architecture behind the game engine, but perhaps this is no longer necessary?

I also found the team size to be quite interesting. It seems that there is a broad range of team sizes, as well as game scopes. Many of the projects I have participated in were either solo or teams of around 8-12. The fact that some of these projects broke the 20 person mark really took me off guard. It is certainly a valuable lesson for the students involved, and gave the opportunity for students to assume leadership roles in a large team.

There isn’t too much to say about the development times. They are significantly shorter then the average professional product, but there were no illusions otherwise.


Part 2

On my next post, I will be covering the What went right/wrong and breaking it down into discipline, as well as subjects important to student developers. Thanks for reading!



For the love of the Game!

Original Author: Colin Michaels

Why do we make games? For the love of the game that’s Why!

Why do people play games and for an even better question why do game developers sit in front of a computer for hours on end to make these games.
 Even though for most game makers it is considered a  job I would hope and think
Gamer Mouse

Just playing for a piece of Cheese!

the reason they got into it was for the love of the game.  For the hobbyist game developer there might be a different  driving force and as of right now that is the category I would consider myself one of the hobbyists until I receive my first big check for creating a game.  Though even if I never get paid to do this I plan to continue doing it long into my golden years.

Why do you make games?

Is it for the glory, personal satisfaction of it, the money (when there is some), the groupies(*chuckles)?  I personally got interested in making games for the pure challenge of it.  Coding, texturing, sound designing for games to me is like a puzzle.  How do I put the pieces together to create the bigger picture.  Sometimes those pieces might not work and you find out you have the wrong puzzle piece.  Building your coding skills is like leveling up in a game.  Finding a new piece of software or new site that has some great asset to use to help in your next project is like getting some great loot in a MMO.  Completing and publishing your first game is like conquering the final boss battle and winning the final prize.

Gaming Puzzle

Future of Gaming:

How will we play games in five, ten , twenty years.  How will we make games? Will there be the Sci-Fi chips in our heads where we jump into a Virtual Reality scenario and become the players.  Interactivity in games with the advent of the Wii and the Xbox Kinect are trying to get players up off the couches and chairs and into the games.  But, can all games be played this way and do you want to have your games played this way.  I personally do not,  though, I think there is a definite market and place for games like this.  I just would rather not play a FPS and have to run around pretending I’m toting a gun.  There’s a place for all types of games and all types of gamers whether it be for educational purposes, training, pure enjoyment or pure profit there’s a game out there for everyone.

Faster Game Processing

Side Notes:

About Me.. (more Ramblings)

I’m currently a returning college student working on a future game development career.  So maybe my viewpoints are very skewed and optimistic since I haven’t yet been tainted by an industry background.  But I come from a very similar entertainment field from working in the music industry for over ten years I can relate and take some of the lessons I learned there and apply them in my future endeavours.  For the same reasons I’m pursuing this career is why I got into music business.  Had I known it should have been named “business music” I would have thought twice about going down that road, but the love for the craft and the process behind it kept me going and eventually having a successful career.  I think with anything you love it can be spoiled if you let it be and I plan to learn from my mistakes in the past.


Bored Game – A Cautionary Tale For Design Students (Part 2)

Original Author: Andrew Meade

Earlier this month, I embarked on a two-part odyssey chronicling the misadventures of my design team as we built an analog game for class. You can read part one here, but the tl;dr version goes like this:

 We spent two weeks of a three-week project developing a game that we were too stubborn to admit broken. It was broken because we split the focus of our team, ignored crucial states of play, and waited too long to prototype. At the end of the second week we scrapped our previous board game model, and decided to do a pen and paper RPG. It was an odd choice considering the time frame, but there was logic behind it.



When working in the AAA industry, we had been told ad nauseum that they wouldn’t give be giving us the opportunity to bring our “visions” to life on a daily basis. With that knowledge in mind, we thought that maybe it was best to get our rocks off in school – after all, how often would we get the opportunity to make the games that we wanted to make without going indie? Not that going indie is a bad thing, mind you…


Lesson #5: Follow your heart. Make the games you want to make while you still can, but remember that those games still have to be games that players want to play! 

Initially, the other designer and I wanted to make a tabletop RPG, but passed over it in favor of a board game. We felt that it was better to limit our scope and get something simple out there that worked really well. However, we both wanted to make an RPG so bad, that the initial board game got hit by a hard dose of feature creep. RPG elements were snuck in daily, and soon it was a massive, bloated whale of a project that we just couldn’t keep up with. Maybe it was subconscious, but we never really loved the game we were making. In the end, that ended up biting us in the ass really badly. When it came time to scrap the initial game, there wasn’t a choice. We were going to make an RPG, because darn it – that’s what we wanted to make all along.

So we sprung to action.


Lesson #6: Don’t have time for a full product? Make it modular! 

The first task was (again), limiting scope. We didn’t have time to make something terribly in-depth, so we went for a style that new players could cut their teeth on.

The logic was relatively sound. Say you have a friend that is intimidated by the dense and massive RPG’s out there, but you have inkling that they may enjoy it. You could set this game up, and run a two month long campaign to whet their appetite.

Conversely, if you were experienced RPers looking for a new world to conquer, the game would give you enough flexibility to add as much complexity as you wanted. What resulted was basically two different “modes”. The first followed the instructions to the letter for new players, and the second served as a framework for an experienced GM to work off of.

Furthermore, as we only had seven days to make this product work, we decided to give the game a low level cap with the intent of adding expansions on a quarterly scale. Each new expansion would explore a new and exciting world, as the lore revolved around traveling through different dimensions. The sky was the limit, and we really felt that it would work out well. If executed properly, the game would give mini-campaigns four times a year for players to diddle with when they needed a change of pace, because let’s face it – nobody was quitting D&D for another RPG any time soon.

Modularity became the mantra. Make classes that can stand alone, but also be vital group assets. Give each class a toolkit that is powerful, but amazing when combined with the rest of the party. We made the experience 90% combat, 10% RP, because we felt that combat would be the intoxicating nectar that would leave our players craving for more. It wasn’t like you couldn’t RP more if you didn’t want to – but the important part was that you could sit down, pull out your character mat, and just do it. We wanted adrenaline to be a factor in the game, and making the players just a little too powerful was a great way to do that.


Lesson #7: Be agile…in your development….

Iteration became key. Every day we would make the entire game from start to finish from the previous model. We were prototyping combat immediately, and continued to prototype very often. Major slips weren’t getting past us – and we were hoping that the minor issues would be countered by engaging gameplay. We only had seven days, so we had to make our peace over the fact that we knew it couldn’t be perfect, and our grade would likely take a hit regardless. We stopped focusing on our grades, and worried more about delivering an excellent, workable concept that could be expanded on with a more generous time frame.

It was rapid trial and error – every day. This brings me to a saying from one of my favorite professors.


Lesson #8: If you’re going to fail, fail fast! – Keyvan Acosta

Through flexibility and rapid prototyping, we were able to knock down every major problem as it came. Failure came and went – an everyday product of creating a game. We chose to fail fast – the faster we failed the quicker we learned. The difficult part, of course, was actively choosing to not ignore the hard problems in favor of saving them for later. Seven long days of balancing, rebalancing, tweaking, iterating, and iterating some more and we were finally done. We zipped our game up, submitted it to our teacher, and waited.


Lesson #9: You can’t win ‘em all.

Although later our teacher would tell us that our game was conceptually the best and most engaging submission, our final project netted an 84.

There just wasn’t enough time in the week, and the biggest problem was that the game manual just had too many holes. We all knew how to play the game, but we crunched too hardcore to get all the information in the manual.

Some teams did much better, some teams did worse, but they didn’t get the experience that we got. We made two games, experienced an insane crunch time, and stoically marched toward a deadline knowing that we would be lucky to pass. We did all this, because we love games. We love making games, and we love to learn.

So, game design students. What’s the moral of the story? Don’t be afraid to experiment and fail. If you end up with a lesser grade for it, then fine – but most of the time the gamble will pay off, and you will have been better for it. After all, we ended up with an education the class never could have given us intentionally. And I’ll take a B for that any day of the week.



Meet my dog Chester

Original Author: Rolando-Abarca

Technology/ Code /

Meet Chester

Chester is my dog. He’s sloppy and messy, but most of the time, let’s say 80% of the time he’s the best dog in the world PERIOD.

The other that I asked him: “Hey Chester, would you mind teaching me some WebGL? I understand you’ve been playing a lot with it, and you even made some cool WebGL demo”, and since he’s such a good dog he had no problem in teaching me.

First, the first

Chester is a good dog, but he’″>learning webgl and when you finish with the lessons, come back for some really premium extra knwoledge”.

After reading the lessons, Chester asked me: “hey, what about we go through the basics? – and while we’re on it, let’s take a look on how we can optimize what you just learned – but for 2d, and add some other things in the way, like a graceful fallback to canvas when webgl is not enabled.”

And so we did. These are the basics.

1) WebGL == OpenGL-ES 2.0

Don’″>webgl lessons are good enough for starters.

2) Let’s take you to the matrices

When it comes down to WebGL, it’s all about your matrices, you have the projection matrix, the model-view matrix and some other matrices.

But what are the 3d matrices? Here’s where your linear algebra classes must be remembered. For us they’re going to be basically transformation matrices. 3D ones. So you use them to store your model transformations: translate, rotate, scale. In order to concatenate two transformations, you would just multiply them and the result is the concatenation.

In order to understand a little bit more about this, Chester brought up the next example: let’”>cocos2d.

The scene graph is what holds the objects in your game scene and how you would traverse them. The basic structure we’re going to use is a block (like a construction block) and every block can contain other blocks. Blocks transformation should be relative to it’s parent, like so:

In this example, the big block (a 64px square) is the parent and the small one (a 32px square) is the child. The big block is positionated at the middle of the canvas, and the little one has a relative position of {32,0}. Since 32 is half the width of the parent, the center of the child is exactly on the right side.

Ok, let’s have some fun, first let’s move the little one outside the bounds of the block, so if we set its position to {32 + 16, 0}, it should be right outside:

Cool. Now let’s rotate the bock 45 degrees:

Even cooler 🙂 – What would happen if we rotate the parent in -45 degrees?

And that’s how our concatenated transformations should work: the child transformation (so far, rotation -> translation) should be concatenated to the one from the parent. The first 3 examples were just a single translation, but after that, we added the rotation, and since we rotated the parent in -45 degrees, it looks like if our little block is not rotated.

Fun fun. But enough for now said Chester, we need to move on.

3) It’s all about 2D

We’re going to use WebGL, a 3D engine to do some cool and performant 2D graphics, like 2D sprites and 2D games. So Chester said “When doing 2D we face a completely different challenge: you will not be filling the screen with thousands of triangles, you will be sending lots of textures to the screen, so your bottleneck will be the fill rate instead of how many triangles you want to draw. The fill rate is how fast you can send the texture — usually a much higher quality texture than in a 3D game — and how many of them you can use at the same time in the screen”. Then, after a small break playing with the ball, Chester continued “The thing is, to achieve what we want, we will be fixing a coordinate, in this case z = 0, to draw everything in a plane. Thus, our sprites will be represented by two triangles forming a square and that square is the constructing block we talked about earlier.”

Show me the code!

I was getting a little bit bored with too much talking and no coding, so I demanded Chester to show me the code. He said “ok, but I will just give you the hints, you can build up from there and make sure you refer to the webgl lessons when you feel lost”.

And so, Chester continued “The first thing we will do, is to set our projection. The projection we’re looking for must be a 3D, but must look 1-1 with the pixel size of the canvas we’re drawing into, right?”. And then he started typing.

setupPerspective: function () {
  	var gl =;
  	gl.clearColor(0.0, 0.0, 0.0, 1.0);
  	var width = gl.viewportWidth;
  	var height = gl.viewportHeight;
  	gl.viewport(0, 0, width, height);
  	this.pMatrix = mat4.create();
  	if (this.projection == "2d") {
  		// 2d projection
  		console.log("setting up 2d projection (" + width + "," + height + ")");
  		mat4.ortho(0, width, 0, height, -1024, 1024, this.pMatrix);
  	} else if (this.projection == "3d") {
  		// 3d projection
  		console.log("setting up 3d projection (" + width + "," + height + ")");
  		var matA   = mat4.perspective(60, width / height, 0.5, 1500.0, matA);
  		var zeye = height / 1.1566;
  		var eye    = vec3.create([width/2, height/2, zeye]);
  		var center = vec3.create([width/2, height/2, 0]);
  		var up     = vec3.create([0, 1, 0]);
  		var matB = mat4.lookAt(eye, center, up);
  		mat4.multiply(matA, matB, this.pMatrix);
  	} else {
  		throw "Invalid projection: " + this.projection;

NOTE: “for now, think of this as a magic object that holds some important information. We will be building around it and with time, you will understand”, Chester said.

The first thing that I asked after reading the code was “Wait! what’s that weird hardcoded 1.1566 number!?”. And Chester told me what it was:

“It’s there to gives us a 1-1 relation between opengl points and pixels at the plane z=0. It has to do with the field of view, which we also hardcoded to 60 degrees. Don’t ask me how I came up with this number – it’s being transfered over generations”. Later I found that Chester just copied the number from cocos2d and that he couldn’t trace the number. But you will have to believe me that it has to do with the fov.

And then Chester started to discuss the “3d” projection.

“So, you first create a simple projection matrix, with a fov of 60 degrees, with the right aspect ratio, znear of 0.5 and zfar of 1500, and store that in matA. After that, we calculate the parameters for the lookAt, which are the zeye previously discussed, the eye, center and up vectors. We pack all those into matrix B, and concatenate those transformations in the pMatrix, the projection Matrix.”[1]

So, how do I render a sprite? I asked Chester, and so Chester answered.

“What is a sprite? I already told you a sprite is two triangles, but how are they represented in the webgl world? Let’s see what we need first.”

  * @type {?WebGLBuffer}
  glBuffer: null,
  * @type {Float32Array}
  glBufferData: null,

That’s all? I asked, what about the buffer for color, position and textures? (remembering the lessons in webgl). And Chester told me that we could pack all those in a single array, a technique known as “interleaved array”. That sounded cool, so I asked him more about that.

   * this is the size of the buffer data (Float32Array)
   * @const
  Block.QUAD_SIZE = 36;
  Block.create = function (rect) {
  	var b = new Block();
  	if (rect) {
  	// set default color
  	b.setColor(1, 1, 1, 1);
  	var gl =;
  	// just a single buffer for all data (a "quad")
  	b.glBuffer = gl.createBuffer();
  	b.glBufferData = new Float32Array(Block.QUAD_SIZE);
  	// always create the mvMatrix
  	b.mvMatrix = mat4.create();
  	return b;

Why 36? I know what a “quad” is (frame + texture + colors), but why 36?

36 == 12 + 8 + 16
  12 == 3 * 4 // 4 points for the frame, 3 coords each (x, y, z)
  8 == 4 * 2 // 4 points for the tex coord, 2 coords each (u,v)
  16 == 4 * 4 // 4 colors, one for each point in the frame, 4 coords each (r, g, b, a)

Ok, that makes sense. But how do we send the data to the GPU?

render: function () {
  	var gl =;
  	// select current shader
  	var program = ChesterGL.selectProgram(Block.PROGRAM_NAME[this.program]);
  	gl.bindBuffer(gl.ARRAY_BUFFER, this.glBuffer);
  	var texOff = 12 * 4,
  	    colorOff = texOff + 8 * 4;
  	gl.vertexAttribPointer(program.attribs['vertexPositionAttribute'], 3, gl.FLOAT, false, 0, 0);
  	gl.vertexAttribPointer(program.attribs['vertexColorAttribute'], 4, gl.FLOAT, false, 0, colorOff);
  	gl.uniform1f(program.opacityUniform, this.opacity);
  	var texture = ChesterGL.getAsset('texture', this.texture);
  	// pass the texture attributes
  	gl.vertexAttribPointer(program.attribs['textureCoordAttribute'], 2, gl.FLOAT, false, 0, texOff);
  	gl.bindTexture(gl.TEXTURE_2D, texture.tex);
  	gl.uniform1i(program.samplerUniform, 0);				
  	// set the matrix uniform (actually, only the model view matrix)
  	gl.uniformMatrix4fv(program.mvMatrixUniform, false, this.mvMatrix);
  	gl.drawArrays(gl.TRIANGLE_STRIP, 0, 4);

All right! now we’re talking. I could see that Chester was using the well known vertexAttribPointer, but just one bind and setting the offset of the call to match the position of the array. He’s also multiplying the offset by 4 because a Float32Array contains 4 bytes. Clever dog! Then I gave him a treat. He was happy.

Chester then showed me the shader and it was nothing out of the ordinary, just a very simple texture shader. So I asked him “Ok, but how do I fill the bufferData?”

transform: function () {
  	var gl =;
  	var transformDirty = (this.isTransformDirty || (this.parent && this.parent.isTransformDirty));
  	if (transformDirty) {
  		mat4.translate(this.mvMatrix, [this.position.x, this.position.y, this.position.z]);
  		mat4.rotate(this.mvMatrix, this.rotation, [0, 0, 1]);
  		mat4.scale(this.mvMatrix, [this.scale, this.scale, 1]);
  		// concat with parent's transform
  		var ptransform = (this.parent ? this.parent.mvMatrix : null);
  		if (ptransform) {
  			mat4.multiply(ptransform, this.mvMatrix, this.mvMatrix);
  	var bufferData = this.glBufferData;
  	if (this.isFrameDirty || this.isColorDirty) {
  		gl.bindBuffer(gl.ARRAY_BUFFER, this.glBuffer);
  	if (this.isFrameDirty) {
  		// NOTE
  		// the tex coords and the frame coords need to match. Otherwise you get a distorted image
  		var hw = this.contentSize.w / 2.0, hh = this.contentSize.h / 2.0;
  		var _idx = 0;
  		var z = this.position.z;
  		bufferData[_idx+0] = -hw; bufferData[_idx+ 1] = -hh; bufferData[_idx+ 2] = 0;
  		bufferData[_idx+3] = -hw; bufferData[_idx+ 4] =  hh; bufferData[_idx+ 5] = 0;
  		bufferData[_idx+6] =  hw; bufferData[_idx+ 7] = -hh; bufferData[_idx+ 8] = 0;
  		bufferData[_idx+9] =  hw; bufferData[_idx+10] =  hh; bufferData[_idx+11] = 0;
  		var tex = ChesterGL.getAsset("texture", this.texture);
  		var texW = tex.width,
  			texH = tex.height;
  		var l = this.frame.l / texW,
  			t = this.frame.t / texH,
  			w = this.frame.w / texW,
  			h = this.frame.h / texH;
  		_idx = 12 + this.baseBufferIndex * Block.QUAD_SIZE;
  		bufferData[_idx+0] = l  ; bufferData[_idx+1] = t;
  		bufferData[_idx+2] = l  ; bufferData[_idx+3] = t+h;
  		bufferData[_idx+4] = l+w; bufferData[_idx+5] = t;
  		bufferData[_idx+6] = l+w; bufferData[_idx+7] = t+h;
  	if (this.isColorDirty) {
  		_idx = 20 + this.baseBufferIndex * Block.QUAD_SIZE;
  		var color = this.color;
  		for (var i=0; i < 4; i++) {
  			bufferData[_idx+i*4    ] = color.r;
  			bufferData[_idx+i*4 + 1] = color.g;
  			bufferData[_idx+i*4 + 2] = color.b;
  			bufferData[_idx+i*4 + 3] = color.a;
  	if (this.isFrameDirty || this.isColorDirty) {
  		gl.bufferData(gl.ARRAY_BUFFER, this.glBufferData, gl.STATIC_DRAW);

In a step by step:

  1. If the transform is dirty (that is, if we moved the block, rotated or scaled it), after that we need to recalculate the transform. Also, if our parent’s transformation is dirty, we also need to recalculate it.
    1. To transform, first load the identity, second translate, then rotate, and finally scale. The order is *very* important! Lastly, if we have a parent transformation, we must concatenate it with the one of the current block.
  2. When the transform is ready, it’s time to fill the buffer data:
    1. If the frame is dirty, copy the right coordinates on the vertex first to form the two triangles: bottom left, up left, bottom right for the first one, and the last two + top right for the second triangle. The same thing goes for the texture, but without z.
    2. The color is easy: just copy the current color on the four vertices.
  3. As a final step, send the buffer data to the webgl buffer.

Seems pretty easy. Chester pointed out that having the Float32Array created just once and copying the data only when it has changed makes a huge performance improvement.

I had only one question left: How do you start the whole thing? I mean, how do you start the rendering chain?

   * main draw function, will call the root block
   * (this is in ChesterGL)
  drawScene: function () {
  	var gl =;
  	// global blending options
  	gl.blendFunc(gl.SRC_ALPHA, gl.ONE_MINUS_SRC_ALPHA);
  	// start mayhem
  	if (this.rootBlock) {
  // this is in a Block
  visit: function () {
  	if (!this.visible) {
  	var children = this.children;
  	var len = children.length;
  	for (var i=0; i < len; i++) {
  	// reset our dirty markers
  	this.isFrameDirty = this.isColorDirty = this.isTransformDirty = false;

The magic begins with the drawScene method, that basically creates the chain reaction, first visiting the root block, and in turn the root block will visit all their children. Chester also said that the visit method can be improved and that is in this point where you want to keep an eye on the rendering order: since all your objects are in the plane z=0, the rendering order is what says what is on top of each other.

At this point Chester unveiled the curtain and told me that he had written this simple 2D engine/demo using WebGL, that even falls back to the canvas API when there’”>Texture Packer format) and tile maps (TMX files). He called it “ChesterGL” because it was his library.

He passed me the source code, I added a MIT license to the files and placed them in a github repo for everyone to hack them: we want more HTML5 games!

Cool! Now for the rest of the stuff, I’ll leave that for another post, like how Chester approached the canvas API fallback. Spoiler: it was easy, canvas provides a setTransform() method!

Why Code Reviews Can Fail

Original Author: Lee Winder

In my last post I covered what I see to the The Benefits of Code Reviews. But with every process there are problems that if not tackled can cause teams to lose these benefits and remove it from their development process.

So what do I see as the biggest problems facing introducing and maintaining a code review process?


Aggressive reviewers & victim syndrome

Code reviews are there to improve the code base for the benefit of the team. They are not there to ‘go on the attack’, to rip some-one’s code apart or to make someone feel like they are not good enough.

If people start to fear putting up their code for review then the number of reviews will suddenly start to drop or even worse only the most trivial of code will be submitted.

The opposite of this is the review owner who is too sensitive to any kind of code critique. Any non-positive comment is seen as an attack on them rather than the code and criticism is met with defensive comments rather than seeing it as an opportunity to learn.

Having an over-aggressive reviewer is not that difficult to tackle. Taking them to one side, reviewing their comments and how they approach the reviews will often resolve the issue quite quickly. Most of the time the reviewer won’t even be aware of how their comments are coming across and are not intending to be aggressive at all.

The later is much harder to solve.

Quite often the developer is highly protective of the code and may be more defensive when reviewed by certain developers. It might be possible to start off by restricting who reviews their code or what is reviewed, starting smaller and slowly introducing more of their code to more people over time.


A Lack of Positivity

Remember that there is nothing wrong with the only comment on a review being “That looks great!”.


Lack of Outcomes

People will argue, and people will disagree, especially when it comes to code. “You should do it like this”, “I don’t want to change that because…”. Discussions are great and should always be encouraged, but at some point there needs to be a decision.

You have to know who has the final say – whether this is a manager who is on every review, or a senior responsible for the quality of the code. A simple comment along the lines of “That’s a great suggestion for the future” can put an end to most arguments with most people being happy with the outcome.

Sometimes a short face to face discussion will bring these discussions to a suitable close for everyone involved if the discussion starts to turn into a tit-for-tat point discussion.


Lack of Follow Through

The worry here is that nothing changes as a result of the code review. Obviously not every suggestion or comment needs to be acted on but if developers are seeing review after review being posted and time and again every comment being ignored or not even acknowledged, it can have a devastating effect on buy-in.

This kind of behaviour is both demoralising and infectious.

If developers see their comments being ignored time and time again they will start to do two things. Comment less and react less.

If their comments are being ignored then why should they continue to post more comments? And if people can ignore their comments why should they respond to comments on their reviews?

Sometimes it takes time to respond to a review comment. To avoid situations of reviews just ‘sitting there’ I like to make sure there is a closure plan for all reviews. That way people know that if a review is still open but not responded too, they are still processing the information.

But if reviews are constantly being closed and the suggestions ignored, then this needs to be resolved quickly. Maybe a manager or senior developer re-opening the review to ‘bump’ the comments to make sure they are referenced might solve the problem quickly enough.


Unfocused Reviews

Sometimes people don’t know what to review so every review dawdles around the code and nothing of note ever comes to the surface. In a lot of these cases review after review will seem to focus on coding standards and nothing else.

In situations like these I like to ask people to suggest where people focus their time on the review. This won’t be on every review and it’ll only be certain developers who do this (usually those who know where their weaknesses are).

By suggesting areas for people to focus on it will start to open up both those reviews and ones that don’t have specific suggestions as people start to get more ideas as to what to look for and what might be important.


Unrealistic Expectations

There are no silver bullets for a development team. No process will take you to a communication nirvana, there is no way of working that will stop code rot and nothing you can do to stop some bugs getting through to a possible submission build.

If you start to expect that a code review process will cause every bug to be spotted before the code is submitted or that suddenly every ones skill level will rise to that of the best developer on the team then you’re setting yourself up for disappointment.

But by accepting that the review process won’t solve all your problems but that it will have a generally positive and cumulative effect on the quality of the work being produced those expectations will start to lower but your team will be better off for it.


Any More?

There are not the only reasons why a code review process can falter but from my experience they are some of the main ones. What things have happened to your review processes in the past and, most important of all, what could have avoided it?

In the next post I’m going to describe some of the different ways we’ve reviewed code and the various benefits and pitfalls they had.

Apologies if I take some time to respond to comments to this post. I’ve scheduled this to be posted while I’m out of the country and I won’t have the time or opportunity to respond until I get back. But don’t let that stop you posting! 🙂


mroth.  Used with permission.


Team Audio vs. The Milestone

Original Author: Ariel Gross

Time again for the epic battle of the ages: Team Audio vs. The Milestone! It sounds much more glamorous than it is, but it is yet an epic battle, and it is probably safe to say “of the ages,” because it has happened approximately one billion times already and will surely happen again at any moment now.

A background of the opponents.

Team Audio is the audio team working on a game. Probably obvious, but one never knows. Team Audio could be a team of a dozen, or Team Audio could be a lone wolf, or any range in between. Team Audio needs to hit deadlines just like all the other disciplines. But where do those deadlines come from? That leads me nicely into The Milestone.

The Milestone is a chunk of time, basically. A chunk of time in which, hopefully, work gets done. At the end of The Milestone, progress is measured, so everyone endeavors to accomplish the things that they set out to accomplish before The Milestone ends. Towards the end of The Milestone, I tend to ask myself all sorts of questions. Did I meet all of my goals? And did I squash all of my bugs? And did I remember to brush my teeth? Because that’s also very important.

The Milestone can vary from developer to Developer, and even from project to project, which I’ll talk about later because it has happened at Volition. So, your experience of The Milestone might be different than my experience, but that doesn’t really matter to the point that I will eventually be making. You’re probably thinking, get to the epic battle (i.e. the point) already! Alright, alright! One last thing, though.

To understand the battle, you should probably first understand where audio fits into the schedule in game development. It’s easy. Most of the time, audio comes last. There’s no sense in designing a glorious explosion sound effect when we haven’t yet seen the explosion. I mean, we’ll make something awesome, but when we find out that the explosion has green flames and a bunch of silverware shooting out from it, we might need to redesign the asset. That is unless we always put silverware clattering in our explosions. (we do)

Anyway, what you need to know is that audio tends to happen last, after the visuals have been completed. Or after the lines have been written. Or after the fire rate on the gun is dialed in pretty close. Or any other number of variables that would make us change how the thing, whatever it is, could sound. Otherwise, we run the risk of wasting time.

The battle begins!

The Milestone has begun and all of the disciplines start grinding away at their work. And it looks like a couple disciplines are going to barely make it! Team Animation and Team Mission Design only have a couple of days to wrap up their work… it’s getting so close, now… and BOOM! Team Animation and Team Mission Design finish their work in the nick of time on the final day of The Milestone! Team Audio can now design and implement the sound effects for those animations and missions. Will Team Audio make it? Nope! I’ve just said that it’s the last day of The Milestone.

Team Audio might do something miraculous and valiant and actually finish their work by the end of the day or over the weekend. It happens all the time, in fact. But even if others can’t tell, Team Audio knows that those sounds are nowhere near the quality that they could have been if they’d had more time. Actually, little secret here, Team Audio will redo those assets later, probably at a much more inconvenient time, like towards the end of the project. It’s not unheard of for Team Audio to not tell anyone that they’re redesigning those sounds, just so that they can redesign those sounds.

Before we get to the potential and possibly obvious solutions, I feel like I should be clear about a couple of things. First of all, Team Audio failing to complete their work by the end of The Milestone is not the fault of Team Animation or Team Mission Design in the above example. In fact, Team Audio will be happy that the other teams got their work done on time. Nor is it the fault of Team Audio, and I hope that fact doesn’t need explaining. Secondly, The Milestone isn’t a bad guy. The Milestone can be very valuable and important, though applied incorrectly in this case, I think.

Is there a better way?

Team Audio might push for other disciplines to complete certain things earlier than others. That’s not a bad solution, really, but it’s not very reliable, either. Team Audio could ask an animator to make the animation of the guy getting punched in the face before making the one of the guy lifting his arm to light his cigarette, because the first one will likely need sound effects while the second one could get by without. Unless of course the guy is whipping that cigarette up to his face super fast. Then you’d want a wicked kung-fu whoosh like a ninja is trying to punch Bruce Lee in the nads. Anyway, this could work, but then Team Audio might be messing up Team Animation’s flow, or Team Animation might forget. But it could work, and I think it’s better than doing nothing.

In my opinion, the better solution is to give The Milestone a little compadre called Audio Milestone. Audio Milestone wraps up a week or two after The Milestone is over. This way, all of the other disciplines can proceed as normal, and then Audio Milestone kicks in, and Team Audio has the chance to give the project the love and quality that it deserves and needs. Added benefit: Team Audio can cut $45 from their monthly Pepcid AC budget!

This is what Volition has done for one (and probably both) of our upcoming projects. On Red Faction: Armageddon and Saints Row: The Third, it was Team Audio vs. The Milestone, and Team Audio became adept at phrasing their goals in such a way that they wouldn’t fail if they couldn’t get their work done due to a late-arriving deliverable. Next projects, though, instead of Team Audio vs. The Milestone, it will be Team Audio <3 Audio Milestone.

And what about the future?

But there is a great nothing on the horizon, a deep and endless murky black, drifting slowly across the lands. It’s inky tendrils, while far away, creep towards Team Audio and leave an eerie hush in their wake. And that vast darkness is named The End of the Project. What happens at The End of the Project? Because, if you think about it, Audio Milestone can’t go on forever, can it? Will Team Audio be given time at The End of the Project to complete their work after everything else has been locked down and truly will not change?

We’ll see. Maybe I’ll be writing about a new and different epic battle sometime in the future. But at least it won’t be “of the ages.”

My design method: Interweaving

Original Author: Julien Delavennat

Warning:  there might be a couple of light spoilers, but everything is in the trailers anyway so… nevermind that.

I hope what I’m going to say won’t sound too stupid, agreeing with everybody and not making a fool of myself is really hard. n_n

That being said:


  • DON’T duct-tape features together to make Frankenstein-style abominations.
  • DO find natural sources of gameplay/setting harmony and consistency.
  • DO identify the axes from which your game is built in order to know what you should and shouldn’t do (it also works for other forms of intellectual construction).


This has been my main design paradigm and method for the past year. I understood the base concept about a year ago, and spent a few months refining it into a model for quality creative direction. The main idea is that in quality artworks, everything just fits perfectly; you can call that harmony, purity, focus, or whatever.

There are 4 main axes that need to be taken into account when using this model: Perimeter, Exploitation, Justification, and Legitimacy. These axes are used in the following way: you define a perimeter, then exploit it, by justifying that your exploitation of the perimeter is valid, and making the legitimacy of your perimeter obvious.

Simply put: find a nice place to dig (like a goldmine), and DIG deep, don’t just scratch the surface.

I realized later that that described very precisely what QUALITY is about.

Here’s a definition of quality we were taught at university: “a product’s ability to satisfy known or unknown user needs”.

Making quality art is somewhat easy, you just define what you want to do, and do it.

If you define something worthwhile to make, and succeed making it, you have quality.

It’s a sort of exploration of the Ideosphere: define a need for exploration like “hey, we should totally make a game about …” and satisfy that need.

That’s what happens all the time: you publish a trailer for your game, and create a need for your players to put their hands on it.

If you satisfy that need, you win, because you only have to satisfy the need you’ve created, which you can probably quantify.

If you don’t, you frustrate your players and lose.

You need to define very precisely what you’re making and announcing, it’s very very important.

Let me explain.


I’d say, I usually start defining a game from an idea, but there’s often a couple of other questions I need to answer before I can do anything. “What am I going to do with this idea ?”, “How am I going to do it ?”, “What options do I have ?”, “What should I do ?”.

I’ll use examples:


So I guess the first idea was the portal thing right ?

What did they do with that mechanic ?

A Strategy game ? A fighting game ? nope, a Puzzle Game.

Third person ? RTS view ? nope, First person.

How are the portals used ? you have a gun.

What do you do ? You escape from a science facility.

What’s relevant in here ? I would say you can sum up the game by “first person puzzle game with portals”.

So we have “Portals”, “Puzzles”, and maybe “First person view” as keywords to describe the game, “Portals” being the main one.

Portal is what happens when you combine portals and puzzles like this:

When you think about it, almost every game, or artwork has a couple of base axes like this:

  •  Super Meat Boy: Platformer, Hardcore, OldSchool – Everything in the game just says “I’m the revival of the oldschool platformer games (but without everything that went wrong at the time)”
  • Braid: Time manipulation, Puzzles, Depth
  • Angry Birds: Demolition, Puzzles, Simple

The thing is, these axes I’ve just given aren’t necessarily valid, but that’s what I work with, and it works very nicely.

It even works for other domains than video games, music and film for instance: any artwork can be described as being made by combining a couple of axes.

You can see an intersection area on the Portal axes diagram.

That is what I call a perimeter.


There’s a couple of things to be said about perimeters.

What happens when you don’t actually have any intersections between your axes ?


Just take features and throw them together, you’ll find out that your features are interchangeable.

From what I know, that leads to hollow games, clones, and cookie-cutter production.

Take a look at this graph:

Games like this are just the sum of their parts, like dead bodies, and dead bodies aren’t exactly engaging by default.

It’s like making Frankenstein-style abominations: not games, but bits of games stitched together. See the difference between the two ?

So we have to find intersections, to find synergy between ideas, which creates new real ideas to work with, before we start making anything.


So what do we do to make games that are designed naturally, and not artificially ?

Well there’s one thing that happens sometimes, and that is really awesome: there is a strong link between mechanics, and setting.

How awesome is that ? well, it’s a start for NOT making duct-taped stuff.

I call that Hyperweaving.

What is Hyperweaving ? It’s when there’s an equivalence between your gameplay and setting: they imply each other.

Your mechanics and setting are basically the same: you could say that you have a consistent game world.

I’ll take Mighty Jill Off as an example: Jill is sent downstairs by her queen, and she has to climb back up.

Jill climbing up and you making her jump are the same thing: you can’t have one without the other.

That’s organic design, it’s consistent, natural, not stitched together… you get the idea.

Another example, Half-Life: you’re escaping from Black Mesa, which implies shooting stuff.

You escape from a science facility, and you need to shoot stuff.

You shoot stuff, to get out of a science facility.

See how hard it is to separate the setting and the mechanics ?

Again take Counter-Strike for instance (sorry for the Valve over-representation here, they just happen to make insanely high quality games from what I understand):

How could we get the same gameplay without the terrorists vs anti-terrorists setting ? (I mean, the bombing/hostage rescuing and team infiltration)

How could we have a terrorist vs anti-terrorist setting without some good old team infiltration and bombing ?

It would need some serious re-arranging for that to be possible.

In hyperweaved games, everything just fits so well together, you have a hard time isolating elements because of how tight and closely woven together things are. Organic design is when everything is just too intricate for you to see through.

And it’s really engaging to feel like you’re not presented with a mechanical system instead of good company to spend time with.

I feel I need to give an example of a non-hyperweaved game.

I hate saying nasty things about specific people. I wuv everyone :3. It’s just regretful that people make mistakes.

I won’t give names, but I’ll say I’ve played a AAA game recently that could have had the exact same story but with a totally different gameplay to it.

Or the exact same gameplay but with a completely different setting.

That specific game, didn’t have anything special gameplay wise, and the setting was just slapped as Art and story assets, without much to do with gameplay.

It was very conventional.

Conventions should never be where you stop, but only where you start.

A hyperweaved setting is what you’re looking for.


Well then, turns out this post ended up being longer than expected.

I guess I’ll have to divide it into several parts.

So for the moment, I’ve only talked about perimeters.

Next time: exploitation and actual design methods.

In the meantime, if any of this is either too obvious or too confusing for you, please tell me. n_n

Please don’t pay too much attention to the fancy words I use.

I don’t want to pretend I’m bringing anything new, everything is there under our nose, we just need to understand it.

I know this is stuff I’d like to have understood years ago, and I hope you can get something out of this post too 🙂

Have a nice day n_n

How the austrian guy ended up working in the games industry

Original Author: Stefan Reinalter

Technology/ Code /

I figured it would be quite nice to have some sort of introductory post here on #altdevblogaday, so what could be better than telling my story of how a guy from the small country of Austria (we’re the ones without the kangaroos, we’re living next door to Germany/Italy/Switzerland) ended up working in the games industry? So here goes…


Early addictions

It all started more than 20 years ago, when my father introduced me to video gaming on the Pitfall on our old TV. Because games were so expensive back then (around ~100€ nowadays, not taking into account inflation!), my family used to buy games only twice or three times a year, leaving us with an incredible collection of about 8 games. Still, we used to play them whenever we were allowed to.


Arrival of the C64

One or two years later, my father invested his money in our first computer – the Commodore 64. Ah, the C64!

Not only did it feature a vast collection of games, it also made it possible to copy games (piracy was a big problem) – there weren’”>Austria at that time, so we more or less had to get them by copying from somebody. Turned out my father knew a few people, so we ended up playing tons of games. Even though it’s been more than 20 years ago, thinking of some of the games and especially some of the SID chiptunes gives me goosebumps. Everybody of us put up with loading times somewhere around 10 mins. (possibly more) for larger games on the datasette, simply because the games were great. What a machine the C64 was, I loved it!

In addition to having a great collection of games, you could also write and run BASIC programs on the C64. Before even knowing what BASIC and programming in general was all about, my father introduced me to LOGO (which supported turtle graphics!), which must have been my very first contact with a simple programming language. Not long after figuring out how to draw simple snow-flakes using the turtle and its “turn-left”, “move-forward”, “turn-right” commands, I got introduced to BASIC.

Even though I was not able to grasp high-level concepts like for-loops and GOSUBs at that age, I remember that writing very simple BASIC programs was a lot of fun, and I used to sneak into my parents’ bedroom when they weren’t around, just to use the C64. More often than not, I was trying to recreate simple stuff I had seen in other games, just to figure out how you could actually do something like that. Of course I had no idea how to use sprites, or what the C64’s architecture was all about, but getting the computer to do something I wanted was so enthralling.


Baby steps in programming

A few years later, my father spent an awful lot of money on our first PC – a 386 with 33MHz. We used to play all-time classics like Wing Commander, Syndicate, UFO, and Doom – and invite people to our home, in order to participate in nights full of Doom deathmatches. I still remember how much I admired people working in the games industry, and I knew that being a game developer working on such a game would be like a dream come true for me. We still used to play games on the C64, but the PC was able to do so much more, so it attracted my attention. Around that time, my older brother began programming using Turbo Pascal for MSDOS, so naturally I wanted to learn as much as possible about PC programming, bothering him with questions endlessly.

That’s when one day I got introduced to the PC demo scene.

This must have been the point which sparked my thirst for low-level programming, hardware details, working at the assembly level, and getting the most out of any hardware. I just didn’”>Crystal Dream 2 was possible on my father’s poor 386 (those demos have to be one of the best demos ever made, and will always be remembered by me). I was stoked. I wanted to know every little detail about texture mapping, 3d algorithms, and mode 13h programming. But I didn’t know where to start. Luckily, my brother was already in college, and helped me learn a lot about vectors and matrices, some assembly, and programming in general.



I soon went to college (called HTL here in Austria) myself, and slowly started to learn C/C++ in my spare time – surprisingly, we were never really taught any programming language in school (except for a bit of Pascal), which is kind of uncommon for a college specialized in engineering. At that time, I was still tinkering around with texture mapping and the likes, but never really got that far with my own game. I was always more impressed with technological stuff, technical articles I read on the internet. All that mumbo-jumbo about 3d graphics and complicated sounding stuff just made it so much more interesting. I was addicted to technology and low-level details.

After having finished college, I knew that I didn’t want to go back to engineering, because somehow that topic lost its appeal over the years. Not really knowing what and where to study, I came upon a computer science master’s program at the Vienna University of Technology, so I ended up moving to Vienna and studying Computer Graphics & Digital Image Processing there.


First payoff

In retrospective, some of the stuff I was taught at university wasn’”>Best Game of 2004″ award!

Later that year during summer, I contacted one of the guys I knew from university who was working for a local game development studio (the Austrian game development scene is very, very small), and asked whether his employer was offering internships. It turned out that this guy was no longer working for said company, so he wasn’t aware of any internships. But he told me he could maybe arrange a job interview at his current employer if I’d be interested. Well, of course I was, so I took the chance, showed them my portfolio, showed them the game we did at university, and started work the next monday. After all those years, that’s how I ended up in the games industry.


Fast forward

In the last 7 years, I’ve learned a lot about programming during my time in the industry. I’ve worked with some very talented, passionate and creative people. And even though I have been through times of crunch where I had to put in more than 100 hours a week, I can whole-heartedly recommend the industry as a great place to work with like-minded people. Joining the games industry has been one of the best decisions in my life, and it has always been a dream of mine.


Hacking the App Stores

Original Author: Tyler York

Hey everyone,

It’s my first post here on AltDevBlogADay and I wanted to briefly introduce myself. My name is Betable is a pretty cool startup: we make it so game developers can legally add real-money gambling to their video games just by integrating with our API. Yes, it is legal for any developer to use, including US developers, but that’s a topic for another post.

One of the things that I picked up from my work with iPhone app developers and Lookout is how the app stores differ from each other and how to best use the small marketing assets you have to get the most out of your app’s listing. I have more experience working with the Android Market, but I’ll also include some insights that will be helpful for both stores. Let’s get started, shall we?

The Key to the Android Market is Search

As I learned from Charles Hudson at the Android-i-fied event back in August, Android users primarily discover apps and games through search “because it is Google.” That was a ‘duh!’ moment for me. The way that an app marketplace is set up drives behavior, and at the top of your screen where ever you go on the Android Market, you can find the Search bar. Therefore, the key to unlocking the Android Market is by optimizing for Search just like you would for a website. Unfortunately, with limited marketing copy and no linking, you can’t use your father’s SEO strategy. Instead, take the following steps to improve your Android Market ranking in search results:
  1. Find out what key words are relevant to your game that the Android Market users search for. Often times, they are key words that people search for to find your game, which you can track with Google Analytics. Alternatively, you can make educated guesses based on key phrases appearing frequently in top-ranked apps in your category.
  2. Add those keywords to your game listing as many times as possible, preferably in the title and many times in the description. This tactic may seem silly, but it works extremely well. The Android Market’s search algorithm is surprisingly basic when compared to Google’s homepage algorithm, and frequency does improve your results. Do your best to fit it in the conversation naturally, but also remember to add them at the bottom of your game description in the Keywords section. Just take a look at Lookout’s description to see this strategy in action.
  3. Take steps to improve your click-to-download rate with good marketing copy in the game description, while fitting in those keywords.
  4. Take steps to improve your retention rate, which we found had a strong correlation to our Market ranking. An easy way to do this is to simply manage expectations with your description and not over-promise or cater to the wrong audience.

Also, since the Android Market still allows incentivized installs, there’s no harm in buying your first 1,000 users to get that seed group of users and accelerate your growth. This helps tremendously with improving your ranking for a brand new game and getting you that valuable information you need to improve your marketing.

Optimize Your Icon

Now I’m going to transition into some tips that are applicable to all app stores, not just the Android Market. The first and most important thing that you can optimize with your marketing is your Icon. Your icon is your single most visible and memorable aspect of your game’s brand in the marketplace and on your users’ phones. Back when software came in boxes and was sold on store shelves, you had two sides of a large box to sell your product, and maybe even a flap that folded out. Now, you have a 80×80 PNG file that needs to convey your brand and compel a user to try your game in about half a second as they flick by. How do you make sure that your icon does all this and doesn’t get lost in the vast sea of the major app stores?

If you don’t have the artistic skill to make a great icon (which is fine, not many do), then hire someone who does. Remember all of those reasons I just mentioned about why the icon is so important? Those same reasons make the few hundred dollars you spend on a professionally designed icon completely worth it. That said, you still need to give your designer some guidance and you should definitely maintain control over the creative vision of your game’s brand. Let me give you a few tips that can make or break your game’s all-important icon.

  1. Stand out from the pack. This sounds easy and straightforward, but it’s actually one of the most difficult parts of making a new icon. Look at what colors, styles and fonts that other games in your category are using, and then pick something totally different. You want your game to stand out from your surroundings and get the user’s attention.
  2. Decide on your brand. Whether its grungy or glittery, bright or dark, your branding is the personality of your game and the thing that users remember best. Your icon is the first time that users will interact with your brand, so having an icon that represents it is key.
  3. Keep it simple. An icon that is too busy visually will not as much attract attention or convey your brand as effectively as a simple icon. Instead, focus on a single object that defines your game, whether it be the main character of your game, a funny still involving the characters in action, a symbolic weapon/piece of equipment, or your game’s logo. The best games have simple representations of their brands that are unique and easy to recognize.
  4. Be consistent. You want to establish your brand in the marketplace and on user’s phones, and by redesigning it you essentially hit the reset button on that process. That said, you can certainly update your icon, but you want to make small, incremental changes over time and not surprise them with a brand new logo.
Some examples of games with great icons include Words With Friends (consistent).

Getting Featured

The holy grail of any app store is to get Featured, which can drive tens of thousands of users to your game in a single day. Unfortunately, the process for getting Featured is a black box for the majority of developers. Building a great app helps, but building a great relationship with the app store’s manager is a must if you’re trying to get your app Featured. I can tell you from my experience at Lookoutthat the key to consistent placement on the Android Market Featured section of various carriers was the relationships we built to support the great app that our engineers had created.When aiming to get Featured, it’s easier if your app is new to the app store, so submit your app early and submit often. The goal isn’t necessarily to get Featured the first time, but to build a relationship with the app store representative that you end up talking to. Even if you get rejected, you can start a conversation around the following topics:
  • What do you look for in a Featured app?
  • What could I change about my app that would make it more valuable to users?
  • Could I get my fans to request that you Feature my app?
  • What can I change about my Featured app submission to increase its chances of success?

Not only does the ensuing conversation give you valuable advice, it also gives you a rapport with the representative so that next time you submit, they will recognize you and the improvements you’ve made in response to their advice. This makes it much more likely that they will accept your app for the Featured list, especially if you submit directly to the rep via email instead of through the submission process.

That said, the tricky part of this is definitely getting an email back at all from the representative that contacts you. While I joined Lookout after a lot of the initial conversations, I did initiate a couple of new ones and I think there’s a couple tips I can give you to that end:

  1. Have an app that is new, interesting and polished, and they will make sure they find time for you (this is the “make a great app and you’ll get featured!” tip). That said, don’t wait forever to send it to them either: you can’t learn if you never submit it.
  2. Keep the email VERY concise. Pick one of the above questions and ask it. No fluff, no schmoozing, and no begging! You know that you aren’t getting featured, but want to learn from the experience and improve your app for your next submission.
  3. Be persistent. This is a tip I picked up from Dean Takahashi at the “Meet the App Press” event in July. Even if you ping them and they don’t respond, they remember you, and the next time they see your name next to an email, they might be more inclined to take a look.

Wrapping Up

I hope this helped everyone, especially solo developers & small teams that don’t have a ton of bandwidth for marketing. Marketing isn’t easy, but with an open mind and a little elbow grease, you’ll find that it’s a lot easier than it looks.

If you have feedback (which I hope you do), send me an email at @betable.