I’ve been giving a lot of thought lately on how to price a game on the Android market. I’ve given myself a deadline for codename Squishy Bugs (by the way, that’s the new name for codename Frog Fly). I plan on having something, anything, but hopefully something playable and fun on the market by December 24. There’s no strategic plan for that date, I just told myself I’d have the game playable and on the market by Christmas. December 24 just happened to be the furthest date away that still fits the deadline.
Now that a date is set, what do I do about the price?
I’ve been considering the following plan. First, the game gets posted to the Android market December 24 essentially as a fully featured demo. All power-ups and game-play elements are in place but users are restricted to a limited level set. And the game would be ad-supported.
Then I continue to polish the game. The December 24 demo would be considered the “first 90%” of the game. When the game is at a semi-polished level, somewhere in the last 10% of the development cycle (for those not in the know, the last 10% of development is the longest part of development) then I put a new build of the game up on the market with the lowest possible price point. $0.99. And I remove advertisements from the new build.
Early adopters get in at the low low price of $0.99 and get to play and suggest features as the game reaches completion. This could be a month, it could be half a year, but they get in at $0.99. And when that last 10% is done then the price raises to $1.99 (but not without a nice sale price for the first week or two to transition new purchasers into the product).
At least, that’s the thought right now. I’ll be continuing development on the game. I’m trying to post new screenshots every Saturday but there’s really not much new to show. It’s the same sort of screenshot every time. And I suppose I should get WaggSoft and the forums operational some time soon, too. I’ll need those forums to get feedback on demo.
This is an initial screenshot of my current project. It’s a pretty rough “outline” of what the game will become.
I’m writing the game in libGDX so I can test the game natively on my workstation and compile it for Android at the same time.
Heyall. So it has been almost three months since I last posted here? Ouch… Here’s what’s new.
Though I started the game just about a year ago, “Space Fight” development is on a bit of a break. It’s an ambitious project and for a guy like me who has never made a big ambitious project, it’s a lot of work. And since a lot of work takes a lot of time, my wife suggested maybe I should get something smaller out quicker (insert that’s what she said joke here). So in the meantime I’m learning how to develop for the Android platform with the book Beginning Android Games. My wife and I brainstormed what we think may be a fun little game for touch screens so I’ll be making a small game for Android before moving on to the bigger more ambitious projects.
Kev Glass has started to flip my world upside down now with his HTML5 version of Legends of Yore! He has written the game in Java and compiled it into Javascript using GWT and the canvas widget. How cool is that? It’s significant for me as I was going to look into HTML5 game development but it appears that now you can just code your game using Java2D and have it compiled into Javascript and runnable on all manner of platforms (iPhone, Android, WebOS, PC, etc) right away.
I suppose the best course of action may be to finish Space Fight in it’s current framework and worry about porting it over to Java2D later. But first I learn Android development!
This screenshot is going to look familiar.
It will look very similar to this image.
So what’s the difference? Well, the previous image shows off a very inefficient 55878 polygons with 579 nodes. The image above proudly displays a much more efficient 3417 polygons with only 16 nodes.
You may notice the right hand side, there’s an inconsistency with one of the sub-maps (a recursed AccessibleAreaMap) that appears to have stopped rotating when there was still room to continue mapping. Likewise in the top-right area. So there is still room for further improvements.
At the very least, I’m happy that the AccessibleAreaMap generation happens almost instantaneously where previously it took at least a few seconds. Rendering the AccessibleAreaMap also no longer strains the loop.
I had fun with this one, too. Shadows!
I had the theory churning in my head and this tigsource thread helped me solidify it in my brainspace.
It’s not something I absolutely needed in SpaceFight! but it’s kind of a staple for 2-dimensional games. Mostly, I was trying to wrap my head around an alternate method of accessible area mapping. When working with “lighting” it’s important to forget about the light. What’s important are the shadows. Now I can try working these ‘light sources’ into the accessible area map, placing one at each available node, and I could have that efficient accessible area mapping algorithm I’ve been looking for.
