Level up: +1 creative output; +1 communication; unlocked “play” skill

I’d thought about writing a resolutions post for this #idevblogaday a few times, but each time hesitated as I had thought it was something of a get out. However, after having thought through what that might mean for 36peas, I realized that’d it actually be very useful – at least for us.

So, here it is – 2011 resolutions for 36peas:

1. Create
2. Communicate
3. Play

1. Create

We’ll be doing a lot more of this in 2011. Last year was something of an odd one, we started with a few months of dedicated development time, but without a fully developed and resilient business plan and underlying guarantee of resources for something that’s a relatively high-risk, unpredictable business. We now have a commercially viable plan and the surety we need to just get on with it.

I’m deliberately avoiding specifically stating how much we plan to create (all credit to Noel though for doing so) – I’m just stating that we’ll be doing a lot more creating. Having said that, I can’t see much stopping us from publishing the two iPad games we’re currently working on: Dead West and our as-yet-to-be-titled 360idevgj project (which we’ve only actually spent about 6 hours on since the game jam itself).

2. Communicate

Our greatest achievement in 2010 was actually getting involved and communicating with others via twitter, various events (including 360idev) and obviously this blog.

There are specific ways we plan to apply what we've leant in 2011 – both internally and externally. But most can be boiled down to sharing what we do and sharing in what others are doing. We never could have expected a growth in monthly unique visitors to this blog from <100 to over 3,000. In retrospect this is obvious – we shared what we cared about and found ways (obviously including #idevblogaday) to get that information to others who care about it too.

3. Play

This is as much a personal one as it is a team one – but I’m sure the rest of team won’t complain. We need to do more playing. I’ve done more in the last couple of weeks (Rock Band 3’s pro keys & drums, Dungeon Hunter 2 on the iPad and some excellent marble kit – thx Lisa for the latter) than I have in the last 8 months. This has reminded me of exactly how directly important it is.

I’ve done more thinking about how to balance Dead West as a result of playing Dungeon Hunter 2 end-to-end than I have from any other gaming experience since playing through Dragon Age: Origins nearly 12 months ago. It’s not that I haven’t played games either… it’s that I haven’t fully immersed myself in a game since Dragon Age. In that 11-month gap I hadn’t exposed myself to the full extent of the experience laid out by a game designer: and as such hadn’t had the opportunity to reflect on that analytically and apply it myself to our own games.

This realization is actually pretty timely – Dead West’s at the point that it needs some pretty consequential decisions making about the overall game balance (I was actually planning on writing about that this week for #idevblogaday but wasn’t getting anywhere fruitful). Dungeon Hunter 2 – whilst quite a different game – shares some of the same balance issues and though I did very much enjoy playing it, it couldn’t have given me better examples of how to (mis)manage some of end-game situations and problems I was trying to evaluate for Dead West.

Play as an input to game design is something I talk about a lot – I think I’d just forgotten how useful it can be in facilitating immediate design decisions.

Of the three resolutions above, “play” was probably the most lacking last year ("create" was similarly lacking – but for good reason) – whilst it’s ostensibly an easy one to change, I suspect it’s this that I’ll have to put the most effort in to. Looking forward to reporting back the results of all three resolutions throughout the year.

About Infinity Blade, about Infinity Blade, about Infinity Blade

I've resisted doing this for other games, but now fully into the swing of things with #idevblogaday I've decided to ignore all previous concerns and just get on with... critique and anaylsis of other people's games.

Any experienced game developer will tell you that the best form of testing ideas is by looking at the work of others. With a bit of patience and a lot of 20-achievement-point plays, it gets pretty easy to learn from a game in an hour what the development team spent years on. Okay, they probably learnt at little more - but in terms of testing design ideas you're actually better placed seeing it with fresh eyes (just like the fresh eyes of your audience: the player).

So, without further adue, here are some thoughts on very recently released Infinity Blade from Chair Entertainment.

I'm not going to bother explaining how the game works - it's pretty simple. If you've not read them already check out Shawn McGrath's notes on reward and fun and demaning better design. Actually... if you've not played it yet do that first and then then read them. I don't want to give anything away. Oh, hang on - best not read part 3 of this either. Or part 2.

Giving my own game away, you've probably guessed that this is in parts - they go something like this:

1. My thoughts from late in the evening after reading one of the early review (before having played it)
2. The initial thoughts/reaction of our resident art Goose (an eager sword swinger)
3. Some analysis and specific design thoughts I wrote as I was playing through the game

Part 1: Late-night ramblings before playing

...I love the fact that they appear to have thought about how to bring a levelling experience to devices that are _not_ console/PC. The whole 30-minute rinse repeat (with levelling) thing, regardless of whether it's been implemented well, is absolutely on the right track...

...I'm intrigued about how it plays out on both iPhone and iPad given the swipe-sensitive nature of the game -- something that's quite different on each form factor...

...Also: cut scenes with interactivity. Winner. Don't care if it works, it's just showing that they actually -- you know -- fucking thought about it. "It" being watching another bloody cut scene on a i_____ screams "I know how to make CONSOLE games"...

...All of this done with the Unreal engine... the Unreal engine that powers so many "me too" titles elsewhere. There's the flip side of that too: it makes things look good when you actually try...

...I suspect/hope that this, though, will be remembered not for its aesthetics (which will be surpassed soon enough) but for the fact that they brought a graphical iteration as well as device-specific thinking and inspired game design...

Part 2: Initial thoughts / reaction

From Goose:

At first was bowled over at the way it looked but then figured, "you know what? It's not actually that impressive, kind of reminds me of the PS2's Devil May Cry." I'd have probably still been impressed as I haven't yet seen much that looks anywhere like that good on the iPad -- before, that was, I checked out Rage HD recently. Playing Rage changed my view on what is doable.

At first the gameplay made me grin. However, after having to do it again for the umpteenth time i started to get a bit bored -- and massively dissapointed. I thought there would be a large amount of exploration involved but, nothing. Would have been really blown away if there was an ability to explore the awesome looking castles.

The whole thing feels like a demo for an upcoming - and less than great - title. If its going to be a show-case piece then it nees to be more polished. Which reminds me, this would work better with actual buttons to press - or at least touch controls that responded a bit more like buttons. I quickly got fucked off at how many times i took a swing and nothing happened or the dodge button didn't work and i ended up getting twatted as i stood there like a fucking goon. 

On difficulty... what the fuck? No real learning curve, if anything it's fucking backwards! One minute everyone is a push over and as slow as a retarded sloth, the next they all have mad ninja skills and fuck you up in a heart beat.

The overall feel (aside from it feeling like a demo) is standard beat em' up,  only replacing the ill-placed narrative with, er, some walking. All it's missing is a over-egged vs screen with slide-in introductions surrounded by flames.

Over all it's a shame: I really like the look of all the environment and the equipment and the fighting can be fun at times. Unfortunately though, the only thing that makes me want to play again is my desire to knock that smarmy bastard off his throne and hopefully open up something new in the game.

Part 3: Analysis / design thoughts

So after us both having played it all the way through (well, in so much as you can do that - to the point of actually killing the God King anyhow) we noted some thoughts on the game's design and implementation.

Useful or just a curiosity, this is the kind of stuff we use to evaulate our own game design decisions.

• The eagerly-anticipated "interactive" cut scenes feel more like a severly crippled adventure/looting experience -- not enhanced cut scenes.
• The fast-forward feature during cut-scenes and in-battle interludes is brilliant: it get's around the "i don't to press skip because I might miss somehintg" issue, as well as providing the player with a functional and consistent way of skipping through the juicy bits.
• The button/touch responses are infuriating - so much so that I went for a sheild-heavy build so I didn't have to press the dodge buttons too much.
• There's no clear indication of what you should be doing and when -- the earliest battles with the God King are so repetitive that you wonder whether you should just let him finish you quickly and wait for a "different" experience to make an actual attempt. It turns out that this is the wrong way about doing it - at some point (generally at the end of Bloodline 5 or 6) you should able to actually beat him. In fact, it turns out you shouldn't expect anything other than an exact repetition of what came before: whether he kills you, you accept default at his prompt or you kill him, it'll be just the same the next time around.
• It's pretty obvious and not particularly worthy of specific comment, but this game is entirely based around artificially rewarding the player. Nothing you receive in reward (xp, cash, loot, levels) changes anything about the game - there's no new content (arguably the additional weapons and armour provide a small reward in the form of new textures) and nothing changes the game mechnic and features (established early on in the first Bloodline).
• The in-menu music is very clever -- dum, dim, dem, diim -- it compells you on, constantly driving your forward for the sake of, well, driving you forwards.

• The affect of enemy levels is just a mess. As there is no "levelling in this game is unlike every other" message or even suggestion of such, you expect something akin to the genre-defined normals unless told otherwise. To illustrate, some specific notes taken as playing through:
  • Should i really be able to take on a lvl24 assasin (at level 10) and win?
  • I took out the God King at level 17. He was level 50.
  • Really what do the levels do... On bloodline 5 I'm encountering a lvl25 Hedge Knight who can't land a hit on me (I was lvl14 at the time) - i can just shield block, block, block break and then take a swing. This was repeated later for level 30-40 enemies (I only ever got to level 22), and the level 50 Death Knight (who provdies no defence whatsoever to the God King himself).

 

• The pacing and visibility of the battles themselves is too quick and unclear - it's far easier to rely on what it tells you than shows you - i.e. the "block break" thing is the cue to start swinging one's sword.

• Unclear on what options are when you loose a battle -- save and return to start of castle? Does this mean you save your status and go back to castle start or that you save a game or what?
• Seemingly no facility to have more than one campaign -- in a game that does, theoretically, at least, support multiple effective character builds this is just plain irritating. No one else can play it on my iPad, and i can't play it how I'd like. I can live with not being able to share it with others - but I'd really like to do a shield and magic build alongside my shield/attack build.
• Seems on bloodlines 3 and up it's always possible to get the God King down to approximately 60% health without really taking too much damage yourself -- at this point though he'll inevitably break your shield and knock your sword aside. Until you can do some real damage (at Bloodline 5 and up) it doesn't feel like you're getting any more able to defeat him. And then when you do it all happens in one go.

• There's nothing stand out about the graphics (although a good demo for the platform). The visual design is impressive - and a relatively small amount of world space is used to good effect in both battles and battle-to-battle movements (camera angles being the key to this). Unfortunately there are some very specific issues that make things look very poor - best example being the sight of a sword piercing armour in a finishing move -- i say the sight of a sword piercing armour because I'm sure that was what was actually meant -- unfortunately it looks more like a geometry mismatch with the sword texture cleaning intersecting the armour texture. I realise Apple may have kicked back on blood effects but there are lots of other ways to get around this.
• Some battles forgo the pre-battle info screen - I.e. you get a route circle/button, but tapping it moves you to a position and then starts the battle immediately. This wouldn't be so much of an issue (I never needed to re-spec equipment before an encounter based on opponent info) if it weren't for the fact that you expect that pre-battle pause and as such aren't primed and ready with your sheild finger or dodge.
• The dodge buttons just don't work properly. As a result of this, you inevitably end up with a shield technique that gets dull fast.
• Opponents get easier as they increase in level - a lvl 31 assassin (encountered at lvl15) was a lot easier to deal with than a lvl23 assassin on a level previous -- specifically in that it became quicker, but far more predictable and less risky. When doing block, block, block break instead of having to estimate when it starts swinging again, it now blocks your attacks after it recovers from the initial stun of the block break -- so the pattern becomes block, block, block break, attack, attack, get blocked, ready shield to repeat. Previously you were left exposed as you're attacking as it'd just swing straight at you while you were attacking -- because the pace of the mechanics of the thing are so quick, it's not possible to dodge or shield these attacks (unless you only land a couple of blows and then deliberatley stop attacking).
• Very rarely do you have break from this pattern - some enemies attack with their sheild and you have to dodge it and some land very heavy blows and deplete your sheild quickly (depending on your spec, possibly before the end of the battle).

The endless repetition is actually a good idea - I don't mind it at all. It's all the other stuff that gets in the way. The rinse, repeat structure of the game is novel and provdes greater valuable mileage out of limit assets / development time. It could do with being just a bit more interesting though. Groundhog Day gets is a somewhat more refined version of formula, and that doesn't even have swords in it.

This sounds like a lot of criticism, but it obviously got something right - as I've been compelled to write about it.

Mac App Store game dev quickstart for iOS developers (pointers, lists, links, how-tos and more)

We've been doing some preliminary research (and the more technical "fiddling") with Mac App Store potential for game development. So it seemed sensible to share our findings for this week's #idevblogaday post.

What you absolutely need to do first

Go join the Mac Developer Program. It costs $99/€59 and it's super simple if you already have an iOS Developer Program subscription.

Activations (the bit between you buying it and actually getting access to it) are now happening much faster than they were in the early days of the (then) iPhone Developer Program. Ours took about 40 minutes to come through.

When the Mac Dev Program first launched, we experienced some problems adding the program to our existing account as the primary Apple ID (mine) was associated with more than one iOS dev account. This seems to have been resolved now, and it prompted the expected "select your program" drop down.

Getting this done quickly is important for a couple of reasons - firstly because a lot of the resources from Apple are only available to registered program members, and secondly because it kicks off the process of submitting financial and contract information (if you've not already done this for an iOS dev program) - more on the pre-requisites to actually publishing Mac App Store apps later.

Clarifying a few things

Just to make this super clear for those who missed it: Apple is not launching an iOS layer atop of OS X, nor is it making the Cocoa Touch APIs available to Mac OS X applications.

What it is doing is providing a mechanism for packaging, selling, delivering, installing and updating applications that run on Mac OS X: the Mac App Store. Other than the review guidelines (see below), there's really little else guiding us at this stage. We know that we need to use XCode 3.2.5 to sign applications (and their installers), but even that may be up for debate (again, more on this later).

What can Apple tell us?

First port of call should be the Mac App Store Review Guidelines (you need to have your Mac dev account setup to access these). Love them or loathe them, they're a framework for what you can and can't do. And if we're talking specifically about game development, there's nothing really problematic. Hell, this is opening up a platform (and market) for indie games publishing that just didn't exist before. Take it for what it is and do your best, or go elsewhere.

There's also the Mac OS X Reference Library, but at the moment it doesn't really include anything specifically oriented toward apps targeting the Mac App Store.

Another valuable resource is the Mac App Store section of the Developer Forums (dev program account required). There's an excellent submissions FAQ post and amongst many others, a recent discussion on what "Copy Protection" really means (i.e. it's up to the developer). Again, this requires a dev program account.

We're going to get on to development tools and game dev-specific bits in a moment, but first...

Submitting applications

Make sure you've gotten your Mac Developer Program subscription.

Adding a Mac dev program to an existing iOS dev acct gets you free apps contract by default. I'm not sure what happens for completely new program enrolments.

From iTunes Connect's Contracts, Tax and Banking section, you need to submit / agree to the paid applications contract: 

• Select request from the above page, then read and agree to the contract.
• Setup any items stating "setup" - this will require banking and tax setup if you're not coming from an iOS dev account / and/or already have those in place. This takes time and is worth doing right away. If you're a non US resident, it takes a while.

Once done, you can manage both iOS and OS X apps from the Manage Your Application interface of iTunes Connect. Apple have provided a pretty good pre-flight checklist that includes all the key information relating to building and submitting applications. Key steps are:

1. Create certificates to sign the application bundle, and the installer - get these from http://developer.apple.com/certificates/index.action#overview.
2. Create a Mac App ID - this needs an application name ("description") and an identifier (Bundle ID) - normally in reverse domain syntax (i.e. com.36peas.macapptest).
3. From iTunes Connect, select Manage applications > Add new application > Mac OS X App and enter the app name, the SKU number and the Bundle ID you just created.
4. Complete the availability and version information (which is identical to that required for iOS apps, apart from the screenshot having a 1280x800 minimum resolution).

Once you've done all this you'll be sent to a completed summary in iTunes Connect for this app/version indicating the app's status as "Prepare for Upload" or "Waiting for Upload". It should be showing "Waiting for Upload" before you can use the Application Loader to upload your binary. 

Development tools - the basics

Basic toolset is XCode 3.2.5 (GM Seed currently). Best place for information on this is the home page of the Mac Dev Center itself, which includes an important "Important Note" about not being able to use 3.2.5 GM for building and submitting iOS applications.

If you want to do both (build for the Mac App Store and the iOS App Store) as of right now (November 2010) you'll need to either do a parallel install of the dev tools, or use separate machines. If you choose the former, there's information from Apple on the XCode installation configuration itself, a handy dev forum post with a step-by-step guide on installing XCode to a different folder and even instructions on how to change the icon for one of the versions of XCode to avoid confusion.

Development tools - for 2D games (Cocos2d)

So, we've not really talked specifically about games development just yet - here's where we start.

Given the relatively open nature of OS X, there's a good few options available to you. However, I thought it was worth focussing on just two - and two that are more likely to be useful/applicable to an iOS development audience. First up is Cocos2d...

The iPhone implementation of the (originally Python) Cocos2d framework has been a popular choice for iOS games developers for some time. It offers a relatively sophisticated and evolved (despite its <1.0 version) toolset for those looking to abstract away some of the basics.

A little while ago, in fact before the announcement of the Mac App Store if I recall correctly, the support for Mac targets was announced - effectively allowing the use of the Objective-C Cocos2d framework to create Mac-native applications.

Support at this stage is pretty limited, and there don't (at least from my somewhat basic desk-based survey) seem to be a huge amount of people moving forward with it. However, there's an application template available on the cocos2d-iphone.org forums that allows you to create an empty application that certainly builds and runs on the few Macs I've tried. 

Development tools - for 3D games (Unity)

Gaining popularity amongst iOS developers is the Unity development toolkit for 3D (and 2D) games. It's a commercial piece of software with a free version that is limited on features but does allow you to build for Mac OS X, Windows PCs and a browser plugin. With the right licenses, you can also build for iPhone, iPad, Wii, PS3 and Xbox 360.

In addition to Unity itself, you'll likely also need some modelling tools - Blender's a popular open-source option. For Mac users there's also Cheetah3D -- featuring a somewhat more straightforward interface.

Unity is a visually-driven environment, but relies on the .Net-supported languages C#, JavaScript and Boo (via Mono) for scripting -- which is where the significant bulk of actual game logic in Unity games is found.

Ultimately, you'll likely want to end up paying the license fees ($1500 p/user w/out iPhone) -- and may actually be forced to if your business turns over more than $100,000 per anum.

Another important point to note about Unity applications is that at present, Unity itself cannot compile and sign an application ready for release on the Mac App Store. It's expected that this support will be announced/released soon, but right now if you want to submit a Unity-built application you'll need to go through hoops to get there. Instructions on exactly how to get through said hoops can be found here, here and here.

What's next (apart from these links)

The Mac platform, apart from Marathon, Myst, Blizzard's continued support and recently Steam's arrival, doesn't exactly have the reputation as a place for gaming that the Windows PC (or even the iPhone) does -- but that's not what matters. What matters is that very soon many millions of dedicated Mac users will be presented with a way to access (and buy) quality applications (you've got to assume the majority of said users are now familiar with the concept of an "app store") built by people like you.

Apple haven't been any more specific on dates yet, just that the App Store will come to Snow Leopard before Lion, and that it'll be in the November-January timeframe.

In the meantime, here's a bunch of useful posts from ourselves and other #idevblogaday bloggers that are relevant to games development for the Mac App Store: 

• Owen Goss's Game Dev: Getting Started
• Our own 7 simple game mechanics
• Again, our own finished game recipe
• A selection of Open Source Libs from Four Door Lemon
• Very important information about coffee from Bytesize
• Acorn heroes' Game Developer's Bookshelf
• And, very important if you're switching platforms, an honest view on play testing

Update: April 2011

Was just revisiting this for some additional resources on Unity targetting the Mac App store, in addition to the above, found:

• http://technology.blurst.com/unity-games-and-mac-app-store/
• http://forum.unity3d.com/threads/71340-Submit-Unity-games-to-the-Mac-App-Store!

What's coming in 2010 for 36peas?

As you'll be hearing plenty about in the coming weeks and months, we're working on a hidden object game, a casual racer and something else that I'm deliberately avoiding describing until I can show some early demos - it's awesome and worth the wait.

Edmund McMillen's recent post on Gamasutra is worth a read - it's not perfect but there are a few choice pointers on indie development. I'm particularly fond of #24:

24. Have fun.

If you're not having fun then quit. You only live once; there’s no reason to keep doing something if it's not making you happy.

I'm not one for resolutions (and I'd argue 2010 will be the realisation of a 15-year resolution anyhow), but I did spend some time yesterday finally sorting out my photography from the last couple of years - you can now find that at http://www.flickr.com/photos/gjjenkins/.

Finally, just a little teaser of the aforementioned and not-yet-described project: