The Computer was Invented for Our Games

First Sorcerers Stripes Commercial

2011-03-27T19:09:00.001-07:00

Check out our first Sorcerers Stripes commercial, located HERE. This was just a fun little thing I, the Lion, and my intern (also known as my daughter) threw together. Art is completely done by James (Satellite Observatory), programming for the iPad version is done by me (Lion), and music is done by Kevin MacLeod (incompetech.com) -- check out his music, it's awesome.

This game is big, and thus taking some time to put together. But the process is fun, especially testing it out at every stage. Kids really love the battles, others also like the stories.

The exact date for release has yet to be determined, but it is just a matter of a few months, if not more quickly. Stayed tuned!

Sorcerer Stripes initial game engine done!!!

2011-02-18T18:06:00.000-08:00

The initial game engine for Sorcerer's Stripes is done!!

Initial terrain checks are done. The AI portion of the terrain check will need to be improved for better efficiency, but overall, not bad. Very quick work here :)

Also, I have added a “Media Mode”, which will be used for recording commercials. This Media Mode will not be available in the shipped version.

And with that, all the major code pieces are in place!

Now I will start fleshing out the tutorials and stories, with guidance from Satellite Observatory, who put together all the tutorials and stories originally.

There will be a lot of tweaks in the code, to make it more dynamic as time goes on. Also, I will be adding a lot of “bling” to the code, graphical and sound effects.

But with all the major pieces now in place, we can finish out a version of the game! I do not have a projected launch date yet, though it will be in a couple of months. Stripes will be launched once I feel it is worthy of a release. I imagine it being updated frequently with new features for a while as well.

And now, back to the coding. Time to add that bling!!

-the Lion

New Version of Tic-Tac-Awe Released, Update to Superior Wallpapers Coming

2011-02-05T05:26:00.001-08:00

Hi Everyone,

While development continues on Sorcerer's Stripes for the iPad, we are also maintaining our other apps.

In Tac-Tac-Awe Pro, the ability to choose a difficulty is very popular - Easy, Medium, Hard. We have now brought that functionality to Tic-Tac-Awe. An update is now available, that let's people of different skills to play the game. This is very good for young children, or those just wanting a casual game.

We have also submitted an update to Superior Fantasy Wallpapers. This update adds 10 new screenshots of backgrounds and monsters. The update should be approved by Apple within a few days.

In the meantime, development continues on Sorcerer's Stripes. More news to follow in the next few weeks on that.

For more frequent updates, please follow us on Twitter and Facebook. Links are to the right!

Quiet on This Blog, Noisy on Facebook

2011-01-15T19:38:00.001-08:00

Hi Everyone,

The Lion here. I haven't been updating this blog very often. Most of our updates have been over on our Facebook page. To follow us on Facebook (or Twitter), just click over on the right side of this screen.

Updates - Superiority Studios is now porting the Sorcerer's Stripes game over to the iPad (from our original Windows code). The port started the last week of November. Really, it is more than a port, because the code base is being reprogrammed from the ground up to make the game more expandable, being able to add onto it more and more well after the initial version is realized.

I would estimate that we are about 50% done. You can fight battles, you can progress through the story and tutor modes. The basic engine for the iPad app is complete! (as of last week). Now we are adding content, special effects, and lots and lots of little touches. We are also making sure that the iPad version of the game is rock solid, tracking down every bug, every memory leak, so that our customers will have the ultimate playing experience.

Release date - we are aiming for 3/20/2010, just over two months away.

The best way to follow our progress is on Facebook, which is most frequently updated, or to follow our Twitter stream. Both are updated pretty often. For those who wish to follow blogs instead (not everyone is into the social tools), I will make a good effort to keep this blog updated more often.

Thanks for visiting!

Thank you for a great September! More good things to come

2010-10-03T17:01:00.000-07:00

Superiority Studios wants to give a big "thank you" to all of our fans. September has been our best month yet, with two of our apps really picking up downloads, specifically Tic-Tac-Awe and Superior Fantasy Wallpapers.

Both of these apps are free! If you want to check them out, just go to Apple's AppStore and search on "Superiority Studios". If you like the apps, we ask that you click on the iAds that Apple shows, at the bottom of the screen. This helps to support our development efforts, especially to apps we are working on right now. One is an adventure game code-named "Golden Weepy". The other is a really cool app code-named "First Contact".

Thanks again! We look forward to bringing you more cool apps!

Tic-Tac-Awe Version 1.4 available!

2010-08-20T05:00:00.000-07:00

The newest version of Tic-Tac-Awe is now in the AppStore. This version contains PlayHaven functionality, which is a good way to find other cool games! If you have an iPhone and haven't tried out Tic-Tac-Awe yet, give it a try. Tic-Tac-Awe is free!

New versions of Tic-Tac-Awe and Tic-Tac-Awe Pro are on the way

2010-08-14T15:39:00.001-07:00

New versions of both Tic-Tac-Awe and Tic-Tac-Awe Pro have now been submitted to Apple. We have integrated PlayHaven functionality, giving users of the Tic-Tac-Awe products an easy way to find new and cool games, those enjoyed by users of Tic-Tac-Awe. The Pro version also includes a bug fix.

Both apps are now waiting for approval by Apple. We will post updates as each of these games is available. For those who already have Tic-Tac-Awe and Tic-Tac-Awe Pro, you will see the updates on your iPhones and iPod Touches!

-the Lion

Check out the upcoming RPG, All That Is Light!

2010-07-28T17:19:00.000-07:00

The game page for All That Is Light is live on our site. We have links to it off of our main page, @ www.superioritystudios.com . For convenience, you can also follow this link.

Also check out our 3 demo videos for the game here, here, and (drum roll please), here! .

Be sure to leave comments on YouTube, or on our Facebook page!

-the Lion

New Product in Development

2010-07-20T10:46:00.000-07:00

We now have a new major product in development -- a full-fledged RPG entitled All That is Light. Slated for a Windows release in early 2011, and possible porting to other platforms after that.

Check out further info at the official website: http://www.superioritystudios.com/allthatislight/index.html

Tic-Tac-Awe Updates

2010-07-09T19:46:00.000-07:00

For those of our fans that follow the Facebook or Twitter feeds, this may be old news. But it is always worth repeating. A new version of Tic-Tac-Awe has been released! This version has vastly improved memory management, and incorporates iAds (*note: Apple is still ramping up iAds, so you may not always see them).

If you have an older version of Tic-Tac-Awe, and have upgraded your iPhone/iPod Touch to iOS 4, you should be receiving your updates soon. If you do not have Tic-Tac-Awe, check out the AppStore! Fastest way to find our products is to search on "Superiority Studios".

-the Lion

New Tic-Tac-Awe Pro uploaded to AppStore

2010-06-19T12:01:00.000-07:00

We have completed modifications to the Tic-Tac-Awe Pro application, our free version of the Tic-Tac-Toe app. The new version has improved memory management, speed, stability. It incorporated all of the changes we made to Tic-Tac-Awe, and improved a few more things besides.

It should be less than a week for Apple to approve. They are very busy over there in Cali :) I will let everyone know once the updates are available.

-the Lion

Tic Tac Awe update & video

2010-06-11T21:46:00.001-07:00

Hi everyone. The Lion here. We have some updates for you here :)

First, Superiority Studios has published a demo of our Tic Tac Awe app onto YouTube! You can take a look at it here - http://www.youtube.com/watch?v=XdmIIenm1qU

It is a great video to learn what this app is all about, and is a great start of Superiority Studios to YouTube!

We've also been updating some of our applications. We have updated both They Say, and the free version of Tic Tac Awe. The updates bring improved performance and memory management to both apps, and also brings in a new products information screen. I am very excited about bringing these updates.

Still working on these - the same memory management and performance updates will be brought to Tic Tac Awe Pro. Also, Satellite Observatory and I are both working to bring you awesome RPGs soon!

Lastly, Superiority Studios will soon branch out into Droid programming, translating our games to that new platform.

It is a really exciting time for Superiority Studios. Check us our also on our Facebook page :)

iPhone 4 is annouced!

2010-06-07T19:31:00.001-07:00

Steve Jobs gave the opening keynote for WWDC today. The newest iteration of the iPhone is a very impressive device, and shows that Apple is going to fight the Droid with everything they have.

There is nothing like watching the keynote for yourself, but I wanted to mention a couple of the features that I am particularly interested in. First, there is the video-conferencing. It uses the new front-facing camera built into the phone, and looks pretty awesome. Unfortunately, it only works over wifi for now. AT&T's bandwidth problems shows why this is so.

Second is the high-def video recording using the iphone's rear-facing 5 megapixel camera. And you can edit your video using iMovie, which is an app right on the phone!

Third is the multiple-tasking. It will be great to be able to run more than one app at a time.

And finally, there are folders. Anyone who owns an iPhone, or iPod Touch, or iPad, knows how unwieldy pages and pages and pages of apps can be.

There are more new features as well, but these are the ones that jump out at me.

Oh, and one. more. thing.

iAds. You can now insert ads into your (hopefully free) apps. It is a great way to generate revenue with free applications, and is definitely something that I am going to be looking into :)

-the Lion

Tic-Tac-Awe is Ready! (by the Lion)

2010-06-06T10:04:00.000-07:00

Well, I have been slaving away at finishing up the new version of Tic-Tac-Awe. And it is done! The memory management in the code is significantly improved. Also, the Product Information screen is now available for the app.

I will post again once it is approved by Apple. For now, on to the rest of my weekend!

Apps in Motion! (by the Lion)

2010-06-06T07:31:00.000-07:00

Well, there has been a lot of activity from Superiority Studios lately on the app front! A new version of They Say is out the door and published in the AppStore. It implemented over 50 new sayings. Plus better memory management. Plus better performance.

Last but not least, since this is one of our free apps, we added a new "Products Info" screen, to inform our customers about some of our other great products. Especially our good art apps!

Second, we have resubmitted the "Superior Wallpapers - Science and Sorcery" app. I corrected the small icon to match the larger AppStore icon, which is what Apple wanted. It should be available in the AppStore soon.

Lastly, I am fixing up Tic-Tac-Awe (the free version). I am putting a ton of work into reworking the memory management. Plus, I am adding the same Product Information screen that They Say has.

Also, Satellite Observatory is also hard at work on an RPG! He is designing it in C# for now (an awesome language) and XNA at first. But he is going to make it work with C++ and OpenGL, so that it will easily port to the iPhone.

Lastly, we are going to branch into Droid programming!! Droid programming has some advantages, in that there are less hoops to jump through to get things published. The first apps that I will port to the Droid OS will be the Art apps, since they seem to be our most popular ones to date, and they are also fairly easy to make :)

Well, that's it for now. Watch for more activity from Superiority Studios!

iPad Review

2010-04-05T08:45:00.001-07:00

Hi all. The Lion here. If anyone is interested in what the iPad is like, I have one :). I review it on my latest post over at my Tech From the Closet (TFTC) blog, which is located at http://mlwalker1972.wordpress.com . Go and check it out!

As a very quick review here, I love it, and am currently typing this entry on it. Go and buy one yourself. And be sure to download all of Superiority Studios' apps!

-the Lion

Another Art App

2010-02-14T12:02:00.001-08:00

SO and I have released our second art app, Superior Wallpapers - Lanther the Unlucky. It is currently in review by Apple. It should be available in the AppStore within a couple of days. We have another art app in the queue as well, so stay tuned :)

- the Lion

Releasing new app

2010-02-07T11:51:00.001-08:00

Hi everyone! The Lion here. I wanted to let everyone know that Satelite Obervatory and I have just finished a new app - Superior Wallpapers - The Legacy of Aurimancy.

While it is not the most logically complicated app we have developed, it is the prettiest. It is a great collection of original art, developed by SA. You can choose any picture from the wallpaper app, extract it, and use it for your iPhone's wallpaper.

I think this will be our bestselling app to date. Hence, I have another treat for our fans. I am repricing Superiority Studios 'They Say' app to free! That's right, free!

This is good for our fans, as the price is right. It is also good for us, as it is good advertising for ourselves and our up and coming art apps.

So when will you be able buy Superior Wallpapers - The Legacy of Aurimancy? It is currently going through Apple's approval process, so it should be available within a week. When it is ready, I am sure you will enjoy its great art.

-the Lion

Using BlogWriter for this post

2010-01-31T12:21:00.001-08:00

As shown in the subject line, I (the Lion) am now using BlogWriter for writing to our blog, at least for this post. That way I can easily blog right from my iPod Touch.

Superiority Studios now has 4 apps on the AppStore - Tic Tac Awe, Tic Tax Awe Pro, They Say, and Superior Dice. Cool stuff is on its way, too. We have some art apps, or wallpaper apps on the way, and adventure apps still in the works.

So stay tuned!

-the Lion

Company Streaming Audio (AKA, Podcast)

2010-01-30T23:01:00.000-08:00

Wondering where Superiority Studios is standing right now? What the Lion's next quick-app idea is? How that lazy bum Satellite Observatory can write over 10,000 lines of code, dozens of pages of design notes, and draw hundreds of graphic files and not have a single Appstore application to show for all that effort? Will he ever get off his useless butt and get a completed iPhone app out the door? (Short answer: Probably.) Find out the answers to these and other dubiously pressing questions in our first highly dysfunctional company streaming audio file (er, podcast, I guess) available at http://web.me.com/leetaur1/Thoughts/Podcast/Entries/2010/1/30_Progress_of_Mankind,_Superiority_Style.html.

Apps, Apps, Apps

2010-01-24T11:11:00.000-08:00

One more app is in the AppStore (what we call "In Production" at my other job). The previously mentioned one is "They Say", the knowledge of the common man. It is a fun little application.

I just gave another one to Apple, that should show up within a couple of days. It is called "Superior Dice". The idea was spawned a couple of days about when I was playing a game with my daughter. All of a sudden I needed a die, and didn't have it. I looked online, and yes, there are a number of dice apps out there. But none of them worked quite the way I wanted, so I decided to make my own. I am going to end up with several apps out there that way, I think :) Determine what I want. If it is not there, make it myself. And share it, for 99 cents of course.

So, altogether, we have in the AppStore "Tic-Tac-Awe" (free version), "Tic-Tac-Awe Pro" (better version), "They Say" (the wisdom of the common man), and now, in a couple of days, "Superior Dice", in which you can roll 2, 3, 4, 6, 8, 10, 12, 20, and 100 sided dice. And you can roll up to 10 of them. Support Superiority Studios, and buy our apps!

Now, on to the next one!
- the Lion

Scifi RPG System Continued

2010-01-06T08:36:00.001-08:00

Continuing with my discussion from last time. I promised I would talk about the issue of rules heaviness, but as I thought about this post, I decided that was actually only 1 issue I wanted to talk about. Having discussed the flavor of the implied game setting last time, this time I want to talk about the mechanics of the system, in a very high-level way, regarding fundamental decisions rather than specific details. To my thinking, there are 3 separate issues to be considered at this level, which I divide into rules cohesion, heaviness, and balance. As I talk about these things, I'm going to be referencing other systems a lot, and sometimes taking a trip down memory lane, back to the olden days of gaming. (Well, relatively speaking -- I'm not old enough to remember the really olden days of tabletop gaming.)

Warning: This post is really, really long.

I am convinced that many game designers don't even think about the issues I just named when putting their systems together. This is less true now than it used to be, as a real science (and art) of well-formed RPG rules is finally starting to take shape, but the problem is still worth looking at, particularly because there are real consequences of avoiding these high-level decisions before you start putting rules together.

Let's start with the first tabletop RPG ever made, D&D and its successor AD&D (before TSR was bought out by WotC and the system evolved into its 3rd and 4th editions). Now, I don't mean to pick on D&D here -- the late Gary Gygax and Dave Arneson, co-creators of D&D, literally invented an entire new form and media of gaming, having a vast influence on countless other game systems, movies, books, even reaching overseas and dramatically influencing fantasy anime, JRPGs, etc. An enormous pile of awesome entertainment and just about the best playground of imagination ever came into being as a direct result of Gygax and Arneson's efforts. I thank them for pioneering the modern form of gaming from the bottom of my heart. It is also worth mentioning that I remember having a lot of fun playing AD&D as a kid, which puts the system ahead of any number of others that fail on this crucial point.

That said, you would expect the first iteration of such a revolutionary experiment to be rough around the edges. And boy, was it ever. Earlier editions of D&D/AD&D had serious issues, and looking back, it almost feels like the game was fun in spite of itself, or perhaps it was fun because of its flavor (which was and is totally awesome) as opposed to its mechanical implementation (which was rife with problems). Which segues into my first real topic for this post -- that of rules cohesion.

It should be mentioned that my earliest gaming experiences were with AD&D (1st and 2nd edition), not with pre-Advanced versions of D&D. So it is to those versions of this venerable game that my comments apply.

So, rules cohension? Yeah, there isn't any. Not only that, a lot of the rules are needlessly weird and complicated. Let's take the example of THAC0 -- To Hit Armor Class 0. In order to determine if you hit something in AD&D, you subtract its AC (Armor Class) from your THAC0, and have to roll that number or higher on a D20 to hit it. So, if your THAC0 is 15 and your target's AC is 3, you need to roll (15 - 3) 12 or better to hit it. Really badass creatures have negative armor classes, and of course subtracting a negative results in adding, so, for instance, hitting a -7 AC creature with your 15 THAC0 requires a 22 or better to hit -- good luck with that.

Now, this particular rules mechanic isn't particularly hard unless you really suck at math; most people can figure out what they need to hit in like 1 second in their heads. But that's not the issue here. The issue is that this rather counterintuitive mechanic makes no sense considering how much simpler it would be to just have a modifier to your D20 roll and set the target's AC at what you need to roll to hit it (as in 3rd and 4th edition D&D). It also has the odd effect of making lower ACs better than higher ones, and lower THAC0s better than higher ones -- which would be OK, except these are not universal characteristics. In AD&D, it seems random and arbitrary when statistics get higher or lower as they improve, and the only way to figure it out is to memorize them on a case-by-case basis.

Let's take another example from pre-3rd edition forms of D&D: saving throws. 3rd and 4th edition use the sensible Fortitude, Reflex, and Will saves which cover just about every contingency and make sense, but something like that would have been way too sensible for AD&D:

- Paralyzation, Poison, or Death Magic

- Rod, Staff, or Wand

- Petrification or Polymorph

- Breath Weapon

- Spell

Okay, the first issue here is that this list uses the word "paralyzation" instead of "paralysis." As it turns out, paralyzation is in fact a real word, but never in my entire life have I EVER seen the word paralyzation outside a dictionary, except here. I think these guys just like using weird words.

Moving on to the real issue, this list looks downright nonsensical at first glance. Examine it for a minute and a sort of weird logic does start to reveal itself -- "paralyzation, poison, or death magic" seems to indicate a creature's ability to shake off effects that target its vitality, sort of a counterpart to a Fortitude save. "Rod, staff, or wand" clearly indicates resistance to magical implements, although we're already starting to show inconsistency since now we're categorizing our resistances based on arbitrary criteria. "Petrification or polymorph" implies a resistance to effects that transform you or change your composition, but this further exacerbates the inconsistent criteria problem. "Breath weapon" and "spell" are pretty self-explanatory, but now we have confusing overlap -- what if you're targeted by a spell that polymorphs you? Is that a spell or polymorph save? What about petrifying breath -- save vs. petrification or breath weapon? And there's nothing in here to cover effects that target your mentality, like charm or domination. These saving throws have problems.

Then there's the incredible number of tables in AD&D. Just about every rules mechanic in the game gets its own table swarming with numbers that need to be referenced when that mechanic comes up in play. Turning undead, hit dice vs. immunity, morale ratings, poison strength, structural saving throws, lots of random encounter tables, surprise modifiers, encounter reactions, and on and on. And there's no consistent underlying math or logic to these tables. It's unbelievably confusing.

Fast-forward some number of years to 4th edition D&D. Love or hate 4E, the game has this much going for it -- kickass rules cohesion. This isn't just a bunch of arbitrary mechanics thrown together, added to, and patched into oblivion, this is a cohesive system built to be self-integrated from the ground up. Except for damage, pretty much every roll in the universe is a d20 roll, which succeeds if it's equal to or higher than the target DC (Difficulty Class), which is just a way of saying "roll this number or higher to hit." Now that's easy to remember. Saving throws make sense, there aren't arbitrary tables for every bizarre situation you can imagine, and every set of circumstances that might come up in the rules is generally covered by a broad system that successfully covers a lot of ground with a minimum of fuss and complexity. Character classes pretty much all work the same way (unlike AD&D, where every character class is its own self-contained rules set, just about). Things make sense and they're easy to learn because they're consistent.

So, after all this it's tempting to say "cohesive rules = good, non-cohesive rules = bad." Well, mostly. Certainly you want your rules to be as easy to learn as you can make them, and they tend to work better together if there's common underlying logic behind them. That said, I don't think it's necessary or feasible to try to make your rules so elegant that you can apply one or two common mechanics to every situation in the universe. Some circumstances just kind of need to have their rules spelled out for them -- certain environmental hazards, for example, or effects of starvation on characters. And some situations do benefit from a specialized rules subset that takes into account unique factors; for instance, vehicular combat. Lastly, sometimes having random tables full of weird stuff is just fun. You shouldn't overdo it; having like 2 tables per page as in AD&D is going a little overboard. In particular, tables that need to be referenced in the middle of play are generally to be avoided (using them in character or adventure creation is far more acceptable). But your rules will have more character and personality if you allow them to take on a quirk or two instead of shaping them into a sterilized monstrosity.

Next up is rules heaviness. By this I mean whether a system is rules-heavy or rules-light; whether it contains rigorous formulas and detailed systems that direct play, or whether it provides the bare minimum you need to get up and running and pretty much lets the players take it from there.

This is not a trivial issue. In fact, it has a huge and dramatic effect on how your game feels in both look and experience. There isn't really a "right" or "wrong" answer here. Both approaches provide benefits that the other lacks. Some gamers strongly prefer one approach. Others (like myself) are flexible and can have fun in either a tightly constrained or a free-form environment. Nonetheless, a decision has to be made. These philosophies are mutually exclusive; it simply isn't possible to get all the benefits of both of them simultaneously. Before we make our choice, let's examine the benefits of both approaches.

The chief advantage of the rules-heavy approach is that a well-done rules-heavy system provides tactical depth that a more free-form system lacks. This doesn't necessarily refer to combat (although it often does), but can also refer to nonviolent challenges, facing environmental hazards, using skills effectively, and even social encounters. The key here is that "restrictions breed creativity." Concisely stated, if you have a lot of rules specifying in detail what you can do in a given situation, this inherently creates an environment of variable-benefit choices whereby critical evaluation becomes necessary to maximize the chances of success. This is the essence of all games with a strategic aspect, from purely abstract games like chess and Go to tactical RPGs like Disgaea, Yggdra Union, or Growlanser. It engages the players by rewarding them for thinking strategically. It becomes an exercise of skill. In short, between the roleplaying and gaming aspects of RPGs (which of course stands for roleplaying game), a rules-heavy approach favors the gaming side of the equation. For people who enjoy intellectual challenges, this kind of system can be immensely rewarding. On the other hand, all the emphasis on the available options, cost-benefit, risk-reward, et al, does tend to limit players' thinking and encourage them to stay within the limits of what the game allows. This in no way means that creativity, roleplaying, and storytelling are excluded from such a system, but it does decrease the emphasis on these things in certain situations.

Prime example of a rules-heavy system: GURPS, which seems to make a mission goal out of rigorously simulating reality as much as possible using paper and dice. (Whether this is a good approach to making a rules-heavy system or not isn't relevant to the current discussion.) AD&D would also be considered quite rules-heavy. D&D 4E is rather an interesting case because it is rather rules-light everywhere except in combat, where it suddenly becomes very rules-heavy. Although this theoretically sounds like an ideal approach, in my experience, the lopsidedness of the rules in favor of combat tends to cause 4E to devolve into a pure battle-tactics game with light RPG trappings sprinkled on top unless the DM is rigorous in fighting this natural shift (which, incidentally, is my chief complaint in what I feel to be an otherwise excellent system). An important lesson to take away from this is that something that looks good on paper doesn't always work out in reality, which is why testing and constant critical evaluation are really important.

Now let's take a look at the rules-light approach. A rules-light system emphasizes the group storytelling aspect of RPGs (roleplaying over gaming) by providing just enough rules to act as a fair means of evaluating the outcome of important actions, and pretty much letting group consensus, common sense, and of course roleplaying dictate the rest. In a rules-light system, the assumption is that you're playing the game first and foremost to participate in a story, and you don't want an 800-page tome of complicated rules getting in the way of telling that story. This tends to work best with rather advanced players who are comfortable acting in the context of the game environment without lots of rules holding their hand to tell them how things work out. With the right group of players, imagination and creativity can really take off in a freewheeling environment like this. And of course, this isn't to say that a rules-light system completely eschews rules (it wouldn't really be an RPG anymore if you went that far), or that a rules-light system provides no tactical depth at all. If the system is well-designed, there will still be room for interesting choices and meaningful evaluation of options in dramatic situations like combat. However, a rules-light system, by its very nature, cannot provide the level of depth that a good heavy system can. Sure, when a fight breaks out, the dice start rolling and HP start falling just like any other system, but at the end of the day, when a pivotal moment breaks out, you don't look to the dice to decide the fate of the characters -- the needs of the story trump all. This approach tends to be very appealing to highly creative or artistic types, and to lazy players who don't want to have to think about everything or learn a complex set of rules.

BESM (Big Eyes, Small Mouth) is an excellent example of a rules-light system. There are just 3 core stats for each character -- Body, Mind, and Soul -- which is substantially less than the majority of other systems out there. The core combat system is extremely simple and straightforward, emphasizing speed of play over tactical simulation. Outside of combat, the game mechanics have little to say about how to handle various situations except "roll an ability or skill check against a target number set by the GM to determine if you succeed," emphasizing that the GM should just use common sense and fairness to determine how to resolve various situations. Despite the simplicity, there is a plethora of character options to allow players to go into great detail trying to build the character they envision, further underscoring the system's implied emphasis on roleplaying. It's quite simple and elegantly assembled, promising a fun and fast-paced gaming environment, but in no way could BESM be considered to supply the tactical depth of heavier game systems.

Some people might object to my preceding analysis by saying that players can alter the system they're using as they see fit; for example, that even in a rules-heavy system, you might just ignore the rules a lot of the time when you feel like playing roles over slinging dice; or that in a lighter system, you might expand on the rules to provide more tactical options when appropriate. There is certainly some truth to this, but this objection overlooks an important reality: Even when you modify it to suit your needs, the system you use makes its influence felt throughout your entire play experience. Whether you roll up a character with a long list of specialized stats tailored to provide an interesting set of tactical strengths and weaknesses, or spend 10 minutes throwing together a "light" character whose sparse attributes are designed to aid roleplaying rather than defining him in terms of a tactical simulation, colors your thinking and your approach to the challenges of the game world. When the GM puts an adventure together, whether the rules provide a sparse means of fleshing out challenges or supply page after page of options for detailing environments, hazards, and foes, is most definitely going to impact how the GM creates that adventure, and how it's going to feel in play. You can alter the amount of influence these characteristics have on your game, but you can't escape it entirely.

As I mentioned previously, many gamers will have a strong preference for one approach or the other. In a person whose mental makeup is dominated by more logical and mathematical modes of thinking, a heavy system will have greater appeal. For the more artistic gamers out there, a lighter system will probably look more attractive. (You could almost say it's a left-brain vs. right-brain kind of issue.) In my case, neither side could really be called dominant -- I'm simultaneously strongly inclined to logic and artisticness, an unusual duality (unusual only in that neither side really dominates, since in most people one or the other is clearly stronger even if they enjoy both) that colors all my thinking and makes the decision of whether to go heavy or light for my own system less clear-cut.

Nevertheless, a little consideration makes the choice clear. Although I can enjoy both heavy and light systems, there is no getting around the fact that when I'm playing a game, I appreciate having meaningful, not necessarily obvious choices that increase or decrease my chances of success based on the strength of my situational evaluation. In short, I like strategy. The intellectual challenge of it is fun and engaging. I don't want my system to be missing this important (important to me, at least) aspect of gaming. The decision is made: The weight of my system will lean toward the heavy side.

(...The fact that among the few people I know who are willing to play RPGs with me now and then, almost all of them favor a lighter approach, could be construed as a bit of an obstacle, but that's life.)

That brings us to the last high-level issue of game design: balance. In one respect, this issue is very straightforward because (except for the fun of shattering broken systems) balance is good, lack thereof is bad, and there's not much else to discuss. Well, except there is, because systems can be unbalanced in a number of ways.

Anytime player effectiveness is starkly at odds with what you'd expect, or the effectiveness level is such (too high or too low) that the fun factor is impeded, a system can be said to be unbalanced. Let's go back to AD&D again. Even above and beyond its rules cohesion issues, where AD&D shows its weakness is in the fact that it has the balance of a one-legged chimpanzee with an inner ear infection. Low-level AD&D characters are so fragile as to be completely ridiculous. It is not only possible, but is in fact a common problem in AD&D where a 1st-level character dies anytime they take any damage from anything. Comparing the stats of a 1st-level mage with an alley cat, the alley cat has a pretty good chance of taking the 1st-level mage out. (No, I'm not exaggerating. The alley cat has a better THAC0, substantially better AC, comparable damage output, and twice as many HP as the mage. The mage's best hope is winning initiative, getting off a magic missile, and rolling lucky on the damage. Failing that, retreat is the most sensible option.) Aside from the fact that having your supposedly heroic character killed by a stray housecat really sucks, this virtually forces the DM to pull his punches like crazy in early adventures lest he get repeated TPKs and prevent the campaign from going anywhere. The most sensible solution is to houserule this nonsense and give 1st-level characters a HP boost, or just start characters off at about 4th level -- but this wildly unbalanced design is indicative of deeper problems.

3rd edition D&D addressed some of this problem. 1st-level characters start off at maximum HP, and there is a feat called Toughness which boosts your HP (by 3, if I remember right, which is actually kind of a pittance, yet can be invaluable at 1st level), and if you have any brains at all, you put a good stat in your Con score for the HP bonus to increase your survivability (assuming you don't roll your ability scores randomly). Putting all this together, even a 1st-level mage can get up to about 8 or 9 HP without too much trouble, but in order to do that, you have to burn off a valuable 1st-level feat and put a good score in your Con stat when you might well prefer to have it somewhere else. If you don't waste all these resources on boosting your HP, you're still looking at a mage with a miserable 4 HP, who still has an excellent chance of getting killed by a single blow from a pissed-off kobold grandma -- and it's not like 8 HP is awesome; you're still down from just one unlucky blow. In short, while 3E was an improvement, it still didn't go far enough in addressing D&D's "low-level characters are preposterously wimpy" problem.

4E finally got it right, where even a weakling 1st-level PC can easily expect to have around 20 HP, and thereafter HP increase at a respectable but not stupidly-fast rate. (In 4E, a 5th-level character usually has about twice as many HP as a 1st-level character, as opposed to 5x as many HP in AD&D or 3x as many in 3E. This seems reasonable.) In fact, the low- to mid-level HP values for PCs seem just about perfect in 4E, because they're enough that the PCs can take a few hits before going down, but not so much that they can take a ridiculous amount of punishment. (Which isn't to say that 4E is perfectly balanced across the board. Monster HP, in my experience, are too high and make fights drag out too long; and at higher levels, HP values are just plain too high all around.)

Another balance issue is when certain character options are undeniably better than others, without taking into account intelligent character construction. Let's look to AD&D again. At low levels, mages are unbelievably pathetic characters. They have no AC, no HP, no THAC0, and no decent weapon proficiencies. Their spells suck and they can only cast a handful of them per day, after which they become useless (and consequently, boring to play due to their inability to contribute meaningfully to the team). About all they have going for them are auto-hit spells like magic missile, but these don't begin to make up for their suckitude because their damage output sucks, and they can cast so few of them before running dry. To add insult to injury, mages require more XP to level up than most other character classes, so they are doomed to stay crappy for longer. Compared to a fighter, who can wear good armor, has much better HP, better THAC0, and good weapon proficiencies, being a 1st-level mage just plain blows.

As they start gaining levels, mages become more tolerable to play, and once they gain the ability to cast 3rd-level spells (and consequently, the vaunted fireball), they take the first steps toward becoming completely overpowered. Through the middle and then especially at high levels, mages become unstoppable killing machines who get insanely powerful spells like disintegrate, prismatic wall, meteor swarm, and a host of others. Other characters can't even begin to compete with the power and versatility of a mage who's managed to live long enough to outlive his suckitude. 3E mages have pretty much the same problems; the problem was finally addressed in 4E, where mages became on par with other classes at pretty much every tier of play (much to the dismay of magophiles everywhere, but others were relieved that balance had finally been restored to the Force).

So basically, mages are unbearably crappy at low-levels, and then insanely overpowered at higher levels. A knee-jerk reaction might be to argue that this evens out and becomes balanced after all, but that argument falls apart with even a cursory examination because, quite simply, mages aren't fun to play at low levels, and then it's not fun to play anything else at higher levels as long as a mage is in the party to one-up everybody else. The point of a well-balanced system is that every viable character option is fun to use at every level of play. Note, every viable character option. It's okay if a system that provides a lot of character options has some combinations that are crappy and others that are good, as long as there are multiple viable combinations of attributes, and not just one narrow set of options that makes a character definitively superior to all others, and thereby "breaks" the system. The system doesn't have to make all options equal, but it should support viable variety.

So, the takeaway from all this is what we started with: balance good, lack of bad. But there's more to the story, because as it turns out, just like there are multiple ways to be unbalanced, there are multiple ways to be well-balanced. For the purposes of my discussion, the two major approaches to a balanced system are to balance low, or balance high.

When balancing low, the designer basically tones everything down to make sure nothing is overpowered. If he fears an ability might break the game, he makes it less powerful, just to be safe. In essence, it's basically nerfing everything until there aren't any game-breaking options. It probably sounds like kind of a dull way of maintaining balance, and frankly, it is. It's better to try to balance things properly rather than timidly weakening things just to make sure you're not introducing any broken options.

At the opposite end of the spectrum is the balance-high model. This takes the opposite view and tries to make every option so good that everything breaks the game -- but if everything truly is that good then actually nothing breaks the game. Functionally, balancing high is no different from balancing low because either way, you make sure your options are in line with each other. However, the feel is drastically different. With low balance, it feels like everything sucks and can be frustrating trying to build a kickass character, while with high balance, practically every option seems exciting and you wish you could have everything because it all seems so cool. A well-done high-balance system makes the entire game more exciting. There's a price to pay for this benefit, though: If you mess up when balancing high, your system can end up being as broken as Amu's chastity belt. The goal with high balance is to break nothing by breaking everything, but if you screw up the "breaking everything" part, then you lose the canceling-out effect and the resulting imbalance can make the system practically unplayable. It takes a deft touch to balance high.

Clearly, I feel that balance-high is much better than balance-low, if you can pull it off. It's not quite that clear-cut, though. Depending on the nature of your system, going for a truly high balance isn't always possible. So the real rule of thumb is, balance high when you can, but don't ruin your system doing it. When balancing high in a given subset of rules doesn't make sense, don't try to force it.

...And that pretty much concludes my discussion of high-level game mechanics design considerations. For my next post, I'm going to break through the abstract and start getting into concrete details, like class-based versus points-based character creation, what set of dice to use for action resolution (the most common options are 1d20 or 3d6, but that doesn't mean other options aren't possible -- and, in fact, there may be good mathematical reasons for breaking the mold), and so on. Look forward to it! (Or not.)

- Satellite Observatory (James)

Random (but fun) tangent

2009-12-29T21:30:00.001-08:00

A couple days ago, I decided I needed a break from working on my iPhone game (All That is Darkness, built on my Indifference Engine). So I've temporarily set it aside (I'll be getting back to it soon enough) and decided to follow my current whim of creativity -- which, randomly enough, is to work on a scifi-themed pencil-and-paper RPG system.

When creating such a system, I feel it's important to have a solid idea of the flavor you're shooting for. In the case of scifi, there are two opposing schools of thought, one which feels that scifi should be very scientific and technically accurate, and one which feels that scifi should basically just be fantasy in space and not care at all about realism (e.g., Star Wars). Both have good points, but each side tends to regard the other as "wrong," which I feel is misguided. I think both methods can be (and have been) used to create fun settings and stories. I also think that the best settings and stories use the best elements from both viewpoints rather than focusing exclusively on one.

To elaborate, I think the idea that good scifi is somehow obligated to be fully realistic and scientifically accurate is absurd. By that logic, stories set in the contemporary world should be even more obligated to be entirely realistic and scientific, since we have more data about our immediate experiences. Yet this is clearly not the case, since many stories set in the modern world use unscientific elements (ghosts, monsters, psionics, magic, supernatural events, etc.) to excellent effect. It is also nonsensical to assume that the fundamental state of scientific theory will be exactly the same 500 or 5,000 years in the future as it is now. Anyone who knows anything about the history of science is aware that scientific knowledge undergoes continuous paradigm shifts and is constantly making mistakes and corrections. Over and over again, science has discovered that previous assumptions were completely wrong (Aristotle, Copernicus, Galileo, Newton, Einstein, et al ad infinitum) and created more accurate models to better reflect how reality works as we understand it. It is both arrogant and naive to believe that modern scientific theory is the "final" stage of scientific progress and that we will not experience more -- perhaps many, many more -- evolutions of scientific thought as we come ever closer to an understanding of reality as it truly works. This is particularly true because even on the Earth of today, there are many everyday phenomena that are not fully explained by our current scientific understanding even in its most cutting-edge forms (e.g, quantum physics), or which only have speculative theories to explain them, such as (just to cite a couple examples out of many) the source of gravity (gravitons? possibly, but unproven -- and even if true, how does a graviton exert a force of attraction?) or light (particle? wave? photon? nothing definitively proven). How much greater would our ignorance be of phenomena in foreign solar systems, with environments we can hardly even conceive of! It is more feasible to assume that (so long as human civilization is not destroyed or retarded) scientific understanding will be far more advanced several hundred or thousand years in the future. But because it is impossible to know what scientific breakthroughs will be in advance, a scifi author has no choice but to imagine a fictional superior science that will exist in the future and extrapolate new societies and inventions based on it -- unless said author bases virtually all the technology in his story on existing scientific theory, which can be quite interesting but is no more realistic than "making up" scientific advances to fill the gap. As for inserting supernatural creatures or events and other "unscientific" phenomena -- why not! As long as it improves the story.

On the other hand, the idea that scifi settings should shy completely away from adhering to known scientific principles is equally flawed. Some individuals almost seem to have a phobia of using real science in fiction as though it will somehow hurt the story. Quite to the contrary -- although a scifi author can and (in my opinion) often should "make up" science to simulate more advanced technology, a setting can be made much richer if, wherever possible, the author does base his technologies on science as we understand it. For example, you can equip all your ships with ray cannons or just call all your beam weaponry "lasers" regardless of whether they actually behave like lasers or not... or, you can take real-life concepts used by modern scientists and engineers such as railguns (which fire slugs using electromagnetic acceleration instead of chemical propellents), particle cannons (which fire beams of supercharged particles which do not travel at light speed), and scientifically accurate lasers (which travel at light speed and burn through targets rather than exploding since they are, after all, extremely condensed beams of light -- not explosive projectiles!). And you can equip all your spaceships with shields that block incoming attacks with no real explanation, which is fine, but you might make your setting a little richer if you, for instance, give some sort of reference to the fact that your ships generate electromagnetic fields that deflect incoming particles of certain characteristics (e.g., a given electric charge) since it has been demonstrated in laboratory experiments that electromagnetic fields can do exactly that. Sure, you might or might not be able to create effective shields this way, but at least an explanation like this is semi-plausible and gives a nod to real-life science. Having a rudimentary knowledge of gravity, orbits (tangential velocity, the fact that so-called weightlessness is actually continuous freefall, etc.), interplanetary navigation (you can't just go in a straight line from one planet to another!), and so on also helps you not seem like an idiot and lends a little credibility since a lot of stories really screw up these basic concepts. If you can use science without hurting your story, why not do it! After all, the genre is called science fiction.

That's why, rather than adhering to one mindset or the other, when I make up scifi settings, I use real science when I can, make up fake science when I can't, and throw in unscientific, unrealistic things, places, and events whenever I feel like it will improve the story. While "hard" scifi and sci-fantasy can both be used to construct fun and engaging settings, I feel that a hybrid approach allows for the most potential and creativity.

And that's what my scifi RPG system aims for. I draw on real science when creating rules for things such as falling (this gets a lot more involved than "d6 damage per 10 feet fallen" when you have to deal with variable gravity and factor in continuous acceleration and terminal velocity), atmospheric pressure, temperature extremes, and so on. Obviously the rules for a game have to be greatly simplified compared to actual scientific models (most people wouldn't find it fun to do 30 minutes of calculations just to work out the damage from a 4-meter fall), but they are both more plausible and more useful as good rules when the numbers are based on real theories and formulas. And I haven't made my weapons list yet, but when I do, you can be sure it will draw heavily from cutting-edge experimental and theoretical weapons of modern times. At the same time, I'm not shy about making up fantastic equipment, vehicles, and weapons if they're cool enough to justify it (giant robots and laser swords ahoy!), and I don't feel constrained by the known laws of reality if they stand in the way of integrating good ideas. Who doesn't like malignant races of alien spirit demons showing up and ruining humanity's day?

That covers the flavor aspect of the system's fiction and setting -- but what about the flavor of the mechanics? There are more issues to be considered here as well, like the issue of "rules-heavy" vs. "rules-light," which could also be phrased as "crunchy" vs. "free-form" rules. As usual, there are merits on both sides of the argument, as well as flaws. But this post is already very long, so I'll leave that discussion for next time.

- Satellite Observatory (James)

"They Say" is close to completion - the Lion

2009-12-27T15:05:00.000-08:00

The code for my next program, They Say, is now done. It is a collection of the wisdom of the common man, all the facts, and fictions, where you here someone start with 'They say', such as 'They say boys are better at math.' My sayings are not meant to be taken at face value. I know some of them to be blatantly wrong, yet I hear them repeated by friends, coworkers, and on television.

All that is left is a little artwork (provided by our multi-talented Satellite Observatory), some voice recordings by various individuals, and some more 'They Says'. We have about half the sayings we need to launch the application.

I think we will be pretty much ready to ship 'They Say' by the end of January.

My next task, while I am on vacation from my full time job, is to put together a dungeon adventure, which will take advantage of Satellite Observatory's Indifference Engine. That one is going to take a while to complete, though my first adventure using the engine is going to be much simpler than that being developed by SO.

Still workin'

2009-12-09T13:08:00.001-08:00

I haven't yet thought of a name for the first game I'm making using the Indifference Engine... but preliminary progress on it is pretty good. I've been doing lots of high-level design work, as well as character designs and some illustrations. I finished my plot outline today (rather complex because the game has a branching plot based on the player's in-game choices), and the doc that contains the backstory, character profiles, and plot outline weighs in at 13,652 words, or roughly 27 typed single-spaced pages. When I have more material to work with, I'm thinking of making a teaser site with more info about the game including a few plot and setting details.

In the meantime, here's some of the character designs I've cooked up. (Click the thumbnail to bring up a slightly larger version.) This isn't all the illustrations I've done for the game so far, but it's a good sampling:

Next task is to replace the test versions of the interface graphics with much cooler ones... then perhaps write the script and draw the graphics I'll need for the game's opening segment. Then I need to compile some sound effects and music. No rest for the creative...

- Satellite Observatory (James)

Indifference Engine Ready for Development Use.

2009-11-29T18:18:00.000-08:00

Finally, all features are implemented, all known issues are fixed, and all game modes run at an acceptable speed even with the engine running at full tilt. I hereby declare the first version of the Indifference Engine complete. Now the fun part can begin: Actually making games!

Of course, it's probably more accurate to say that the Indifference Engine is 98-99% done. That's because, although I've tested all the features in isolation, and I've tested how they interact as much as I could within a reasonable amount of time, a full-fledged game is going to put a greater strain on the engine than my test data, and might well expose some subtle bugs that the initial tests missed. But that's not too big a deal -- the entire engine is fundamentally sound and any remaining mistakes could only be in the form of minor logic errors, which are generally pretty easy to find and fix. So from here on, it's mostly a matter of designing and creating game content. Pretty exciting.

- Satellite Observatory (James)

Indifference Engine Almost Done...

2009-11-26T10:04:00.000-08:00

Since finishing battle mode, I've added the victory screen, random encounter tables, the settings screen, saving and loading, and an autosave so if the application quits in the middle of the game (for example, if you're playing it on an iPhone and you get a phone call) it will preserve your data and reload it the next time you start your app. All that's left is to make a title screen and then add sound. Though the real test, of course, will be how smoothly it runs once all of these features are implemented. My biggest fear is that battle mode will slow down again once I add audio -- but if that happens, I'll just figure out even more ways to optimize it.

The autosave feature was a bit of a pain to implement. As best as I can tell, the only place where you can add autosave functionality is in the applicationWillTerminate method of the AppDelegate. But the problem there is that my main View class, where I keep all my data, is invisible to the AppDelegate class. (Huh? MVC? Screw that.) And it's kind of hard to save data that's invisible to you.

My solution was to create a singleton class and import it in both the AppDelegate and the View. That's still just a one-way communication though -- the AppDelegate and View can talk to the singleton class, but not the other way around. That was good enough, though. The View class periodically compiles autosave data within the singleton and then when the application terminates, the AppDelegate checks in with the singleton to see if it needs to autosave -- and if so, it does. Then when you start the game back up, if autosave data exists, the InitWithCoder fires it up and you can continue on your merry way. It was a bit trickier than that, though, because the game needs to track a ton of state data and sometimes my timing on compiling the autosave data was a bit off, resulting in the data getting out of sync -- for example, it saves a bunch of Event data but then tries to load it in Map mode, which causes it to get really confused and then die horribly, thus making it impossible to ever start the game again since it immediately crashes. That obviously isn't very acceptable behavior, so I spent a few hours tracking all those bugs down and making sure the autosave data stays synced no matter what combination of loads, saves, and mode changes the user goes through. It seems to be working now.

Just a couple finishing touches to go. Gonna be glad when the programming phase is behind me and I can start actually making a game with this engine that I've spent forever designing and implementing.

- Satellite Observatory (James)

Some progress...

2009-11-21T16:06:00.001-08:00

My battle system is complete. When I tested it out on my actual iPod with everything running at the highest possible capacity, the performance slowed down; but by cutting out some non-critical animations, I got it to run really smoothly even with the enemy and player groups at full size and both sides' attack intensity turned up really high. The battle system looks /slightly/ less cool, but it's a minor downgrade and well worth it to get it running at a smooth 30fps. So I can put a big green checkmark next to that item on my to-do list... as long, of course, as it doesn't slow down again when I go back and add sound to it after enabling the victory, settings, and title screens (all of which is gonna be pretty boring, but needs to be done). It better not...

Fun moments in programming

2009-11-16T15:35:00.000-08:00

I've been really productive lately. Over the past 3 days, I've written over 2000 lines of code and gotten a huge amount of functionality in my game engine in place. Mostly it's been lots and lots of string and array manipulation, and calculating graphical coordinates. But just now I came across an interesting problem:

I was coding changing equipment on your character. Because I store equipment data as structs, it seemed straightforward enough: Create a "swap placeholder" equipment variable and then do this:

Swap placeholder = player's current equipment

Player's current equipment = new equipment

New equipment's slot (the equipment inventory is stored as an array) = swap placeholder

However, this did not work and I quickly realized why: My structs contain strings, and when I use the "=" operator to copy structs, it just copies the pointers of the strings over. I thought of 2 possible solutions:

(1) Write a crapton of tedious, repetitive code to manually copy all the data, accounting for all possible combinations of new and old equipment; or

(2) Write a function that takes 2 equipment structs as parameters and copies the old into the new, and just call this function a few times.

Option (2) is better than option (1) from pretty much any standpoint, but I soon realized another problem. Since my equipment is structs and not objects, by default, they get passed into a function by value and not by reference. This means they become local variables and any changes made to them don't affect the original structs, thus defeating the whole purpose of the exercise. The solution, obviously, is to pass in the addresses of the structs and dereference them in the function, but I had no idea how to pass structs by reference in Objective-C and couldn't really figure it out.

...Then I remembered that Objective-C is a proper superset of C.

So I went back into my raw-C DataTypes header file and added my copyEquipment method signature to that in C format, then wrote the function definition in my Objective-C source file (which looks weird packed in between my Objective-C functions because the signature syntax is completely different), and used the "->" dereference operator to assign values to the struct members while retaining the memory address of the original struct. But, since the string members are still Objective-C objects, I had to combine the C dereference with the Objective-C signals. Then I went back and replaced my original copying code with calls to the copyEquipment function using the "&" address-of operator (after fetching the relevant equipment out of the inventory array).

...Then it worked.

It's very rare that I actually have reason to use the -> and & C operators, so that was actually kinda fun.

Whee.

- Satellite Observatory (James)

Mwahahaha.

2009-11-12T16:26:00.001-08:00

I just set the following as the desktop background on my Mac:

I love it!

Tic-Tac-Awe Pro coming to iPhone

2009-11-11T19:29:00.000-08:00

It has been a while since our companies last post, so I wanted to update everyone on what we are doing.

Our first game out of the game, Tic-Tac-Awe (which is free) has been downloaded going on 200 times in its first month. By publishing this game, and a paid version of it, Tic-Tac-Awe Pro, which implements difficulty levels, we have learned how to sell on the App Store. With all of our information set up, now all we have to do is complete the games we are working on, and publish them. The faster we publish our games, the more successful our company will be!

James and I have quickly been learning the in's and out's of the iPhone hardware and software, what it is capable of and what it is not. Lesson number 1 - it does NOT have the power of a full computer. You cannot throw dozens of graphics on the screen all at once without worrying about performance. This is important, because even the weakest laptops today are more powerful, hardware-wise, than the iPhone. This is not to bash the iPhone - it is a hand-held device. You have to program it as such.

And, as such, our flagship Windows game, Sorceror's Stripes, did not port so easily. It will be ported, make no mistake, but we may need to use the 3-D accelerated OpenGL ES for the graphics, rather than the much easier to use Quartz, which chocked on James' animation.

We have other games in the pipeline, however, that are not as graphics intensive. Specifically, adventure games, very fun and detailed, but that does not use the graphical power. As we finish these up, please support our company by buying a copy of Tic-Tac-Awe Pro (as soon as it clears the App Store, probably a week or so), or buying the fun and flashy Windows game Sorceror's Stripes!!!

Eseffar Preliminary Conceptualizing

2009-10-12T16:32:00.001-07:00

I promised some information about the next game I'm working on, so here goes. The following is extracted from an email I sent to a friend recently, which sums up my ideas for the game's premise:

"Another big task I need to tackle is starting work on my next game. I have a lot of good ideas for this, but right now I'm leaning toward making a kind of simple RPG. My thoughts on this are all preliminary and subject to change, but here are the ideas I've come up with for it so far:

For this game (which I'm calling Eseffar), you create your own character, with the ability to heavily customize your character's appearance and stats, and the game then generates a random adventure to take your character on. You can continue taking your character on more randomly-generated adventures after the first one. Your stats, equipment, and maybe various story-related factors (such as NPCs you've encountered) get saved between adventures to provide a little continuity even though they're randomly generated. Eventually, if your character reaches a high enough level, the game generates a sort of 'conclusion adventure' to provide the feeling of a grand finale (since I think it's important for most games to have a goal instead of just being endless repetition). You can also create a stable of multiple characters each with their own individually preserved data if you want to try a variety of character types. The basic mechanics of the game will be quite simple (so that, even though I'll be working on it alone, I can still complete it in a reasonable amount of time), but I'll try to make them deep enough to be interesting despite their simplicity, like I did with SS. And, I'm thinking of giving the game a somewhat dark and sci-fi-ish flavor, to provide some variety after the pure fantasy and frequent light-heartedness of Sorceror's Stripes/Lanther the Unlucky."

...And that's where I'm at so far. Next step is fleshing out the details, and then to start prototyping out the basics. I'm kind of excited about that. I love game development -- it's just incredibly fun.

Now, if only we could start pulling in some major revenue so I can shrug that worry off my shoulders for a while...

- Satellite Observatory (James)

Sorceror's Stripes Windows Version now available for purchase

2009-10-11T22:54:00.000-07:00

My blog posts have been sparse recently because I've been busy copy-protecting the game, developing our automated download system, setting up the payment system, and creating decent installers for the game. (Harder than it sounds when this stuff is all interrelated.) The good news is... that's all done now, and as far as our tests have been able to determine, it all works. If you feel like some fantasy-flavored tactics/puzzle fun with a sprawling story mode, feel free to check the game out: www.superioritystudios.com/sorcerorstripes

My brother is developing a virtual artbook application for the iPhone (which will feature select illustrations I've done for The Legacy of Aurimancy and Sorceror's Stripes), and porting Sorceror's Stripes onto the iPhone is still on the agenda, though who knows when it will get done at this point. On my end, I'm going to see about deploying the free demo version of Sorceror's Stripes to various places on the Internet to try to get a little exposure. Then, for my next major company task, I might start working on my next game. I've got some really good ideas for it -- more information to come about that in a little while. For now I'll just drop the name I have in mind for the next game: "Eseffar."

But for now, I'm tired, so I'm going to go watch some Hikaru no Go. Nothing like some great anime to wind down after a long day.

- Satellite Observatory (James)

Tic-Tac-Awe AVAILABLE on iTunes store!

2009-10-08T04:48:00.001-07:00

Tic-Tac-Awe is now available on the iTunes store! If you have an iPhone, or iPod touch, please download our app and try it out. The price is right - free! This is the first app we have out the door (I beat our Windows game - Sorcerer's Stripes, written by James - by a few days :)

Change of plans.

2009-10-04T10:43:00.001-07:00

Shortly after I made my last post, the port broke again. Here's just a sampling of the nonsense I've been putting up with over the past week or so:

- Getting memory access errors while accessing an array despite being 100% certain that I'm within the bounds of the array and that all relevant elements (and the array itself) are retained in memory.

- Getting "out of scope" errors on a variable on the line the variable is declared on.

- Setting a boolean variable to true, then watching as the program skips over all the code within the conditional that checks to see if the variable is true.

Long story short, my brother and I have concluded that my compiler is FUBAR and doing any development on my new computer that we bought expressly for the purpose of enabling me to do Mac development is untenable.

For the time being, since the development environment on my brother's Mac at least mostly works, we're switching the job of porting Sorceror's Stripes back over to him. My new task is finding a way to sell the completed and working Windows version of the game: a somewhat daunting task due to the fact that we have no distribution system in place. But at least I'll be able to tackle this assignment on a proven, working development environment: my beloved Windows system, which I've developed a whole new appreciation for.

By the way. "It just works"? That stupid slogan is getting more and more ironic by the day, Apple.

- Satellite Observatory (James)

Making Progress.

2009-10-02T12:58:00.000-07:00

Whew. Finally seem to be working the kinks out of this iPhone port. The foundation is in place and seems to be running smoothly, anyway... though I'll need to actually deploy the app onto a device to definitively test its efficiency. Going to have to do the registration stuff needed to let me do that and then borrow my brother's iPod Touch for that purpose.

Maybe I'll be able to go into high-gear mode and crank out the rest of the port in a week, now that the fundamentals are finally working. Maybe. We'll see.

- Satellite Observatory (James)

Rolling natural 1s.

2009-09-28T20:51:00.000-07:00

I seem to be rolling a natural 1 on my attempt to port Sorceror's Stripes onto the iPhone.

The Mac development environment and I really aren't getting along. Every way that I feel like it ought to work, it works differently. Everything that I do so easily in C# seems like a big to-do in Objective-C. I could write a laundry list of grievances I have with how Objective-C works, but that wouldn't be particularly productive. Suffice to say that I feel like it's fighting me every step of the way rather than cooperating with my efforts, and it's a frustration trying to work with it.

I'm also discovering that, independent of the development environment, I'm not particularly good at / don't like the porting process itself. I mean, I already wrote the entire game myself over a period of 2 1/2 months -- writing it all over again in a different (and inferior) language just feels like a tedious rehash of work I've already done. As a result, I unfortunately find that I'm not getting any enjoyment out of it, which further hampers the attempt, and really isn't what I signed up to make games for.

It had just about reached the point where I was ready to hand the task of being chief porter back to my brother, but I've managed to scrounge up enough motivation to make one last heroic attempt to get this environment to cooperate with me. Hopefully I'll roll a natural 20 this time -- I could certainly use one, with all the resistance it's putting up.

- Satellite Observatory (James)

Progress on a number of fronts

2009-09-27T06:49:00.000-07:00

I posted the following to my Facebook page:

Check out my Facebook page at http://www.facebook.com/mlwalker1972

Check out company Facebook page at http://www.facebook.com/pages/Superiority-Studios/137400967209?ref=mf

Superiority Studios submitted our first application to the app to Apple's App Store yesterday. It is a small, free app called Tic-Tac-Awe. It plays tic-tac-toe. We'll see if they accept it, or want any changes to the interface or other standards changes.

With translating our first big game, Sorceror's Stripes, from Windows (where James first developed it) to the iPhone. James came up with a much more efficent main graphics loop in Obective-C, much better than using an NSTimer, which is how I set the graphics up.

Note: We will be selling the Windows versions as well. We are working on a model for selling it, since we won't have the online Appstore to be our storefront. Also, with the Windows version, James and I worry about piracy. We don't want someone just throwing it out on bittorrent and giving it away.

I've also started a little artbook application, to sell some of James' art on the iPhone ad well. James is also officially a member of my development "team" in Apple's iPhone dev program.

In other words, we're making progress :) Making decent games is a lot of work!

About to embark on some hardcore porting.

2009-09-23T20:15:00.000-07:00

My brother and I have pooled our resources to buy a new company computer: Specifically a Mac mini for my use. Since I have a lot more free time than my brother, I'm going to be taking over the bulk of the work on porting Sorceror's Stripes onto the iPhone, but lacking a Mac, I found myself in need of one to do the job.

It's not going to be easy. I first need to familiarize myself thoroughly with Objective-C, brush up on my C++ (I'm strongly considering writing the bulk of the code in C++ instead of Objective-C for performance reasons), apply a couple of optimization tricks, and then settle down for the long and (I suspect) largely tedious task of translating 10,000 lines of code. It's gonna be a bit painful at first, switching from the cutting-edge C# to these 1980's technologies. Then of course there's the whole memory management issue. (How painful it is, not having automated garbage collection on the iPhone).

But it needs to be done. Porting the game is a big task and I'm the only one with enough time on my hands to get it finished within a reasonable timeframe. Fortunately, my brother has already done a lot of work figuring out how to make things work on the iPhone, so the learning curve won't be quite so steep.

Hoping to have Sorceror's Stripes iPhone version completed within a month. Might be substantially less than that, as long as I don't run into any major stumbling blocks.

Ah, but first I have to wait for the iPhone SDK to finish downloading, it's over 2 GB, and the Internet is being really slow today. Stupid Internet...

Now, I'm off to play some Cross Edge.

- Satellite Observatory (James)

Sorceror's Stripes Website is Up

2009-09-20T20:02:00.000-07:00

And accessible at www.freewebs.com/avienlangley/sorcerorstripes

Too tired and multitask-swamped to really say much more atm.

- Satellite Observatory (James)

Sorceror's Stripes Windows Version Now Working

2009-09-18T12:35:00.001-07:00

I solved my Windows release problems and the game now works on Windows.

Problem? Turns out, in the long list of dependencies for XNA games (.NET framework with optional components, DirectX optional components, XNA framework), one of the versions I was using was too recent and wasn't backwards-compatible, thus breaking the universe. Thanks, Microsoft. This just drives home an important lesson that I really should've already been paying closer attention to: Always check the versions of your dependencies and their compatibilities very carefully.

Anyway, this is good news since it means we can consider selling the game on Windows as well as the iPhone. I'll have to discuss those possibilities with my brother and get his input on it.

Now back to working on the Sorceror's Stripes website.

- Satellite Observatory (James)

Superiority Studios website is live

2009-09-16T09:51:00.000-07:00

I hacked together a company website before going to bed last night. I sort of went for the compact/minimalistic, yet polished and professional look. I'm pretty happy with how it came out -- my only concern is that the advertisement I made for Sorceror's Stripes is slightly on the large side, but pretty much everybody has broadband these days, so hopefully that won't be too much of an issue.

Website URL is http://www.superioritystudios.net/

- Satellite Observatory (James)

Successes & Failures

2009-09-15T16:43:00.000-07:00

I'm the kind of guy who never hesitates to call things the way I see them. For example: I'm not shy about saying that, as far as I'm concerned, Microsoft Visual Studio and C# make for much better development tools than X-Code and Objective-C. But it's not because I'm a Microsoft loyalist. To prove it, it's time for me to reveal the other side of the card. Perhaps I can best explain with a story:

The first full version of Sorceror's Stripes is now done and, as best as my tests can reveal, running like a Mustang. I've converted all the resources for iPhone use, so the porting process should be ready to go. And, as it turns out, I'm very glad our primary deployment platform is the iPhone/iPod and not Windows.

With the first full beta ready to go, I decided I ought to compile a release version of the game so some of my friends can help with playtesting. I hadn't compiled a release version of an application in Visual Studio before, so this was new to me. I suppose compiling a normal VS app is easy enough, but it turns out, in XNA's case, it's murderously difficult.

The first thing I did was select the Publish option to try to create a prepackaged installer for the game. But for some reason, that wouldn't export my audio -- even after compression, the game has 100 MB of audio and the exported audio library was under 200 KB. That obviously wasn't going to work.

So then I tried to just build a Release instead of Debug version of the executable. But when I tried to run the Release exe, it crashed immediately, and I couldn't get it to work, despite triple-checking that the game content was all accounted for. "Okay," I thought, "last resort: Let's go with the debug exe."

The debug executable at least will run... on my computer that I developed the game on, at least. So I copied the debug exe, all the game content, and the files outputted by the compiler onto another computer to see if it would run off the development machine. Unfortunately, it crashed immediately. "Probably missing dependencies," I thought. So I found a forum post by some XNA guru listing the dependencies you need to run a game developed with the version of XNA I'm using... but when I tried to download the dependencies, they wouldn't even download right.

Not to be licked so easily, I transferred the game files onto a third computer and tried to download and install the dependencies on that one. The dependencies at least downloaded and installed on that computer, but even after that, the executable still crashed the moment I tried to run it.

...At which point, after a couple hours of wasted work, I decided to just give up. My big takeaway from this experience was that XNA games are ass when it comes to trying to deploy them, and poking around on the Internet, it seems there's widespread agreement on that point.

On the other hand, my brother Lion has successfully deployed apps onto the iPhone (well, technically, iPod, but if it works on one it'll work on both). It might have been a bit of a pain, but he got it done. All of which, just to reiterate, makes me very glad that our primary deployment target is the iPhone and not Windows. And makes me hesitate not one bit to admit that deploying iPhone games works much better than XNA ones.

The important point, of course, is that at least the development version of the game is working which means that the logic is all sound and the content is all created. So there's nothing standing in the way of porting the whole game onto the iPhone as soon as the speed issues are resolved.

Next task on the to-do list: Build the company website.

- Satellite Observatory (James)

More edits to Tic-Tac-Awe

2009-09-15T05:14:00.000-07:00

After watching my kids play Tic-Tac-Awe, I decided to make some edits. One was an obvious one - drawing a line through the path that won the game (a line going across, down, or diagonal). That way young kids can see at a glance how they won or lost.

The other was replacing some sound files for when you win or lose. It now "cheers" and a deep voice says "You win" when you win, or simply states in a deep voice "You lose" when you lose.

I have a couple more things to finish. One is the "Credits" screen, where we will credit ourselves and the author of our music. The second will be trying to squash any memory leaks. The iPhone doesn't have a garbage-collector, which means you have to explicitly release objects when you are done with them. Else you get a memory leak. On the plus side, there doesn't seem to be a penalty for "over releasing" your objects. So when you are done with them, just make sure they are really and truly released.

Well, time to get ready for work.

-the Lion

Programming Marathon

2009-09-15T00:07:00.000-07:00

I'm tentatively declaring Quick Match mode fully functional, pending further testing. This is after

- about 2 hours spent on planning and design;

- approximately 8 hours spent writing ~1700 lines of code and 45 external data files;

- and roughly half as much time debugging the random generators (roughly a dozen bugs found and squashed so far; testing hasn't revealed any new ones yet) and tweaking the AI to account for the greater variety of circumstances it can encounter with randomized levels.

...80% of which I did today, the other 20% yesterday evening.

Quick Match mode is pretty cool. It picks a random character for each side from 30 possible characters; assigns pieces and spells based on the characters selected; either selects a pregenerated map (from 15 maps) or builds a new, randomized map from scratch; modifies the piece selections to account for the map's geography; then puts together taunts for each of the characters.

All in roughly 1.2 days work.

Now I just add the company splash screen and the first full beta of the Windows version of Sorceror's Stripes is done. Which should be an hour of work at the most even if I make the splash screen real cool, but I'm exhausted, so I'm saving that for tomorrow. Then I make the last graphics for Tic-Tac-Awe, then start building the company website, then the Sorceror's Stripes site. And I suppose TTA should have one too. Then I have about a gazillion other creative projects pending after all that. In addition to a meeting with a business consultant and a class on online marketing strategies... So much to do.

...I'm tired. Like, real tired. Going to bed now.

- Satellite Observatory (James)

Tic-Tac-Awe nearing publishing

2009-09-13T14:12:00.000-07:00

Okay, the game I've been working on isn't nearly as impressive as Satellite Observatory's (SO's), but it is important to note that the first game that will be out the door, Tic-Tac-Awe, is pretty much complete. All we need to do is finish up the credits screen, and that will wrap it up. Thank you to SO for drawing the graphics for me - his drawing is ever-so-slightly better than mine :) About the time he is finishing up the Windows version of his game, I will be working to launch Tic-Tac-Awe onto the AppStore. It will feel good to have that completed, and to have worked out the process of getting something published.

SO is very nervous about the slowdown in graphics on the actual iPod/iPhone devices. I'm not as much. I know the iPhone has it in her, we just need to coax out the performance. It was much more intensive designing the game itself, including the C# code, which for me is pseudocode for the for the iPhone version. I use C# at work (it is one of many languages I know), so the conversion isn't that hard. The hardest part is finding more time, which, with 6 kids and a full-time job, is not always easy.

At any rate, within a couple of months, I am hoping that both Tic-Tac-Awe, and Sorceror's Stripes, will be available.

-the Lion

Optimizing for Wimpy Hardware

2009-09-13T10:37:00.000-07:00

I've looked into optimizing games on the iPhone/iPod Touch a bit and found some promising things to try. Apparently there is a compiler setting in XCode called "Compile for Thumb" or something along those lines that usually increases efficiency unless your code uses a lot of floating point operations, as most games (including Sorceror's Stripes) do, in which case it actually decreases your efficiency -- by a lot. Turning this option off, it seems, can result in substantial speed gains on a game.

It further seems that, surprisingly, there's really no built-in hardware acceleration for audio on the iPhone/iPod, which means it's a good idea to do everything possible to make your audio runs as efficiently as possible. One easy way to do this is to make sure all your audio files are in mpeg-4 format. Ours are currently .mp3s, so simply making this change could give a performance boost. We could also switch to the OpenAL audio library if necessary for additional efficiency.

There are also some tricks I can pull to optimize my graphics files to be less memory-intensive, which I will be doing shortly.

And my brother the Lion believes that, by tweaking the code to redraw only the part of the screen that changes each iteration, we'll squeeze still more performance out of it. My only concern here is that there are times when well over 50% of the screen is being updated every frame in Sorceror's Stripes, so we can't count too heavily on this method to boost our performance -- though, by all means, anything and everything that can increase the efficiency of our code is welcome and desirable.

If we go through all that and we still don't have optimal performance, we can switch as much of our code as possible from Objective-C to C++, because apparently Objective-C incurs a lot of processing overhead and you can improve performance still further by switching to C++. Lion would really prefer to avoid doing that if possible, so hopefully this step won't be necessary -- but it's good to know we have the option if we really need it.

If even that fails to deliver acceptable performance, we can switch our graphics API from Quartz to OpenGL, but that's an absolute measure of last resort.

Anyway, while I finish up the Windows version of Sorceror's Stripes (story mode is done, all that remains is to add Quick Match mode and the company logo splash screen), Lion is going to try implementing some of these optimization tricks to see how they work.

Still proceeding smoothly with the development.

- Satellite Observatory (James)

Our Games Live on the iPod

2009-09-11T09:48:00.000-07:00

Once again thanks to Lion, who, when he's not being the business manager by getting us registered and licensed and providing funding for these efforts, wears the "assistant developer" hat by laying all the groundwork for porting our game onto the iPhone/iPod.

He's made excellent progress on this front. He's successfully duplicated all the critical functionality of the game in the iPhone environment, and now that we have a license with Apple, he's even started moving our apps onto his iPod Touch. It's pretty awesome seeing the things that we've programmed working on the iPod. I may be developing our launch game (not counting TicTacAwe) single-handedly, but there's no doubt that Lion's efforts are just as critical as mine -- and I'm really glad I only have to take a small part in the business aspects, and can leave figuring out how to get everything working in Macworld in his hands. The fact that he does all this while juggling a full-time job and a family, whereas I have nothing else to distract me, makes it even more impressive.

The only setback right now is that Sorceror's Stripes apparently runs like a gimpy snail on the iPod at the moment. But there are games with more advanced graphics than ours that run beautifully on the iPod, so apparently there's just a flaw in the port at the moment. Since Lion's gotten everything working so well so far, I have every confidence in his ability to overcome this speed issue. Still, I'll feel relieved when it's running at full power. I get stressed while critical problems in my apps remain unresolved.

What would really suck is if Quartz (the graphics library we're using because it's so easy to use) is too slow to handle the game and we need to switch to OpenGL to take full advantage of whatever graphics accelerating hardware there is in that little device. That would suck because OpenGL is a b!7ch to use, so I'm hoping Lion will be able to get it running fast while still using Quartz for our graphics API.

All this drives home that I really wish I had the funding to buy myself a low-end Mac just so I can code our next game directly in the environment it'll be deployed to, thereby bypassing most of these twitchy porting issues.

As for me, I'm almost done with story mode for Sorceror's Stripes. I will most likely have it finished tomorrow. Closer and closer...

- Satellite Observatory (James)

Secrets & Lies

2009-09-10T11:45:00.000-07:00

Okay, actually just secrets.

Today's topic is secrets in videogames. Secrets have been a long tradition ever since the original Mario had a bug whereby you could access the mysterious "Zero World." This wasn't an intentional secret -- as I just mentioned, it was merely a bug -- but it nevertheless captured the imaginations of players everywhere and launched a very long and proud tradition of developers intentionally putting secrets in their games.

Is this a vital aspect to making your game excellent? Well, no. But is it fun to put secrets in your games? Yes, very much so.

If you're behind schedule or otherwise in major crunch time, you probably don't have time to put secrets in your game; you're busy enough just trying to get all the essentials in. But if you're ahead of schedule, and you've got some time to spare, why not put a few secrets in?

Secrets can take all kinds of forms, from those that have a direct effect on the game, like powerful items or power-ups for your character, to secrets that provide extra content, like hidden levels, to secrets that are purely cosmetic, like hidden story scenes. There are a handful of secrets in Sorceror's Stripes, all of the latter kind. They're not really all that secret -- before each level that contains an unlockable hidden scene, the characters will have a conversation hinting at the conditions you have to meet to unlock the secret -- but still, unless you're playing in Pudding (easy) mode, it's not necessarily easy to meet the conditions even if you have a general idea what they are.

Now I'm gonna get back to work on the last story arc of the game, so I'll stop the post here.

- James (Satellite Observatory)

We are now licensed with Apple!

2009-09-09T15:17:00.000-07:00

Thanks to co-owner Lion, since he takes care of most of the business matters. Having a license with Apple is obviously pretty vital to selling our game on the iPhone, so this is another big step.

In other news, I'm wrapping up the second-to-last story arc of the game. Just one to go and story mode is done! Then I just need to make the random level generator, add a splash screen for the company logo, and the first full version of the game will be done.

Almost there.

- Satellite Observatory (James)

Keeping Things Fresh

2009-09-07T18:32:00.000-07:00

A good game is constantly introducing new elements to the player to keep things exciting. For example, in an effective RPG, every new dungeon or other map provides a new area to explore with potential dangers and rewards; every new piece of equipment has the potential to provide cool new abilities; your characters are continuously leveling up and acquiring kewl new things they can do. In an FPS, you're continually meeting new enemies with capabilities you haven't seen before and finding awesome, more powerful new weapons for blowing up said enemies. And so on.

There are plenty of reasons that you want to keep throwing new elements at the player. New things are exciting because they're unfamiliar. The saying "familiarity breeds contempt" is true. We grow comfortable with things we're familiar with, and comfort breeds boredom. Dealing with new things forces you to stay on your toes; it keeps you uncomfortable, and that's a key element of interest. It appeals to the human sense of discovery and ambition. And, on a very simple level, too much repetition grows tedious and monotonous. Shaking things up with new elements helps fight this sense of repetition.

The rate at which new elements can and should be introduced varies from game to game. There was one famous game designer -- I forget his name -- who claimed that something new should be happening to the player every 20 seconds. I personally think this is excessive and impractical. But the lesson is that you should be throwing new and unexpected things the player's way fast enough that he doesn't grow bored with what he's already seen.

I've been working hard -- very hard -- to adhere to this principle in Sorceror's Stripes. I haven't done a precise level count in a while, but I'm closing in on 100 levels at this point. Even with most of the levels being fairly short in terms of playtime, that is a lot of levels, and the player would grow bored if they were all the same. It's about more than just varying the geography and piece reserves from level to level (although that's important, too). I also regularly introduce new pieces and spells, often with previously incomparable functionality, and new terrain types, some of which have active effects like killing or teleporting pieces. As you can imagine, this is a lot of work. Aside from having to draw animations and engineer sound effects for so many pieces, I have to code all the new behavior and try to make sure it's all balanced. At this point there are dozens and dozens of pieces and spells in the game thanks to my frenzy of constantly introducing new toys for the player to mess with, and new threats for him to contend with. And of course, there are the dozens of scenery backgrounds and hundreds of character portraits I've drawn for story mode.

It's tough on the developer(s) to take on this much work, but the result is a better game. Done well, this obsessive dedication to having meaty content can transform your game from a good one to a great one. More options means more possibilities, more depths, more tactical opportunities, richer gameplay. Don't skimp on the content. It's the lifeblood that keeps your game alive. And as we all know, having too little blood is a very bad thing.

In other news, the porting process from Windows to the iPhone made some more progress today, as assistant developer Lion translated the code for the title screen. Which might not sound real impressive, but it's a very cool title screen, and there was a fair bit of stuff to translate to get it working. It doesn't help that the iPhone port has to be coded in Objective-C, which -- sorry if I offend any hardcore Mac developers here, but even my brother, a self-professed Mac enthusiast, agrees with me -- sucks rhinoceros gnads compared to C#. Wow, is it easier to do... well, anything, actually... in C# than it is in Objective-C.

But that's life. It's a challenge. I'm glad he's the head of the iPhone port and not me. Developing the original version of the game almost looks like the easy part of the job from where I'm sitting at the moment -- 1226 (and counting) painstakingly hand-crafted sprites and all.

- Satellite Observatory (James)

Gameplay vs. Gamewatch

2009-09-05T14:14:00.000-07:00

I freely admit that I am not hip enough to be a Mac guy. The very idea of referring to myself as an "IT artist" kinda makes me want to find a convenient spike to impale in my forehead, and that's probably a good indication that the Mac subculture, as it were, isn't the right place for me. I'm more of an evil, monolithic empire, maniacal laughter and world domination kind of guy, so I feel right at home with Windows.

Moving on. I've just completed the 8th story arc for Sorceror's Stripes, with 2 left to go. (What's a story arc in this context, you ask? Basically just a series of levels with common thematic elements and a common numeric prefix; e.g. 8-1, 8-2, etc., and the associated story segments.)

In this last story arc, I found myself having to present a lot of story material to the player, because there are a lot of plot revelations getting dropped at this point in the story. This had me thinking about the issue of how much time the player should spend playing the game vs. how much time the player should basically just be sitting around, watching a story unfold. Or, to say that in a lot less words, the issue of gameplay vs. gamewatch.

It's an issue that all games have to think about. The genre and target audience are major factors in where the right balance lies. For example, many FPS (First-Person Shooter) gamers have little patience for detailed story presentations and will grow bored and reach for the "skip movie" button if they have to spend too much time sitting around, watching cinematics. Conversely, RPG fans are not only tolerant of detailed story elements but expect them, and will feel cheated if a game skimps on story too much. These are generalizations and there are exceptions, of course, but the point is that different genres should have different gameplay vs. gamewatch ratios. In the most extreme case, there is the "visual novel" genre where there is literally no gameplay and you spend the whole time watching a story, although it's debatable whether these properly deserve to be called videogames.

In the case of Sorceror's Stripes' story mode, I'm shooting for a generous mix where there is a detailed story, but the player rarely has to read through more than a couple dozen lines of dialogue at a time before starting on the next level. (Though there are a handful of longer story segments here and there, the longest of which is in the 3rd story arc.) Players who get bored with the story can just click their mouse (or, in the case of the iPhone version, touch their screen) a whole bunch of times to skip ahead. And then there are some parts where the story takes a back seat for a while and the player goes through a rapid succession of levels with very little narration or dialogue.

The 8th story arc presented an interesting challenge because I had so much story material that I wanted to present, but I didn't want to make the player wade through half an hour worth of story before getting to play the next level. Fortunately, the nature of this part of the plot is such that it was relatively easy to break it into segments and separate those with levels to keep things interesting. But that, too, was a bit of a challenge because I didn't want to sustain the "next part of this extended backstory, now a level, next part of the backstory, another level" pattern for too long or it would become monotonous and contrived. So that, too, required aiming for a good balance to try to give the player the most satisfying experience possible.

To other budding game designers, I would urge you to carefully consider these matters as well. Think about your audience and how detailed a story they expect. Try to estimate your average player's patience for extended story segments. Remember that sitting through too much story at a time can get tedious, and yet so can playing for too long without taking a breather to advance the plot. Balance is key in all things!

- Satellite Observatory (James)

Introducing the cool "Mac" guy

2009-09-04T17:18:00.000-07:00

I enjoyed my brother's initial post. Now I will talk a little bit about myself. James and I are the typical "Mac" versus "Windows" pair, though he is younger, taller, and better-looking. Go figure. I'm still cooler. After all, I use a Mac. As Lester says on NBC's Chuck, I am an "IT Artist".

While James has been working on the Sorceror's Stripes game, I have been figuring out iPhone development. This means learning how to program in Objective-C, and mimicking each of the features (animation, sound, input, etc). I am pretty confident that as the C# programming finishes up, it will be a pretty quick task to get the game to run on the iPhone. In doing so, I've created a much simpler game - Tac-Tac-Toe. We will be giving my version of tic-tac-toe away for free on the App Store once our account is set up.

I've also been spearheading getting the company set up (registered, bank account set up, working with Apple to get the Developer Program going). This is why I've been dubbed the Business Manager. Though both James and I are capable to both roles - we're both programmers, we can both work on business activities. We do truly complement each other.

As my brother indicated, we should be ready to deploy our flagship game (not counting tic-tac-toe) in about 2 months. It is something I am very much looking forward to, seeing our own software running on the iPhone.

-The Lion (Martin)

Inaugural Post

2009-09-04T14:30:00.000-07:00

First ever post to the official company blog!

Hello out there, Internetland. I'm James Walker, co-owner and lead developer of Superiority Studios -- but on this blog, I'll be going by the clever, inside-joke monicker Satellite Observatory instead.

So what do I do as lead developer? Well, at the moment, I'm pretty much the only developer. This means I do all the programming, scripting, scenario writing, graphics work, and audio engineering. Good thing I'm multitalented. And have way too much time on my hands.

My current project is finishing our launch game, Sorceror's Stripes. It's sort of a tactics-puzzle game that we're targeting primarily at the iPhone (currently in the process of getting a license with Apple). Buuut, I'm a Windows user, not a Mac user, so I'm actually developing the game in Windows using C# and XNA. That's where my brother, the other half of our company, will come into the development equations: He's taught himself how to develop in Objective-C and Quartz, and he's going to spearhead the effort to port the game from Windows to Mac.

Anyway, the core game engine has been done for some time now and I've been creating levels (along with lots of new pieces, terrain types, spells, etc.) for story mode. There are currently 80+ levels and, coincidentally, I'm also about 80% of the way done with story mode. After that, all that will remain is to code a random level generator for quick match mode, a task that I'm really looking forward to, because I love making random level generators. Looking at 2-3 weeks of work still 'til the game is finished.

Then we'll simultaneously commence in-house beta testing and porting the game to the iPhone. I'm guessing it will be about another month after the Windows version is done before we have a deployable Mac version.

And that's pretty much what I've got on my plate at the moment. In between playing Mana Khemia 2. Which, btw, is an awesome game and I heartily recommend it to any RPG fan who owns a PS2.

Well, now I've introduced myself. Hopefully my co-owner, brother, and comedic foil (!) Martin will stop by to introduce himself as well before too long.

- Satellite Observatory (James)