Brief Update

January 8, 2011

I haven’t updated the blog in a while.  I updated Brand Name Space Game to version 0.2.471 on December 31.  That update was a pretty big one: it had checkpoints that let you start partway through a level after dying, which should reduce frustration a bit; it also had 3 new stages with some new gameplay.

If anyone is interested, the version number is created by combining a manually-set version like 0.2 with the Mercurial changeset number (on my build machine) of the source code/data that built that version.  You can see the version number and the build time/date in the About screen.

I’m currently working on adding a high score table to the game, which I think will add some value.  The scoring system isn’t tuned yet, so some of the reward part of the risk/reward equation isn’t set up too well, but I’ll work on that later.  For now, I’m rolling my own high score server.  It’s an interesting style of programming that I’m not accustomed to: PHP, MySQL, and HTTP requests on the client side of things aren’t really my area of expertise, but it’s nice to be learning something new.  It might take a while before I get it all working, though.  I hope to have a new update in the next couple weeks.

Advertisements

Pre 2

December 22, 2010

I finally got my Pre 2 up and running as a development device.  When I installed Brand Name Space Game, the background rendering was wrong: it looked like there was no background at all.  I tried a few things and noticed that I wasn’t initializing some sampler state values when rendering the background.  I fixed that and have a new build that I’ll upload within the next few days, unless I find something else to tweak.

The game is up to 631 downloads and counting now.

Developer Phone

December 22, 2010

I bought a Palm Pre 2 from HP and received it a few days ago.  HP is offering a $200 discount to webOS developers, which is a great deal.  After waiting for the discount code for about a week, I ordered the phone from the HP Small and Medium Business website.  A glitch kept me from getting the phone for about a week, but I finally got it last week.

It’s an unlocked GSM phone and it won’t let you do anything without activating it.  I didn’t have a SIM card or anything so I was out of luck for a little while.  After searching the Internet for information, there were two different routes I could take for using the phone as a developer device: I could bypass activation or I could get a SIM card and an account (preferably pay-as-you-go) with a wireless provider.

Bypassing activation has the advantage of being free, but it seems like you cannot access the Palm App Catalog this way, which is a pretty serious drawback.

The pay-as-you go option seemed a little better because I didn’t expect to use the phone for phone calls and I planned to use a Wifi connection for all data.  So except for any signup cost, I expected it to be free.  Unfortunately, it was a little difficult to get a straight story from various Internet posts.  I ended up going to an AT&T store and getting a SIM card with the cheapest pay-as-you-go plan ($2 per day with an initial payment of $15).  No one seemed to know what would happen if I tried using data on a smartphone with this plan, so I figured I’d try it and, in the worst case, I’d be out $15.

I put the SIM card in and booted the phone.  It went through the normal first-time setup and I created a new Palm Profile with no trouble at all.  Everything worked fine.  It looks like there’s a $.01 per KB charge for data on this plan, which is pretty steep.  I did notice that the phone does do some data transmission in the background, about once per hour.  I’m not sure why this happens, and it was costing about $.25 per hour, which would quickly deplete my balance.  Fortunately, the phone app has preferences that allow you to turn off data, and I haven’t had any charges since I turned it off.  I just connect via Wifi and everything works.

So anyway, so far so good with this plan.  I can access the App Catalog and download my app for testing, and the total up-front cost was only $15.

Unfortunately, there are some recurring costs with this plan, although those costs are very low. When you add money to your account, the funds actually expire if they’re not used. The minimum refill amount is $15. If you add $15-$24, then the funds expire in 30 days. If you add $25-$99, the funds expire in 90 days. If you add $100, the funds expire in 365 days. I believe the refill amounts are limited to $15, $25, $50, $60, and $100. When funds expire, you have a 60-day grace period before the account is cancelled. So, assuming you don’t use any minutes, you can get away with spending $100 every (365 + 59) days if you wait until the day before the end of the grace period to refill your account. I suppose you could just let the account expire if you’re not using any minutes, though. I want to keep my account active just in case I need to test it on a cell network.

Second Day

December 18, 2010

After two days there are now 391 downloads of Brand Name Space Game Beta, which seems like a lot to me.  I appreciate people checking it out and especially those who’ve left reviews with constructive feedback.

Like I mentioned yesterday, I increased the area of the screen where the user can tap to shoot.  I also implemented streaming music using ogg vorbis files to keep the size down.  Playing stereo ogg files takes quite a bit of processing power, unfortunately, so I changed the audio system to output mono.  The CPU usage is down but the music doesn’t sound as good.  I may eventually look at writing an ADPCM decoder, which would be a lot faster and give reasonable compression, but it looks like that would take quite a bit of time.

I added music to the two boss levels, and it helps the overall feel of the game.  I got the music from incompetech.com: there’s a ton of really excellent royalty-free music on that site.  I tried to find some that added to the intensity of those levels.  Now, though, the music is conspicuously absent from the other levels.  There are a number of music pieces on incompetech.com that I think would sound pretty good during normal gameplay, but I don’t know if I can live with the CPU hit.  I’ll invest some time in the normal levels, but I might just release a new version in the next few days with just the boss level music.

First Day

December 17, 2010

I wasn’t sure if anyone would download the Brand Name Space Game Beta app after I submitted it to the Beta distribution channel.  It’s difficult to tell how many webOS users even know about the Beta channel because the Beta apps don’t show up in the official App Catalog.  Anyway, there were 150 downloads the first day, which suprised me as being a fairly large number.  Two users wrote reviews which had valuable feedback.

One user mentioned that the game seemed boring toward the end because there is no music.  This is a good observation: the addition of some good music during the boss fights would add quite a bit of attention.  I haven’t implemented gameplay music because I’m not sure how to handle streaming sounds with the SDL library yet: the title screen music is just loaded into memory and played, but that’s not really a good solution for gameplay music because it would take more memory than I’d like.  I’ll need to make it a priority to work out the details and get some music in the game.

Another user said that shooting wasn’t consistent.  I’m assuming the user meant that touching the screen to shoot didn’t cause your ship to shoot all the time, and I’m guessing that’s due to the somewhat small area of the screen where a touch will initiate shooting.  I just increased the size: now the entire bottom right quarter of the screen can be used to shoot.  I hope this addresses the issue.

I really appreciate the reviews and the feedback that these users supplied and I’m going to prioritize getting fixes for the issues into the next version.

Beta Submission

December 15, 2010

I submitted a version of Brand Name Space Game to the Palm Beta distribution channel.  The process was smooth and easy, mostly because the developer website has good documentation and lets the developer know exactly what to expect and what materials need to be prepared.  Since it’s in the Beta channel, the app doesn’t go through any review process by Palm and should be available shortly (within 24 hours).

I’d appreciate any feedback and bug reports from anyone who decides to try it out.  Keep in mind that this is the first release of the game and that there isn’t much content there, so don’t be too harsh.  For feedback, go to the About screen from the main title screen and use either the “Email Developer” button or the “Request Support” button.  Or go to http://inertia360.com and click the Contact link at the bottom of the page.

To install the app on a Palm® Pre™, use this link: http://developer.palm.com/appredirect/?packageid=com.inertia360.app.spacegamebeta

Design Ramblings

December 1, 2010

I always felt that the early video games, starting with Pong and extending up to the launch of the PlayStation, were appealing partly because of the model of interaction that they presented to the user, which was really simple.  A game showed you the game state, visually and audibly, 60 times a second.  You provided some input that affected that game state.  Ideally, the effect of your input was visible (and audible) the very next update of the game state.  You, as a player,would get into the rhythm of the interaction and develop reactions to the visible state that became reflexive.  Each new game had a different rhythm and you would work to develop your reflexes to work with that rhythm and get as far as possible into the game.

I used to think about games as a tree of interactions where each node in the tree represented a possible game state.  Every 1/60th of a second, your input took you to a new node down the tree.  Of course, it would be impractical to represent the tree visually because there would be so many nodes (if you have N possible inputs,then each level of the tree would contain N times as many nodes as the previous level, which would get out of hand quickly even for a small value of N).  But I still used the tree as a conceptual model.

I used to think of some games as having a broad, shallow tree and some as having a narrow, deep tree.  The broad tree might be present in an adventure game, where the interaction actually happened much slower than 60 times per second, but which allowed for a large number of possible choices each step.  The narrow tree would be present in an arcade game which stepped at 60 times per second but only allowed a few possible interactions (joystick direction and button presses).  I personally enjoyed the fast action games that offered simple, frequent interactions.

When I talk about game design, I’m talking about single player arcade-style or console-style games because those are the games I like.

One of the guiding principles that I used when designing games was that a visual and audible response should occur the very next game frame after the user pressed a button.  I thought this was very important so the player would get immediate feedback so they would feel that their actions were consistently taking effect.  When you pressed the shoot button, the projectile appeared the very next frame along with the beginning of an audio clip.  Any delay made it harder to get into the rhythm.  Worse,a variable delay made the game feel choppy and unappealing.

Another principle that I used was that the game state be communicated to the player in an explicit and unambiguous manner.  The display of health points must be clear and obvious: it could be a number or a set of filled-in icons, but the player must know exactly how many hits he/she can take before dying.  Any ambiguity just detracted from the clarity of the communication between the game and the player.  I never understood the games that displayed health points as a bar graph or, worse, an image of the player’s face that got successively more damaged.  To me, these just introduced ambiguity and confusion and didn’t give the player all the information he/she needed to make good decisions.

Displaying the number of health points goes hand in hand with having a predictable amount of damage.  In general, I preferred having each hit consistently cause one point of damage because it’s absolutely clear to the player what’s going on.  If I have two health points left and I’m about to be hit by a projectile, I know I’ll survive the hit and I can factor that into my decision-making.

Modern games have gone in a different direction.  These days, in third-person games,hitting an action button usually starts a lengthy, realistic animation that eventually causes a projectile to be fired.  Having a different weapon causes a different animation to play out with a different delay before the projectile appears.  Health might be communicated as a number or a bar graph, and hits from different types of enemy projectiles might cause different levels of damage, so when your health is low, you’re never quite sure if you’ll survive.  Controllers have many, many buttons to press and many different modes and sequences that need to be memorized.  The interaction tree is wide.  The standard frame rate is 30 frames per second, and most games have fluctuations in the frame rate that detract from the overall smoothness.

All these things make games a lot different than they were when I was designing.  Obviously,many modern games are technically impressive, appealing to many players, and commercially successful; many of them are very, very good.  I’m not trying to argue that my way of looking at things is better or that the new games aren’t as good as the old games were.  I’m just mentioning this stuff to clarify how Inertia 360 games are going to be different from a lot of modern games.