Seems this past week I’ve been slammed with a ton of stuff. Had to take a breather, step back and get a bit more organized to gain some perspective. Tax season is in full swing, so that’s always biting at my ankles as this is my first year filing as a self-employed tax payer. Tilt to Live Viva la Coop is close to being live on the app store (hopefully), and HD will be followed up shortly after. In the meantime, I’m tasked with starting a brand new project, and it’s an exciting one indeed. The biggest hurdle so far is trying to mitigate the second-system effect. With all the problems encountered developing Tilt to Live, I want to try to get rid as many of them as possible the 2nd go around. Yet, trying to eliminate all of them doesn’t seem like a wise choice because even though there were a few ‘snags’ in developing TTL, they weren’t big enough problems that would justify going out of my way writing custom tools, scripts, or whatever to relieve them.

One of the bigger problems (or a possible non-problem depending on where we go in the future) was the realization of how locked into the app store and iOS system we were. Tilt to Live and it’s HD counterpart were pretty much written in pure Objective-C. Very little constructs of C or C++ were used. There were only a handful of structs for networking, and vector functions, but that was about it. When faced with the decision of wanting to try out the game on different platforms, it was a non-starter as all the gameplay code would have to be rewritten in C or C++ (of course Android is a beast on it’s own using Java). It wasn’t a problem at the time because we were focused on simply trying to succeed in the quickest and easiest way possible. But looking forward, I’d like to have the option to go to another platform without the pain of starting from scratch.

GDC is looming around the corner, and it’s really exciting to think after so many years of following GDC in the news I’ll finally be going to this awesome event not as just a spectator, but as a game developer. Exciting times indeed.

Wow, last week was an intense week, focusing on pretty much Tilt to Live exclusively. Took a nice break/road trip up to North Carolina to do a bit of snowboarding to cap off the week. Conditions weren’t that great, but it was close, cheap, and still fun versus going back out to Colorado. Back today somewhat recharged and ready to go. Haven’t had time to work in Blitzmax at all last week, I hope that’ll change after this week as well.

I’m planning on doing a redesign of my blog as well. I like the theme, but the really thin layout and bad font choice hurts readability. When the RSS feed is more pleasant to read there is something wrong. I may simply just widen the template, and pick a more readable font. Hopefully after that it’ll be more functional.

I haven’t done anything concrete yet, but I know for our next game we’re going to look into using Google App Engine for some of the functionality, as well as Push Notifications.  Ken Carpenter over at Mind Juice had a really nice write up about it. it’s pretty exciting to see how large scale technologies are becoming affordable for even 1 or 2 man shops. Trying to launch a game with a potentially huge influx of users and data use to be only in the realm of studios with large amounts of funding.

The news that Garage Games is back and is going to continue to sell their Torque line of game development tools is great to hear. I used TorqueX to develop Gunstyle on XNA and it was a blast. Torque2D seems really appealing to look into for development on the PC/Mac platform. iTorque2D looks neat, but I’ve heard performance had been an issue for it.

2D engines are a weird beast because their on the edge of that line where the trade off between rolling your own or just buying a package seems very even. I know from experience in TorqueX, the fidelity of control you get content-wise is amazing, but a lot of low level details tend to be out of your grasp without a large investment in modding the source itself. I recall having to write my own map editor, despite the awesome 2D editor in TorqueX, simply because I didn’t have access to the tools to create the physical geometry needed by our game. So creating a level ended up being a two step process of having a level designed and laid out with all art assets and trinkets in the Torque editor, but then loading that into a bare-bones homemade editor to add in the physical geometry for the levels. And this all arose out of a really basic limitation of the T2D editor not allowing the creation of concave polygons with their line editor tool. Surprisingly looking at Torque2D for Mac/PC this doesn’t seem to be the case.

It’s very true that these engines will get you 90% or even 99% of the way there, but then there’s this one crucial element that typically is what is unique about your game or game’s data that the engine simply has no way of accomodating. Looking back, I think it was a nice motivating factor that getting the game setup on just pure TorqueX and having it look great with minimal effort was awesome. The rest of the development cycle was spent bending the engine to our will.

January started off with quite the busy schedule and it hasn’t let up yet. So much to do so little time! Viva la Turret has turned out to be a critical success and people are enjoying it so that’s great. Coming right off the heels of that I wanted to update Tilt to Live HD with Game Center support. It came, and we screwed up (again) :[. There’s a bug with the scoring that cropped up after I added a last minute fix to a less serious bug involving double vortexes. We do have a thorough test plan for our releases, but given the small amount of features/fixes in this one we didn’t exercise all of them. Hah, the code goblins struck again.

What’s funny is there have been moments throughout the year when I look around and realize how freaking awesome things are going. I feel like we’re on a roll and it’s like racking up a crazy combo in some shooting game. Release done and shipped. BAM. Release done and shipped. BAM. ANOTHER Release done and shipped. BAM! That is usually the very moment a dreadful thing occurs. Usually involving HD. And it’s already live and tanking our reviews. It certainly takes the wind out of my sails.

No developer wants to be seen as someone who writes ‘buggy software’, so it’s something I’m striving to improve. So what am I working on as of late?

One Man Left

We’ve got an update in for Tilt to Live HD submitted this past Friday to fix the scoring bugs. We’re also wrapping up testing on Viva la Turret HD and it’s proven to be pretty fun, yet still feel slightly different compare to the iPhone counterpart. Also got some other stuff in the pipeline for Tilt to Live that may or may not come to fruition.

Blitzmax

So I decided this year to make more time to code outside the daily projects of OML. Every few nights I’ll get back into the swing of Blitzmax and started poking around with a game framework I had written for it years ago. It was written when I was in college and it shows. It’s very ‘academic’ feeling when using it. I was pleasantly surprised at how flexible it was, but there’s a lot of tedious code to write to get a ‘blank project’ up and running. I guess back then I had oodles of time, haha (not). I also got it compiling on OS X, so having two clients on different OSes talk to a windows server with minimal fuss was a neat thing to see :).

I think my next steps will be to rip out the WxWidgets integration I did back then, using Brucey’s module. I had originally intended to code in an integrated editor with the game Unreal Engine-style, but recently decided against it for simplicity’s sake. I’m just going to fork the current codebase and create a dedicated editor out of it while having a ‘game’ branch that is hopefully more lean and mean.

Misc Dev

I haven’t begun any actually coding yet, but I’ve been toying with the idea of creating a 2D editor using Cocoa/Objective-C and OpenGL. I’m currently working on some preliminary stuff for “Game 2”, and intend on trying to keep it mostly C++. With that said, writing an editor on the Mac using Objective-C would give me the bonus of re-using a lot of the game code in it for handling things like rendering, input, etc. It wouldn’t be difficult but I guess it comes down to time. Cocoa seems like a really nice UI library, but I’ll admit I’ve never done much of anything in UIKit beyond hooking up an OpenGL view to the window and going back to XCode, haha.

Where as, if I were to just leverage the code I had written in Blitzmax with WxWidgets I can kind of hit the ground running in creating editing tools for Game 2, as well as making the tools cross platform. The drawback being I’m using 2 separate code bases and 2 separate languages. Although, I think I’m just blowing that out of proportion since a Cocoa editor would most likely be a fork anyway. It would certainly provide me the freedom of just messing with the internal model of how objects are structured since I wouldn’t be concerned about game code. When doing editors in the past I found trying to get relevant data out of game objects to manipulate in an editor went against a lot of the encapsulation and designs in place for the actual game. So this may be the better long term route.

Cocoa? Blitzmax? Jury is still out on that one. I also don’t think I can make a fair judgement until I actually try coding some basic tool using Cocoa UI on the Mac. And why Blitzmax? Well, it’s just that I happened to code in it for years so I’m using what I know. And it’s nice. Too bad there isn’t a good native mac editor for it. I use Blide (running in a Windows XP VM) for Blitzmax coding.

2010 was an amazing year for me. While a lot was accomplished, there was a lot left to be accomplished.

  • June 18th, 2010 was the day I fulfilled my dream of becoming a full time indie game developer.
  • Moved back down south from DC to cut living expenses to help my chances at keeping this up as well as be within shouting distance of Adam, my partner in crime.
  • Tilt to Live became a crazy and unexpected success. It was far from Angry Birds or Doodle Jump in terms of income, but the game keeps selling at a steady rate.
  • Released an HD version of Tilt to Live on the iPad. We had a shaky launch, but the game’s reviews have recovered since.
  • Released 3 game modes for Tilt to Live over the course of the year in updates to keep the game in the limelight.
  • Released 1 new mode and weapon during the holidays as an IAP. Lots of backlash over twitter/facebook and on youtube, but our sales numbers speak a different story.

Those were some of the successes of the year. Some of the shortcomings:

  • Gained a lot of weight since I’ve moved back down south :[. It’s my fault, but I like to blame southern cooking and the non-pedestrian friendly nature of the area.
  • Due to the success of Tilt to Live kind of got caught in a treadmill of constantly updating the game. The very thing I try to avoid in game design.
  • Wanted to release a brand new game during that year after Tilt to Live, but never got around to it.
  • Haven’t kept up on my reading as much as I would like. Both for educational purposes and for entertainment.

So what are a few of the lessons learned from 2010?

On IAP

From releasing Tilt to Live HD to releasing our Viva la Turret DLC on the iPhone we’ve gotten a pretty interesting view of how people respond to IAP. For HD, it was rather welcomed since the core game was free and if people truly liked it, they’d pay for the full version. The purchase experience we setup in HD thanks to IAP is rather seamless and very quick. The negative feedback was very minimal and mostly mis-informed users who didn’t bother reading anything beyond the price tag in the app store to realize what they were really getting. I really like this model because if you have a truly compelling game, it can sell itself once you’ve done the marketing to get it on people’s devices. Usually with marketing you’re trying to get people to shell out money on a vague promise that the game is great. The traditional way worked for Tilt to Live, and made sense at the time considering it was only the classic game mode then. HD has made no where near the amount that Tilt to Live has, but I attribute that mostly to the differences in market sizes, marketing effort, and time on the app store.

With DLC for a paid app we’ve learned we have to be very mindful on how we communicate it. While we mentioned the new weapon and mode would be an IAP in a blog post we only linked to it from twitter and Facebook instead of putting the price in the short posts themselves. We didn’t omit this intentionally but soon learned how important this little bit of info is. Being called ‘scammers’ and ‘liars’ isn’t fun to wake up to.  Be sure that if you’re doing something against expectation that users are aware of it no matter where they get their info from. Do it in twitter, app update descriptions, Facebook posts, anything. Regardless, we kept on trucking and defended our game and position. It was a relief to find that even though there was a group of displeased customers, there was an even much larger group of very happy ones playing Viva la Turret :). Phew.

Like they always say, you can’t please everyone.

So was the expectation of free content valid in Tilt to Live? Well, looking back at the numbers:

  • Tilt to Live has over 550,000 downloads. That’s a lot! But wait…
  • Over 80% of customers who got Tilt to Live got it for free. This isn’t accounting for piracy numbers; this is just the week we gave out Tilt to Live for free.
  • Following that promotion Tilt to Live got a lot of content added as free updates.

It’s understandable to think Tilt to Live would be free forever and always. But hopefully people don’t mistake this as “the end of free content from OML” as that’s definitely not the case, we would just like to still be around in 2012. I have no ambitions past 2012 since it’s the end of the world and all.

On Updates vs New Games

So I had hoped to have a 2nd game on the app store before 2010 was out. When we finished Tilt to Live HD there was about 2-3 months left in the year. Looking at all our game ideas, we simply couldn’t come up with one that would have enough spit and polish ready for the holidays that we’d be comfortable releasing. The app store has changed the typical development cycle of a game considerably. Before, a developer would release a game, patch a few things, and wipe his or her hands clean of it. This still seems to be the status quo on the console market.

On the app store, even if the game has no multiplayer service, there are many that are developed and treated as such. More levels in Angry Birds a year later? Doodle Jump STILL getting new content after being out for how long? Pocket God? POCKET GOD?! 😛 The closest thing I can think of that resembles this model that isn’t an MMO is Valve’s TF2. It’s a really cool business model both for gamers who love to see their favorite games continue to be supported, and for appeasing the ‘perfectionist’ inside the developer to make all those features that got cut go back on the list again. The question in my mind is if it’s sustainable.  Given what Tilt to Live was released as, we could have easily made a ‘Tilt to Live 2’ with all the additional modes and weapons we added, but instead decided to improve the original game. I still don’t know whether one is preferable over the other, because adding to the original game is MUCH cheaper than starting a brand new game (dev costs, marketing costs, ads, etc) but you don’t expand your user base as quickly. We’re definitely releasing a new game this year, but it’s a bit unnerving to think that the expectation is such that ‘release day’ is only the beginning. But maybe I’m crazy and this is a self-imposed expectation…

On Reaching Our Audience

Despite our efforts, the most effective way for us thus far to communicate directly with our customers has been through the app store update text.Twitter and Facebook pale in comparison to the amount of reach that little update text has. I can tweet and post on Facebook until I’m blue in the face, but I still wouldn’t reach that customer that plays our game on a daily basis but doesn’t know what “the twitter” is or doesn’t follow us on Facebook. Going forward, implementing a news feed into the app itself I think is paramount in getting any important info (like our In-App Purchase DLC) out to our customers.

Goals for 2011

So what do I have to look forward to in 2011? Lots of stuff planned, and hopefully lots of pleasant unexpected stuff will happen too :).

  • Release a kick ass game #2. Yea I don’t count Tilt to Live HD as #2, more like game #1.5.
  • Hit 1 million downloads of all our apps combined this year (free and paid). We’ve got a looong way to go, but I think we can do it.
  • Get BACK onto my regular work out schedule. Since moving I haven’t been able to get into a routine again.
  • Become a more efficient developer. I’ve been improving all the while developing Tilt to Live, but when starting dev for game #2 I’d really like to take all that I’ve learned and be able to get things done quicker and with less bugs (isn’t that always the wish?). Guess this will be measured by the amount of pain I feel whenever I need to change a piece of code in 2011.
  • Get back into coding for the sake of coding. Being so focused on ‘the project’ has left a lot of my side projects by the way-side. I’d like to start exploring them again. That Greplin coding challenge was a fun diversion to think on problems I don’t normally come across while developing games.

Here’s to an awesome 2011!

I’m currently messing around with bluetooth multiplayer and it’s been a blast so far. The only downside is the much longer turn-around cycles for developing the network code to test on two devices. On the PC it was a bit cumbersome as well, but I could always just run 2 instances side by side locally. I guess if I had spent a little extra time to allow for Wi-fi AND bluetooth I could test with one device and 1 simulator, but it’s still always going to be slower than single device testing.

I had made a post about this a little while ago with running from a single project in XCode. Brian Stormont mentioned I could have multiple copies of the project all referencing the same source files. I finally gave that a try and it does make things a bit easier and allows for simultaneous debugging, but speed of deployment only seems a tad faster, if at all. When compiling from both projects it appears the 2nd project to be compiled is significantly slower and/or waits until the first one is finished. I guess that’s the problem with running a single instance of XCode with multiple projects.

Also if you try to compile at the same time while targeting 2 different devices but with the same configuration you’ll run into a lot of build errors. Creating a new configuration (akin to Debug-2 or something similar) allows the copied project to output it’s files separately without having any contention of the original project for file handles and such.

Thanks to all for their support on this blog and support for Tilt to Live! It’s been an awesome year and lots of exciting stuff coming up as we roll into 2011. You probably won’t see another post here until early January, so have a happy holiday!

(image courtesy of rooter)

About to head out for a week into the rockies for some fun snowboarding :D. So I won’t be able to keep up with e-mail, twitter, or the blog for the next week and I’m currently in a rush to pack. I didn’t want to just leave for a week without explanation though.

In any case, I still use iSimulate for testing Tilt to Live on the simulator. Having already written about the great benefits of using something like iSimulate I won’t go into the details again. Recently, I was trying to create a trailer for our upcoming ‘Viva La Turret’ DLC for Tilt to Live. I was using ScreenFlow along with iSimulate to capture video and iSimulate was performing extremely poorly. Knowing iSimulate uses Wi-fi to transmite the tilt data I turned off all wi-fi devices in my apartment thinking there was some sort of interference. Then I looked at my phone and realized bluetooth was enabled. Turning it off solved the problem. Googling for bluetooth and wifi intereference turns up a lot of similar cases, I just haven’t experienced it in development yet. I figured I’d pass that along.

‘Til next week!

Wow. I think I’m still digesting thanksgiving dinner. Anyway, we just recently announced our newest game mode for Tilt to Live and it’s a doozy. In the midst of getting it all tested and ready to submit to Apple I had a bug lurking about the loading screen code. At seemingly random times the game would crash with an EXEC_BAD_ACCESS error somewhere in my loading assets functions usually stopping at CGContextDrawImage. The fact that I couldn’t replicate it with any sort of consistency really concerned me.

So what did I do? I put it off. hah! Through some beta testing our users submitted a few crash reports and after the pain of getting them to symbolicate (I can never get it to work on the first try) I wasn’t left with much to go off of. Then I noticed a peculiar thing in each of the different crash reports:

  • Thread 7 crashed
  • Thread 8 crashed
  • Thread 9 crashed

Wait what? Why am I crashing in different threads each…oh my. Apparently I haven’t learned my lesson. I wrote that post over a year ago mind you. I eventually went from libpng back to using CGImage loading for performance reasons. Most of my graphics were in texture atlases, but the new ones in turret’s syndrome were not. As a result they were lazy loaded in a background thread when I was pooling objects. The result? 95% of the time it worked without a hitch. Every now and then I would crash while loading some random asset from that method. *Face palm*.

Since I wrote that post I never really looked into any more info as to whether CoreGraphics or the methods usually used in UIImage were thread safe. In any case, it appears it’s not. For anyone that does want some sort of flexibility in loading assets in the background I’ve uploaded the small PNG loader code I wrote and used for a while in Tilt to Live. It’s a bit slower than using CoreGraphics libraries, but is thread safe. The main function of interest is LoadImagePNG(const char *path). It returns a struct called PNGImage that has all the data you should need to use the image. The function loads the image data into OpenGL so the struct contains the textureID if you need it. Pretty basic, and in order to get the same behavior on the iPhone I wrote a small transform that the loader uses to pre-multiply the alpha of the png’s.

The zip contains all the files needed to compile the loader. Just drop the files in a project and you should be good to go. If you’re wanting a more ‘official’ version, just download the latest libpng library to get the latest png.h and pngconf.h files. Enjoy!

Download: opengl-pngloader.zip

So I’m currently playing around with some multiplayer prototypes on the iphone, and when it came down to testing stuff I ran into a problem: You can’t deploy to multiple devices at the same time. Yea it’s not exactly a ‘problem’ per say, but it’s certainly tedious doing a ‘build and run’ on the devices you want to test. So much so that I dropped 3 player support in a prototype just to save time.

I did run across this blog post by Jonathon George on the topic. You can plug in all your devices at once and just switch the ‘active executable’ in the drop down to deploy to each device. Not ideal, but works for the time being. I figured there may be a way to run multiple instances of XCode projects but I expect that gets into all sorts of messy configuration issues so I haven’t spent the time trying to do it. Wonder if anyone out there developing multiplayer games has gotten a elegant solution to this?

After responding to Noel’s post on the size of games I soon learned it was a wide effort by developers to post their thoughts on this topic so I figured I’d throw my hat into the ring. I’ve had this topic in my head for a very long time and it’s been frustrating hearing friends’ and reviewers’ opinions on games. Other developers have covered this pretty well already so not sure what else I can contribute beyond just a rant :P.

I’m curious where this metric came from in the first place. I would imagine it had good intentions when it was first uttered, but somehow got mutilated, deformed, and abused as it seeped into the vernacular of reviewers and gamers spreading through genres where this metric becomes utterly useless. A common argument I hear is “$X dollars is a lot to spend on a short game”. I tried applying this metric to my own gaming experiences to see if I could glean any sense of rationality from it.

  • Tribes, Tribes 2, Tribes: Vengeance – All combined I spent about 80-100 dollars total for all 3 games. How long did I play those games? Years. Something on the course of 5-6 years. In an economical sense, these games were practically free based on the “Length of time” I spent with them. Those were my younger days when I probably should have been spending more time outside, but hey, I wouldn’t trade those memories for anything now.
  • Starcraft/Starcraft 2 – Another one I spent years playing. When SC2 was announced along with the collectors edition I didn’t have to think twice about paying $100 dollars. The game hasn’t even been out for very long and in terms of time spent, I’ve probably reduced the hourly “rate” to pennies on SC2 alone.
  • Battlefield 2, Battlefield 2142 – Played these religiously over the course of a year combined.
  • Call of Duty 1,2, 4, MW2 – 4 $60 dollar games. Again, played them enough to where it was practically “free”.

If you haven’t noticed, all the games that I spent extraordinary amounts of time playing are almost exclusively multiplayer. I’m a sucker for multiplayer games. When it comes to getting these games, price isn’t a factor in deciding whether I’ll play them or not. The fact that they are social/multiplayer games the biggest influence is: who out of my friends and online buddies are going to be playing it? Length never even came into the conversation. The quality of the shared experiences was what kept me playing long past the “expiration date”.

Ok, ok, so ‘length’ in a multiplayer game is almost a moot point. But it’s also a crutch many games hang themselves on. In order to pad out the “length” of a game, many games add a multiplayer aspect. Some are very welcomed and exhibit great design, while others seem like an after-thought for a back-of-the-box bullet point. So you could possibly make the argument that not only is length some sort of metric used by the audience, but some studios/developers are feeling the pressure as well.

How about single player games? Let us look at the evidence:

Call of Duty 4: Modern Warfare Campaign

I played through this in one sitting. I remember my first playthrough my jaw was on the floor during some of the set pieces. They set out to create a balls-to-the-walls action game and they did it. Reviewers played it and what did they say? They couldn’t shut up about the “length”. And despite there being no “standard” for length they kept saying an ‘average’ shooter’s single player tends to be longer. Time and time again the ‘negative’ on CoD4 was that the campaign was short. The news of a ‘short’ campaign for such a large title made headlines on many big sites.

At the end of the campaign I did have a thought about length: I was sad this awesome experience was coming to an end. But the compactness of it I think was its biggest strength! CoD4’s design philoposhy was to create a ‘hyper-realistic’ experience that gets you as close (if not closer) to  a big budget action movie as it could. If it was longer, the player becomes fatigued from the relentless action. A longer campaign would make them walk away not remembering the “whole” experience, just bits and pieces of it out of context. The game’s length was also another plus regarding the target audience. This was a mature game, namely for an adult age group. Most adults don’t have 40+ hours to dive into a solo game. So I applaud them for that. Why make something that the vast majority of your demographic won’t even see? The single player as an ‘experience’ was worth the price of admission alone. Not on length, but quality. But it seems some use those two words interchangeably.

Limbo

This little gem of a game from an awesome indie studio was amazing from start to finish. I’m not going to go on about it again as 2D Boy and others covered it pretty thoroughly. It took me 4-5 hours to beat. For those still trying to “rationalize” length, stop it. This game is an experience, not a damn feature film (which by the way, no one criticizes unless the film is too long it seems).

Mirror’s Edge

This game is where my frustration hit a boiling point. What’s amusing is the media didn’t really know how to approach a game that was genuinely pushing boundaries in game mechanics and at times it seemed they just defaulted to “it’s short”. Same goes for Portal. What does it say about the medium if people’s only complaint is “it’s too short”? I actually had a bit of an argument with a colleague who was stoked to buy the game, but once he read the positive reviews he decided against it because they said the campaign was short. OMGKDJFLA:JDWIO:JI#@R)@RJFDSFDL. Sorry. Got all angry again.

This time it seemed more perpetuated by the audience than the media. To the media’s credit, they focused on the game’s novelty and fresh gameplay mechanics, but still in passing mentioned how short it was. Just looking at this comment thread of all the ones who gave up the chance to try a truly unique game because it was “short” was quite saddening. I spent at least 20 hours playing that game. Not 3-4 as the single player was measured as. Why? Because it wasn’t even ABOUT the single player. This game was raw mechanics, freedom of movement, and anyone that took the time to dabble in the Time trials and the DLC knew it. They made the awesome concept of Quake Trick jumping accessible to a wider audience. Sadly due to the conventions of modern video games, anything not labeled ‘story’, ‘campaign’, or ‘single player’ is considered a side-offering and should not be put up for consideration in the ‘total length’ metric. It’s as if these same people didn’t play Geometry Wars. That game is a single damn screen, and it barely had any complaints about “length”.

At the End of the Day…

I sometimes feel games that get judged on length are treated by a different standard. Take a game that involves a system or a pure mechanic, like The Sims. No story. No levels. Just pure play. Something you enter and leave as you please. Another example: Geometry Wars. The whole experience is contained within a few short minutes. It makes no big claims of story or progression. Did length ever come up in the conversation? No, because length is ‘seemingly infinite’ and as a result not part of the discussion. Give a game a finite story, or a finite set of levels and regardless of the mechanics and the depth of the gameplay it seems “length” is suddenly a talking point again. Weird huh? If length is the only thing one can discuss about the merits of a game, then is the game not deep enough or are we not engaging it enough?

If you got this far into my rant then length is apparently not an issue for you, so go on ahead and read other developers’ take on it:

Markus Nigrin wrote a great follow-up to my previous post on managing one’s burn rate when going independent. His post touches on some really important information that I completely left out of mine, namely, being educated about investing and not ignoring it. I’m guilty of this as well, but only since “cutting the chord” have I become much more concerned about my lack of education about investing, and it’s something I’m currently working to improve.

It’s a great read, and some good book recommendations from him in that post. I would add to that “The Black Swan: The Impact of the Highly Improbable” as another book to read for those that are in a very “unpredictable” and hit-driven industry such as games, books, etc. It echoed a lot of sentiments I had felt at the time, but didn’t know how to articulate it and the book does a good job of explaining that.