Posts tagged: dev

Squishy Bugs Release Soon

Squishy Bugs is scheduled for release soon, barring any surprises/complications. I haven’t gone through the process of submitting to the Android market, yet, so I’m expecting something as simple as uploading and pressing a button marked “Publish”. I hope there’s no signing any packages or hoops to jump through, and if there are that the instructions are simple. I’ve already created and paid for my Android market account. I’m already set up to receive funds through the market. All systems should be “Go”.

I’m just polishing up the last little bits I can in the time permitted. Just last night I started working on the tutorial. I would like to believe the game is simple enough to figure out without instructions, but it can’t hurt to be prepared.

I hope to have the tutorial finished tonight or tomorrow. Then I can go back to fixing the last couple (low priority) known issues. And then adding sound effects. And hiding the advertisement when not on the menu. And then tweaking the scoring system. And then… there’s a whole list of things left to do. Oh yeah, I kind of still need to add squishy bugs to the game. You know, the things that give the game its name? Yeah, they’re still not in here. And finish building the web site…

I’m still on schedule for a December 24 release. Progress will be posted here, as usual.

Android Market Pricing

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.

Polygons and a Proper Map

I wrote in my previous post that my idea would make sense once I got it working.

The purpose of this “Accessible Area” map is for the game, SpaceFight!. The orange area represents the places that the player character can reach given a certain amount of time. The algorithm works something like the following:

  1. Build a list of visible wall nodes (corners) within a range around the player
  2. Sort the list from closest to furthest
  3. Cast out spokes at given intervals with a minimum length of whenever it collides with a wall and a maximum length of the given radius
  4. Create and add to the ‘area list’ a polygon based on the previous spoke coordinate and the current spoke coordinate
  5. Iterate list of visible wall nodes
  6. Calculate new radius by subtracting the distance between the starting location and the node location from the given radius
  7. Start over at the top of this list substituting ‘player’ for ‘node location’ and keep going until the new radius is too small

I really wanted to add (union) the polygons together to create one polygon consisting of the outer-most points. Unfortunately, that messes up and I’m left with what looks like a crumpled bridge at the best of times. For the time being I’ll have to use the list of hundreds (due to the recursion) of polygons as seen in the image above. It’s not so bad as in the game it’ll be displayed in between turns when the frames per second doesn’t matter. Perhaps there’s a Java package out there that could do the job for me, giving me a simplified list of the union of all the polygons.

SpaceFight! Map Rendering

I keep forgetting to post on #screenshotsaturday, so here’s a peek at the current state of SpaceFight! (codename).

It doesn’t quite look like the fight takes place in space.

Since the last post, I’ve changed the resolution from 800×600 to match my phone’s display of 854 x 480. And, of course, the big difference since the last post is map rendering. I’m using the Tiled Map Editor which Slick plays so nice with.

SpaceFight! movement

Added a new state to the loop that handles the ‘turn’ after all the pawns have been given instructions. During this state, the pawns carry out the instructions given to them. At the moment, the only instructions they carry out is movement.

Presently, all the pawns turn toward the direction that they are traveling. I think I might change that so their rotation can be player-defined.

Staypressed theme by Themocracy