The latest thing we’ve been doing mainly consists of updating our Apps and making sure they have the kind of content that we want in them, as well as squashing out bugs.

We recently just updated iRis AG to v1.3, which we put a lot of really interesting changes to the background themes to make them more lively (and trippy). We pulled a few fixes from the EGW:B6 line to fix some things in the EGW:A3 line, such as with the labels being a bit fuzzy and finally patching the RB tree code. We also are not going to go beyond EGW:A3 for the ‘Anton’ architecture, being that it’s superseded by the ‘Bruno’ architecture and soon that will be superseded by the ‘Caesar’ architecture.

Speaking of updates, we’re also updating the EGW:B5 line to the final EGW:B6 line, possibly a EGW:B7 line if we need to. The main thing that is going to keep us from an EGW:B7 line is if we decide to just straight out switch to the ‘Caesar’ architecture revision for the next game we make… or we may just use the ‘Bruno’ architecture again… We haven’t looked at our options as deeply as we’d like to just yet because we’re trying to get EGW:B6 out the door and Tower Assault! updated with the new revisions.

In the EGW:B6 revision, we’ve done a lot of performance optimization work, especially around the main graphics renderer, sound mixer, and physical actuator classes. Basically a lot of pre-cached pointer IMPs again, but also modifications to how plug-ins should fit into our widgets and such.

Probably the biggest concern for a ‘Caesar’ architecture would be streamlining the drawing process to use less draw calls via batching. In my talks with the lead developer over at Gameloft Montreal, seems that that turned out to be their biggest bottleneck and they had to spend some considerable work on batching code.

The other biggest concern for a ‘Casear’ architecture is just tools development, and we wanted to get the engine building onto the desktop so we could have a desktop deployed editor for our GAMX asset manifests… Would really be nice to be able to edit some of the EGW specific settings in a GUI and not by hand in an XML file.

And of course, the other aspect of ‘Caesar’ would be to have full support of shaders, which we haven’t actually screwed around with.

Maybe we’ll do a C++ for ‘Dora’.

At any rate, basically we just have infrastructure changes around RPNi to support future development work, but not just in the technology department, but we also need to get our marketing materials updated with the new updates. That stuff takes quite a while to do because we have to go back into our .xcf’s, .psp’s, and .psd’s and modify a lot of imagery. It’ll look really good in the end for sure, though.

We also wanted to redo the movie for iRis AG, and do one for Tower Assault!, which we actually didn’t ever do.

And we were also going to make iRis AG free after the Tower Assault! update goes live and we get the above finished.

As far as new games we have on the drawing board, which this may be a conversation best had a month down the road, we have two games we were looking at possibly making: a JRPG (which we would need to find a decent writer to help us with, since in those games storyline makes or breaks the experience), and a pandemic like hacker game (which is, on par, much easier to do, and we may be able to get away with just using EGW:B6 or go ahead with an EGW:B7 update).

Lots of decisions to be making, at any rate, and a lot of work to be doing, for sure.

But we’re still here! ^_^

Tower Assault! Curse of Zombie Island is a top-down RTS set in reverse tower defense fashion where the player controls a zombie horde to do their bidding via firing brains from a cannon. The brains then act as attractors for the zombie horde, who moves towards them to eat them up. The player can also fire brains at towers and other scenery to make the zombie horde attack that location. It again used geWiz:ES (Bruno architecture) with a freshly revamped architecture (fixing many of the major issues we had the first time around), the iPhone SDK, and came in around 120k LOC (160k with the XML data files) over the course of 8 months of work (with another 4 months for design). It featured a lot of work using sprite sheets, artificial intelligence driven entities, a quad-tree spatial partitioning based collision system, and more.

After iRis AG, the design of TA!CZI started more along the lines of a traditional tower defense game, but involving zombies. We also had another idea we ripped off a certain 80s movie that involved using a gelatinous cube to eat medieval villagers (as long the kids keep popping in quarters – ring any bells?). Our design process we revamped was now largely aimed at early bad idea rejection with proper risk analysis and product analysis (so we didn’t waste a lot of time building a design up for something that wasn’t going to work out or blow up in our faces – changes of which would have probably made us cancel iRis AG), so we spent much more time in design, and that really payed off. We actually wound up combining the two ideas and came to the idea of the reverse tower defense game (as in, attacking towers with the horde, instead of defending against a horde with towers). After a lot of hard design work, including a few focus group conversations, a few prototypes to test uncertain mechanics, and a lot of conceptual artwork, we started production and knew we had something good.

Some of the more complex technology that went into the production was set up purposely in a “testing-the-water” sort of way in hopes we could build something simple enough in the meantime that would work for the game now but then later be revamped and added into the main geWiz:ES core architecture but with an improved design (which worked out great in the end). Before production started, we also knew we needed a few more key engine components added in regardless, especially with the sprited billboards that we planned on using for the main entities. We developed a sprite sheet exporter for Blender as well as a sprited billboard and sprited image component, and even got to do some vertex key framed mesh animations. The object tree system of the engine again proved invaluable in making the towers animate (fall down), and our artist did an amazing job building and animating the 3D towers even using a Blender physics tool to set up the appropriate interpolation curves, as well as rigging and animating the characters to form the sprite sheets. We also did all our imagery work at twice the size we needed so we could utilize the higher resolution screens on the iPad and iPhone4 (releasing a separate iPad HD version). The XML parser was expanded during the course of this, as well as adding in a few test components, such as a particle system. We used more of the GLES extensions and cached IMP routine pointers (to avoid the costly true dynamic method invocation feature of ObjC), which helped performance.

Overall TA!CZI sales were much more stronger than iRis AG, and we got a fair amount of publicity for what we accomplished. We were actually very satisfied with the end result, which took a LOT of effort amongst several team members. We didn’t come without issues though. For instance, the level editor wasn’t built until later in the project (which we later added into the public release as an easter egg). The game mechanics had to be tweaked constantly to get everything right. We even made the AI/FSM just a bit “too good” and eventually had to dumb-it-down in order for the player to actually feel in control of their zombie horde. We underestimated the repetitious gameplay situation, even though in design we tried to fix that with the additions of different level types (invade the village, capture the treasure, etc.). We also had some speed issues right after release due to the newer SDK released at the same time wound up having too many background processes open that messed with the game, but that was quickly fixed by doing more heavy optimization work. We did however do a lot of things right, and the biggest one was making something that was, in the end, actually fun and contained an interesting story line. It was really cool to see various nephews and neices playing it and having fun with it over the Christmas season. Given the complexity of it, though, not sure we’ll be topping it with any future work anytime soon – the game was just a bit too complex and time consuming to build.

Who are you making this for anyways?

About a year ago, my Indie team decided to build a game idea we liked. We thought we had a great idea, but it turned out that we didn’t put enough emphasis on a variety of basic marketing concepts that could have potentially saved our design for the better. Not that it was bad – just could have been better.

Since then, I’ve observed various Indie teams follow the same general process we followed: they come up with an idea they like, they think it will work, and they go for it. While some are perfectly fine with doing it that way, and surely some make big bucks doing it that way, my team no longer considers that a viable plan of attack.

Two sides of the coin

There are really two sides of the argument that I’ve confronted. On the one hand, if a team builds a game they themselves really like, it is conceivable that they will put every ounce of effort into making it good. On the other hand, if a team is tasked with building a game they themselves may not care for, it is conceivable that they may not put out that same level of effort, and the final product could suffer.

Maybe of course that is an over simplification though; just because one doesn’t care for the concept doesn’t necessarily correlate to output. But, and this is the important lesson we learned, chances are that regardless of how much effort you do or do not put in, the end product is ultimately judged by the consumer, not the developer. Aim your guns wisely; take care of your customers first – profit will come later.

Are you the consumer?

If the developer is themselves a consumer, and their interests are shared amongst fellow consumers, perhaps their personal interest and ambitions are well suited to sticking to just what they like. Perhaps those who are lucky to have that overlap have the same luck to be successful. Personally, I don’t like taking risks I can’t control.

The closer reality I’ve seen is that many developers have an interest that I would term as atypical of the general gaming population, or have an idea that is nothing more than an existing successful game with a slightly different interface and/or mechanic. Forgoing the later, which is a different article entirely (but all too common), when intelligent, skilled, and gifted people get together to make something, I’m not convinced that they are going to push something that a general audience is going to care for – not unless they really aim for exactly that. For example, my love would be for a super in depth WWII tank combat simulator, accurate to a degree unseen by any other, but that doesn’t necessarily correlate to a marketable product. I’d love it, though.

But I’m not very profitable to market to by myself alone. Perhaps another way to see it is by looking at the opposite end of the spectrum: when developers are pushed to do things that make their games appeal to a wider audience via dumbing down and/or removal of intricacies that define such genres to begin with. What effects do a wider audience appeal bring?

Read the rest of the article over at Indie Game Magazine!

Obviously both of the services above have some game-like elements themselves; foursquare has badges and mayorships, gowalla has virtual geocaching and trips. What could be more fun though is once people developing full games that use these services.

Imagine a game of pacman using an entire city.

Whilst location aware pacman in itself is cool enough, I think that once these services become more mainstream we could see some fantastic stuff. What about a Matrix style game where you have to reach a specific point to “jack out” before the agents (other players) catch you? Or a gigantic virtual game of Cleudo where you search for virtual clues at different locations around the city? Anyway, people are already making this kind of thing, for example MyTown by Booyah! games for the iPhone, which is like a location aware augmented reality version of monopoly (try not to sound like a geek trying to explain that to someone), where you can buy your favourite coffee shop and start squeezing your fellow for (sadly, virtual) rent. This is a space I’ll be watching with interest, and hopefully one day RPNi will be making a foray into it.

You see, timers are used all over – from driving a time value that sparks an interpolator to produce a “value” to driving an animation to produce “frames”, timers are useful. Even more useful than just being able to go forward and backward in time (because that’s just too easy) is when one partitions up time segments into “actions”. This gives rise to the actioned timer.

Actioned timers are even more interesting in that they allow a general interpolator, which knows only a curvature of some kind (using both interpolation between defined key frames and extrapolation beyond those frames), to exist itself as a generator for actioned values. What this means is that parts of a curvature can then be segmented and ran across in an interesting way.

Quake was the first of the major series to introduce VKFs (vertex key framed) animations. The later .md2 file format was very common and used in a lot of different places, but the sad part was that it was split into two unique sections (torso and legs) and then also the key frames were statically partitioned into actions. Well, overall, the key frames that defined the entire model were just one long stream.

I’ve read a number of books that show how people have taken .md2, paired it with an extra “script” that defines actions and their time frame start and end points, and then loaded that (e.g. Eberly). I think that is such a horrible way to do things, because even though you’ve managed to make what was once static into dynamic, it still has a lot of further problems. I am really glad we’re using our own file format for this now (the game asset manifest, or GAM (GAMX for the XML version)).

Animation becomes a really much more difficult task to attack because the mechanism that drives the conceptual details can be built up in so many different ways. Either way you look at it, though, the timer object, the way it’s built, etc., has a direct relationship to how animations “happen”. It isn’t just that an animation is occurring, or that a model is being displayed on screen, there has to be some layer of “control” that manages the process.

Of course, there are other forms of animation that should be taken into account also, such as streamed video. That requires an entirely different mechanism than a timer all together (more of a streamer object). When you start dealing with video content streamed over the web, that becomes even a more simple, yet complicated, problem to solve.

So, really, by abstracting the timer control out, we’re left with a very simple infrastructure to work on. For sprites, all we need to do is produce an image based on a particular frame number. For interpolators, all we need to do is produce an interpolated/extrapolated value based on a frame number. For VKFs and SBAs, all we need to do is produce a new vertex list based on a frame number. The concept otherwise, swishing around from key frame to key frame, is all handled in the timer control.

The abstraction here is all key. The way that the animations “happen”, under the hood, shouldn’t have any bearing on how time segments are ran across. However, we do wind up seeing some interesting problems arise. Back in the days of N64, we saw many games that used basic action controllers. The most consumer visible aspect was that animations would “jump” from one to another. If you were in the middle of running, and jumped, the animation was not streamlined. Of course, now-a-days this is fixed by doing a double interpolate, which is a weird architectural change that works.

What will become more interesting to see in the future is when animations are driven purely by the physics involved. We’ve already started seeing this behavior in many games, but it still has a long way to go. Before too long, it may start looking possible to model animations not as strict key frames, but instead model it as motions of power applied to a physics based system. This will be the ultimate animation, when you can actually trip characters walking along, or actually bust holes through a pirate ship. That’s a whole lot more fun, and tricky, to see happen.

Of course, for now, just to get to the point were we can have fully animated sprites, 3D models, and other “things”, will be a great base to continue building onwards. RPNi will definitely be able to take things to the next level.

I can’t wait to see how these interfaces work out during production.

Best of luck. -JvL

Well, the big reason of course is that we have no control over the mess. We have seen numbers that list pirates accounting for less than 1% of up-sell to a full version, and trying to put in hooks to thwart pirates just creates more fun for them to reverse engineer (and reverse engineer they will). So, really, developers are stuck with a dilemma in which nobody can honestly say that pirating games doesn’t hurt sells, but really to what extent?

Without any hard numbers it’s difficult to tell, but estimates which equate a 1:1 relationship between a pirated game and a sell, the proverbial “lost sale”, is a bunch of b.s.. The whole point of pirating is that one doesn’t need to buy it – they get it for free because it’s free. They were never going to buy it to begin with. Between having to buy it or having a very unpleasant experience involving a plunger, they would gladly take the later. There is no such thing as a “lost sale”, only a “no sale”.

Even if pirates are pirating our games, that helps us expand our brand in a sense. It gets the product into the hands of people who can talk about it (if they like it), and for an Indie developer with minimal name brand recognition, that means a lot. So, pirates are actually helping us by distributing our work and making it more common. Eventually, as the brand name expands, more and more people will notice, and that means more and more people with a buy-in potential.

Really, when it all comes down to it, RPNi makes games for people who are going to buy them. We don’t make games for pirates, and we don’t care to over complicate our production by limiting pirating through “clever” means (or more likely “intrusive” means to paying customers). We will however gladly ban pirate-known UUIDs (i.e. devices) and IP addresses from being able to talk to our servers, and we’re clearly not going to stand in the way of publishers doing their “thing” to lock their platforms down. We don’t mind going through the usual hoops, but we fully realize that all protection systems are thwart-able, eventually.

The market has changed again as free apps can now have paid add-ons (i.e. ‘freemium’ Apps). Some have called this an “end to piracy”, but really, if one thinks about it, the game instance that will be pirated will be the one that has all the add-ons anyways since that data is still client-local. Server-local data caches, on the other hand, are the only real way to really combat piracy, but involve a dependency on an internet connection in order to play and thus are suited mainly for MMOs, the bane of Indie. Of course then pirates are replaced with cheaters.

Besides, if you need to pirate a few one or two dollar apps to get by in your life, that by its very definition is a pathetic life, really. When you look at all the things you can get for that amount, you’re looking at the difference between a slushy that it took some scruffy store clerk 8 minutes to make up and an app some rogue pirate ninjas took 8 months to make up. The amount of value you’re getting for the price you’re paying is pretty impressive. In fact, if I may be so bold, I would even venture to say that’s what made the entire distribution mechanism so popular to begin with – on both sides of the fence.

The thing that RPNi sees as a much bigger issue right now is more of the dollar app stereotype that has now plagued the entire process. When you’re trying to make a few video games that require professional level talent, trying to set a price of a dollar or two per unit doesn’t even begin to cover costs. Trying to explain this to people some times just doesn’t work. *sigh*

Best of luck. -JvL