So, I just sent out my “hey everyone, come get a refund” email to all the people who purchased the Stealth Target beta. There are a number of pretty high-profile indie games that have built an entire business upon being a paid beta. Minecraft, Wolfire’s Overgrowth, Data Realm’s Cortex Command are a few that come to mind.

Here’s some analysis on the subject, and why it didn’t work for Stealth Target .. and at the same time, the factors I think that would be important to having a successful paid-beta project.

• Commitment to a larger vision. In the case of Stealth Target, I had a larger vision, but I eventually realized it was too grand for me to realize.  I’m more of a small-scale game kind of guy at this point.  Perhaps later in my game development career I’ll be doing larger projects, but right now, a “Galcon-sized” game is about as large as I can manage.  I think paid-beta games need to be larger to justify the whole “user-buy in to help fund an epic game” concept.
• Commitment to regular updates. I’m only one dev, and when I take a month to work on Galcon updates, and then take another month to take a break, suddenly the beta users haven’t heard a peep from me about the game in 3 months.  Pretty weak “paid beta”.  If I had a team and I had someone always working on the beta so it kept living despite my other obligations / plans, it might have gone better.
• Building a development team. Yeah, I just touched on that, but it really does make sense.  I could have a team, but my lifestyle doesn’t allow for it at the moment.  My hours are too random and my work schedule too unpredictable.  To have a team you have to have some consistency in your life, otherwise (I’m pretty sure) your team-members will get pretty tired of you.  I think having a team would help deliver the quantity and quality of content and updates to make a paid beta make sense.
• You can’t change your mind and be crazy. I still plan on finishing Stealth Target, however, I’m no longer planning on doing a desktop release of the game.  The paid beta was for a desktop version of the game.  So changing to a iOS-only plan really isn’t possible.  The only way to cleanly resolve this was to terminate the entire beta and issue refunds.  Really, for a paid-beta to make sense, the users have to have something they can depend on, and changing platforms mid-stream is just asking too much.

Anyway, to wrap it all up, here’s the email I sent out to folks who already bought the game today:

Hi,

Turns out the business model of doing a pre-beta-sale really doesn’t make sense for me.  I’m more of a “do what I feel like” kind of guy, and committing to making some sort of super-great-game in some kind of pre-beta-sale promise just isn’t something I can really do.  I think in the case of “Stealth Target” I bit off way more than I can chew.

I’m hoping to finish Stealth Target this year, but I’m probably only going to release it to mobile platforms, so I don’t even think I’m going to be launching a desktop version.

Either way .. I’m offering refunds to anyone who wants one!  Just reply to this email and say so.

Thanks for coping with a crazy indie-dev 🙂  Your support is greatly appreciated and I hope I can churn out some cool games that you’ll enjoy in 2011!

Cheers!
-Phil

P.S. Also, thanks for all the feedback you have given me so far on Stealth Target.  I’ve been taking notes on just about everything! You’ve been a huge help!

And, who knows what the future will hold for Stealth Target.  If the mobile version comes out feeling really good, I might try and release it for the desktop.  But the important thing for me is to know that I’m not obligated to produce a “desktop-sized” title when I’m really making a “mobile-sized” game.  I’ve got a lot of things I want to do this year, and I want to do them in the order that I want them to.  A paid-beta project would have “cramped my style” so to speak, and I don’t want to subject my users to a shoddy paid-beta experience.

Thanks!
-Phil

I’ve posted a new build of the game, so anyone who has bought it already can upgrade. It fixes almost all the bugs that have been reported. I sent out an email to the beta-purchasers with these questions:

– What do you like about the game?

– What do you dislike about the game?

– What could be improved about the game?

I hope those questions inspire some interesting feedback.

-Phil

At this point, I’m kind of in grind mode. I churned through a bunch of bugs in the past 48 hours. And did a bunch of user-interface changes. The game is getting more perfect. Here’s a shot of the bugs and changes I’ve made. I’m getting pretty happy with how things are feeling. I’ll thank the beta testers for all their feedback once again, and Tim (my brother-in-law, who does most of my music) for providing a number of pieces of UI feedback which really helped.

The most visually interesting change is that now I tally up scores in sort of a jackpot style, like in most games. The shot doesn’t do the effect justice, but when the “Win” screen appears, each of the numbers is reduced to 0 while the score increases to the total score for that level. It’s pretty cool. This was Nan’s suggestion, and it seemed to be a pretty fun one! Makes beating a level feel that much more rewarding.

-Phil

So, Nan did a test run of the iPad version of Stealth Target today. There’s always a handful of platform issues to deal with in porting!

Like, on the iPad I don’t need a Quit button!

Or, I need to use some ObjectiveC code to open a web page. Thanks to OS 4.x I won’t need to figure out how to embed web browsing in the game due to multi-tasking support. I haven’t added that to the game yet, but I’ll do that before release. (Which reminds me to add that to my tracker so I don’t forget!)

As always, I need to modify the interface a bit more for touch. The mouse and touch interfaces are really quite different, so I always want to make the experience work “the best” given the interface being used.

A new challenge for me is adding pinch to grow/zoom support to the game. In the desktop version the mouse-wheel controls this. To implement this for a touch interface, I need to track where the center of all touch events is, so when a motion happens I can see if that motion is going towards or away from the center. This is a bit tricky, since finding where the center of a multi-touch event keeps changing as motion keeps happening.

I found that technique didn’t work. What did work was passing along with the event a distance value between that touch and each other touch. This way, no matter how many touches are down, a reasonable zoom value will be passed.

-Phil

Many people were confused by my announcement 10 days ago. So I’m going to try and explain it a bit better!

Stealth Target is not a finished game. If you look at the screenshots and video I’ve posted, almost none of the graphics you see are final, they are all free graphics or stuff I hobbled together quickly so as to get the game basically working. What you’re looking at is not what I will be selling to the general public when the game is finished.

I am a solo indie game developer. That means there’s just me doing the bulk of this project. My wife Nan helps with the testing and some of the ideas. And I contract out the art and music since I’m only so-so at those things myself. I don’t have a team of 50 Q&A guys in my basement who test my game for me non-stop. That’s what the beta is for, it’s a way for me to get feedback from the users who are interested in helping me out!

I did, however, make a notable mistake in my beta release! I priced it at $9.99 (my planned full-price.) This was a goof-up on my part, since I really want to thank people who are taking a chance and trying out my games before they are done. I’ve changed this to $4.99 so people who pre-order get the special price. (The few brave users who went and paid the full $9.99 for the game last week I gave full refunds to, so they got the game for free!) And, yes, whoever buys the game at this pre-order price will receive the full desktop game when it is finished. (I’m also planning on releasing it for the iPad. A pre-order will not count towards that.)

Anyway, I want to give a huge thanks to the people who have played the game already and given me feedback. I’ve just posted a new build of the game with a bunch of new features and fixes based on their feedback. You can check my blog to see what all changes I’ve made and how the development has proceeded.

To the people who wondered “Where is the demo??!” Don’t worry, I haven’t built it yet, but I think I’ll be making one available sometime soon. I’ll send out a mailing when I do so don’t feel like you have to rush and buy the game right now if you’d rather try the demo first

So, all that said, if you’re feeling brave, go ahead and pre-order Stealth Target for 50% off the full-price, today! For the less brave, feel free to wait it out until I have a demo ready.

Thanks!
-Phil

I fixed 14 bugs today. Here’s my “resolved items” list. It includes the 3 things I did last week (resolution support, WASD support.)

I’m quite happy with all the feedback I got from the beta-users. Tomorrow I hope to post a build.

-Phil

Update: as an added note – the primary features added are keyboard controls, full screen / resolution options, and better mouse controls.

I’ve gotten a ton of great feedback from users in the paid beta. Today I re-read all the emails and forum posts and entered all the unfinished items into my bug tracker. Then I spent the day getting through a few of them:

– Added WASD key controls for the character
– Added ability to change resolution
– Added ability to switch into fullscreen

I’ve got 10 other items in my tracker, and I’ll see how many I can get through. I’m hoping to post a new build on Saturday and send out another mailing.

-Phil

So .. I spent today making the game feel good on the iPad. The key items I had to get working work some “smart navigation” so that mis-touches would send the player towards an open spot and not just onto a wall. This makes navigating much easier as most locations you would want to walk to are along walls anyways. This also improves the desktop interface with the same features.

I also added the ability to pan around the level by using two fingers like in many other apps. This works well. I haven’t decided if / how I will support zoom in and zoom out.

I’ve gotten a ton of emails from artists and musicians, but it’s all pretty hard to sort through! I haven’t done much contracting out, so it takes me a while to figure out what I’m doing. Hopefully it’ll all start to make sense soon.

The response from the beta sale has been excellent. I’ve gotten a number of people giving me great feedback. Over the next few days I’m going to use all that feedback to update a build for this weekend. I may also try and get it working as a demo version so that I can expand the beta to more people.

Getting the editor working took a few UI tweaks as well as handling of the keyboard when it pops up. What I’ve noticed today is that my game has 4 different coordinate systems that all have to “get along”:

– The OpenGL physical coordinates
– The iOS event coordinates
– My user interface coordinates
– The game world coordinates

And getting all those systems to work nicely together when say, the devices is reoriented, or the keyboard pops up is a bit of tricky business!

-Phil

It took a bit of messing with provisioning profiles, but I got it to deploy to the iPad, eventually.

I also add to add setup for the depth buffer into ES1Renderer.mm .. This is not included for whatever reason.

Then I got to do some iPad specific tweaks – since the game was first for the desktop, some of the code is specific to the mouse interface. I’ve wrapped some #ifdefs around those things to check for BUILD_DESKTOP or BUILD_TOUCH so I can have some code that checks for certain mouse buttons and some code that doesn’t.

There’s a pretty good list of things I need to do however:

– Get music and sound effects working

– Get the mini-level preview screens working better.

– Do some smarter backface culling

– Avoid overdraw as much as possible

– Smarter touch interface

But in general, the game seems to work alright 🙂

So by changing my rendering to use GL_ONE (additive) blending, I can easily see where I have overdraw happening in my scene.

That shot has GL based backface culling enabled, but I’m going to disable it so I can do my culling on the software size so I don’t use so much memory in my buffers. Not sure if that will give me a performance gain or not, but it’s something to try out.

To get the music working, I converted my .wav file to an .aac file using this command on OS X:

afconvert music1.wav -f adts

That seemed to produce an .aac file.

From investigating speed issues on the rendering, it seems my use of GL_LIGHTs is slowing down things considerably. If I disable all my lights it renders much faster. I may have to investigate some other options here.

Anyway, it’s nice getting this game started on the iPad. I think it’ll come together pretty quickly with another day of tweaks.

-Phil

Wow, it’s been 30 days? That’s a long time! At least, say, compared to 5 minutes. I’ve spent the morning answering emails and trying to round up artists for this game. Again, check out my jobs page if you or anyone you know is interested. I can’t wait to see how the game is going to look with “real” art 🙂

I’m going to try and get this game “running” on the iPad. At least, compiling. I’ve got only a couple hours, so we’ll see what we can do.

– Created iPad project. Moved in all files and game assets and gave it a build just to see a big number. 755 errors! Swell!

– I set up my standard -D defines. Error count down to 348.

– Added in proper loading of the iOS OpenGLES headers. Down to 78.

– Fixed use of SDL_ defines in my code to use my generic defines for various keys. Down to 42.

– #ifdef’d out all SDL stuff based on my USING_SDL define. Down to 19.

– Created a few iOS / ObjC specific functions in a .mm file. Down to 17.

– Changed all GLdouble to GLfloat. Down to 5.

– Included “glues” a GLU for ES implementation. Down to 0!!

Now onto the linker errors. I’m starting with 6. The are all the missing audio functions. I’ll have to get my iOS audio code copied over from Galcon Fusion for this.

Got rid of those, but now I’ve got 18 other linker errors. Trying to work out what Frameworks I need, I guess. Just needed “CoreGraphics” it appears. And I’ve got a build! It’s a dummy build, in that it just shows the default bouncing box that the project includes. I’ve got to connect the iPad app to the actual game now – but having it compile without errors is always a good first step!

To wrap the game I’m creating a new file – gamewrap.cpp. The header will include some very simple functions so the ObjC code does not have to interact with any of the real game objects. (This means I’m going to have a global game variable in gamewrap.cpp. This is something which can add some level of pain for Android ports, but I’ll face that music later.)

… and … I’ve got a visual! It’s oriented wrong, and I don’t have it handling events yet, but hey – it worked! Wow!

Now if I can get it handling events and oriented proper, the game will be “working” at some level on the iPad 🙂 .. Got those working, and the game is almost working – some of the 3D rendering is still a bit off though:

Anyway, I guess that leaves me something to do tomorrow!

-Phil