UI WORK
Planning the User Interface

For Outpost 2, as I usually do for any other game or website, I start the UI work by sketches, as it is a quick way to solidify the vision and “proof-test” it early. While I try to avoid boxing myself early, as actually designing the product always trigger new ideas, or better ways to arrange elements, the sketches are helpful to start defining the common elements that will drive the whole UI. Sketching also forces me to insist on the concept behind the UI, and not rely purely on execution.

Here is an example of the original UI sketch, and the equivalent render of the same UI once designed. As you’ll see, while there are definitely some variations between the sketch and the final UI,the result isn’t that far off from the original vision

THE SPLASH ANIMATION

Giving context to the game…

One thing that we really tried to get right with Outpost: Haven and Outpost: Swarm was the landing page (or what I often refer to as “Splash Anim”) – technically, it’s the first impression the player gets from the game, right after the loading screen (and in most cases, after the ads from our publisher/sponsor). Obviously this page needs to give a very good first impression, and make the players want to click “Play” and get to the game after having spent a minute or two waiting.

We got very good feedback from players for the two “Splash anims” we created for the previous iterations of Outpost, but this time we wanted to change the recipe a bit: both previous animations where action-close-ups on the players battling swarms of alien bugs. The whole environment was somewhat pushed to the back, as the focus was definitely on the player action.

I wanted a better context, and a greater sense of environment for the Outpost2 splash. After all, the sub-line is “Outpost2: Stranded” and I wanted the players to feel truly lost and overwhelmed in an alien and hostile world, while still keeping close to the action-shot roots of the previous Splash pages.

The Brief

Once more, I commissioned Concept Artist Brandon Moore to illustrate the landing page for the game. As usual, I provided him a pretty detailed brief explaining the concept, showing some inspiration imagery that lived closed to what I imagined, as well as a step-by-step layout on how he would need to layer his master file so that I could animate it in Flash once the illustration completed.

The Brief was sketched and layered to give him a quick idea of the composition and illustrate the action.

It is by no mean a box, but a start-up for discussion about composition and mood, and a way to put the artist in the right direction, avoiding unnecessary back-and-forth that would strain him and me alike. In short, I see it as a precious time saver (and you know what’s said about time, right? )

Working through the Brief

Brandon quickly came back with various block compositions refining and building upon the brief. I can’t remember if he decided to stay very close to the original composition of the brief, or if it is I that nudged him in this decision, but as you can see, aside a few edits here and there, the composition was really bringing the original sketch slowly to life.

As we were getting closer to completion, it was becoming apparent that the illustration was too dark, and that the composition could be slightly edited (and by that I mean simplified). It’s always a problem getting a static illustration that is meant to be animated, as when static, all the elements seem more cluttered than once distributed over time.

Another issue I was having was that the color palette, generally very dark, would most likely clash, or at the opposite, be absorbed by the game UI. Instead of wasting Brandon’s time, and because his file was as usual very well layered, I decided to handle the color correction myself, as I was still toying with various concepts for the main UI and couldn’t really give him a palette to rely upon yet.

Editing the Art to fit the game generally tones

Aside the color palette, I also slightly edited the position of various key elements (both marines, and the crashed ship) so that their individual shape would be more telegraphic against the lighter background.

While it wasn’t originally intended, as I was editing the color palette towards lighter tones, I realized that I was getting back towards the original sketch palette.

This may come from the fact that I was expecting the sky to be much more dramatic and heavily textured with clouds, something that I had trouble communicating to Brandon. I really enjoyed doing these edits, so I didn’t really tried to carry my point across, and considered it would be faster/more fun to do the modifications myself rather than spend the time for more back-and-forth

After a few tweaks, the image started to look really great within the game UI:

As you can see, I did needed to boost the contrast for the image quite a lot to compensate the screen glows, overlays and other effects we have in-game.

But the Splash looked exactly as I wanted – it was ready for animation!

Animating the end of the world!

I won’t go over the step-by-step process of animating in Flash, as this would be a blog post of it’s own. For those curious about the process, they can look at the layering suggested in the brief, as it is almost layer-for-layer the animation structure of my Flash file.

It’s not a secret for anybody: I can prototype alright, but I’m not really a coder… I don’t really know if Squize even keeps my Tween-based animations, but that’s the fastest way I can render and tweak my anims, and if he doesn’t keep them (meaning, if he decides to code them instead) at least, the tweens give him an idea on how I envision the whole thing animated

Among the things that were sacrificed from Brandon’s illustration where the flying bugs: while they looked great on the static preview, once the animation in place, their immobility looked very awkward… Instead, I picked a random frame-by-frame animation of birds of prey, duplicated and color-corrected it several times, with the understanding that we might use one of our in-game flying bugs flying routine to code the animation.

As I write this, Squize is currently integrating the splash animation within the game – What will stay key frames and what will become bits of code is still unknown: stay tuned if, like me, you are burning to know the outcome

In the meantime, here’s a video preview of the animation, as prototyped in Flash:

In Outpost: Haven, some players complained that the Weapons and Inventory systems, actionable through the various terminals disseminated throughout the space station, were cumbersome to use.
We are correcting this in Outpost 2 – This time, players will enjoy a fully functional inventory, not only to equip their weapons, and tactical extensions, but also to equip various pieces of armor found in the many levels!

Stay tuned with the latest Dev updates on www.luxgames.net or join Outpost 2 community on Facebook at : http://www.facebook.com/outpostGame

Outpost: Haven marks the third collaboration with coder Squize, from Gaming Your Way. While I don’t remember the full genesis of the project, I’m pretty sure we talked about it while we were working together on Ionic - I believe Squize had his mind on a remake of the Amiga hit, Alien Breed, and I sure didn’t want to miss the ride

Alien Breed had the perfect DNA for a game I’d enjoy working on: retro legitimacy, simple and frantic, with a huge part left to exploration, and even some RPG elements. Plus, it (almost) leveraged one of my favorite sci-fi franchise, Alien(s). And most importantly, it lended itself to a “remake” as I believe that the original Art Direction (even though the game still looks glorious) catered a little too much to the “colorful and vibrant” style of the games of that era.

Note that I’m not mentioning the later remakes of Alien Breed, made in 3D – I won’t debate their value here, but let me just say that I believe that they didn’t really stick to the original concept, if only for the shift to 3D – so my primary reference stayed the original game, and of course Alien and Aliens military/industrial look and feel.

Establishing a look and feel

When Squize approached me to do the art for the game, he already had a solid demo built, using temporary Alien Breed sprites. The game, and few of the early levels were fully functional, so it was easier for me to start thinking about how I wanted to tweak the existing, and hopefully take the whole new package to the next level.

One of the most important part of the “vision” for Outpost was that it would be a moody and dark shooter, with a huge nod to the survival/horror genre, and a strong emphasis on storytelling.

It was obvious from the get-go that the game would do well being very dark – We planned on using and animating light as a way to convey the story, and the set-up for the derelict space station.Not only the tiles were created significantly darker than the original series of Alien Breed, but I also made a black vignette that would smoothly mask the levels as it get towards the UI frame.

Designing levels

One thing that seems to surprise designers/devs when I talk about Outpost is the fact that all the levels are actually tile-based. I take it as a compliment that people think the level design is art based, so let’s go over a few tricks used to break the monotony of tiles

Each level is composed of 64*46 tiles for the floor, and 32*23 tiles for the walls. The rest of decorative elements aren’t all necessarily matching these size, as they can be overlaid “pixel-perfect” in our editor. I should take the opportunity to mention that we are building the levels directly in Flash IDE, as I came to love, for every project with Squize.

The early levels (the ones available in the demo) were designed by Squize. I was a bit reluctant to change them dramatically, as all the balancing, and scripting was already in place, and he would have slaughtered me if he had to change them dramatically. So I basically “reskined” the level directly on the old graphics. The main difference being that my level design required many more layers than the originals. Layering the levels, again and again, is precisely what made them look less “tile based” as I was allowed to break the strict tile base positioning, and overlay tiles, or decorative elements with offsets and/or rotations that give levels that typical “built in Photoshop” look and feel.

Now, one of the big challenges was to turn functional levels, that were built for gameplay pacing, into levels that would make sense to the players on a story level. I cannot claim it been completely solved, but I tried to put as much attention as possible into transforming these original levels into “places” that had a purpose and fitted the storyline (and player progression).

Ultimately, levels Movie Clips are being burnt into single images by Flash copy-pixel function, so we get the flexibility of an Art-based process, with the file size of a tile-base game – by my book, it’s a win/win situation, even though building the levels in Flash directly can be a bit of a chore!

In layman’s terms, that means I could layer how many overlays I wanted to build my backgrounds, they would all be recombined into one single image at run-time, saving us the processor extensive process of scrolling them all.

Oh… and the process is called “baking” – for those of you aware of my French origins, that sounds like an unexpected bonus

Setting up the mood

Tweaking the tiles isn’t the only trick I used to make the maps look more “organic” or “lively”. Another big element is the use of dynamic lighting. Now, for all of you 3D gurus, dynamic lighting will mean something very different – I may (or may not, who knows) have created the “dynamic lighting” term for 2D – let me explain…
Some of my tiles are drawn accounting for ambient lighting – some are darker, some include dramatic casted lights – all of this baked in the graphics of the tile itself. This is a process I used a lot for the 3D racing game, Ragged Edge, and it does help bringing mood in a 2D (or 3D) scene. However, it can also lead to very static level design. So, in the midst of baked lighting, we also decided to leverage some more “dynamic” lighting, as Flash layering option allows you for overlays, screens, etc.

These “dynamic lights” include overhead fans, flickering lights, jets of steams, etc. All the ropes used in the “horror” genre film-making are also use to build a mood in Outpost!

A lot of players have compared Outpost: Haven to a 2D version of Dead Space – I take it as a very good compliment, as Dead Space relies heavily (and very successfully, to say the least) on those film-making conventions to build tension and unease the players. If that’s what our players felt, I’d say, mission accomplished

For the record, thought, Dead Space is a game that I played very casually (no more than a couple minutes) a long time before working on Outpost: Haven – Now, tracing back creativity to its legitimate sources is a difficult exercise, but I can safely say that Dead Space wasn’t a prominent influence in the making of Outpost – it might have transpired, but it is completely unintentional.

The Splash Page

When dealing with Flash games, I came to realize the importance of the Splash page – retrospectively, I think I missed the mark on Ionic, making the Splash page a little too obscure for design reasons, and not being very successful at selling the content of the game itself.

However, being a designer, I wanted the splash page (which is technically the first page players get into, outside of the pre-loader and various sponsor ads pages) to completely “kick-ass” and go well beyond the graphic value of the game. I’m a strong believer that as makers of 2D games, we are fighting an uphill battle against high-production-values 3D games, and that we compete against these AAA titles for players attention. Therefore, I don’t believe that a scripted “live” screenshot of the game would do it any favor: I think we need to titillate players imagination from the get-go!

I decided to personally produce the first iteration of the Outpost: Haven Splash page – it would be a twist over the well-know Alien/Aliens theme, with some exciting “action-poses” involving characters/players, and tons of explosions – like if Michael Bay decided to get into illustration

(and for those who wonder, yes, those two dudes come from stock 3D models, although heavily modified!)
While the image worked great as a teaser, I thought it was underwhelming as a splash for an action game – and more importantly, it was referencing a little too much the Alien/Aliens DNA of the game – to a point where it could have led to copyright trouble.

I decided I had spent enough time on this (at this point, the game was half done, and a lot more level design, UI and sprite work was needed). It was time for Brandon Moore to step in, once more

One thing that was important for the final image, was that it was layered correctly, so that I could extract individual elements and animate them in Flash. I gave Brandon a couple of reference images, and explained what I envisioned, and let him work his magic.

After a few back-and-forth, and a couple tweaks, the image was ready to be integrated in Flash and animated – It is interesting to note, however, that the original color palette was quite different than the image currently in-game. Brandon had picked a palette revolving around gold/brown hues, and even though it looked mighty fine by itself, the image tended to get lost in the greenish hues of the surrounding UI – so, with Brandon’s agreement, I decided to shift the palette towards blues and purples, to make the image “pop” more.

User Interface

The UI work on Outpost can be divided in 2 buckets: the game UI itself, including the Splash page, various menus and credits, and the in-game various UIs, as the store or the player’s digital assistant that we use for the maps and a few game options.

For the game menus, I tried to focus on the UI to be as unobtrusive as possible, fighting a tendency that I have over-designing UIs sometimes

In game, however, I took the opposite approach – all the UIs used in game were carefully crafted to not break players immersion in the story, well, all but one…
The terminal and the player PDA work pretty well at letting the user access various options, buy ammo, upgrade weapons, etc, but the weapon wheel, retrospectively, could have used the extra thoughts – it is what I call a “meta-UI”, meaning that it’s the only one that doesn’t replicate a device that the player would logically interact with within the game world. The look and feel of the wheel works well with the rest of the UI, as it lifts colors and shapes directly from the surrounding UI, but the functionality was a tad cumbersome, and had no logical tie-in in the Outpost universe. Oh well, we’ll correct that for Outpost 2.0

Sprites

The sprite work was maybe the most straight-forward part of Outpost: Haven. We had a somewhat restricted amount of enemies, and the Alien heritage of the game kinda dictated the design for the bugs, at the exception maybe of the final Boss. Since Outpost was an “horror” survival game, and given that tiny sprites of bugs are hardly scary, I wanted something with some shock value!

I hesitated quite a while around various designs for a super-bug, but none of them was really working as the big pay-off I was after. As I was browsing some work from HR Giger, the original creator of Alien for inspiration, I stumbled upon that infamous, gross painting of monstrous babies. It clicked right away, as our story features a main villain that gets a little too deep in his veneration for the Alien race: his twisted, unborn body would be our final Boss! To add to the horror, I animated it devouring some of the crew, like a reversed-grown Chronus eating its disciples. I’m actually surprised to not have seen more feedback about the end-boss from the players that finished the game: I guess I’m the only one sensitive to the shock factor of an overgrown baby eating people .

Post Mortem

We finished the game and uploaded for Sponsors bids on FGL on november28th. To motivate sponsors, I also uploaded a Trailer on youTube. The game picked up some good momentum, and Newgrounds ended up with the winning bid. The game went live December 31st on Newgrounds – I was traveling that day to Charlotte, NC to spend the New Year with friends, and spent most of the trip (and the New Year eve) tracking how the game was doing, how many plays, etc (and a big thanks for my friends, and wife, as they were very tolerant with this, and even appeared genuinely excited by the progress!)

at the end of the night, I believe we were at 30.000 games served, and ratings and reviews were stellar – it really made that particular New Year Eve very special and exciting – and made up for the last minute hard work that went into correcting bugs, editing levels, etc! (I’m sure Squize will cover this in his own post-mortem, launches tend to be more demanding on devs than designers, although I was sharing the stress, at least spiritually )

After a month, we had over 800 user reviews on the 3 main portals (Newgrounds, Kongregate and Armor Games), 3.500.000 plays with an average of 15 minutes per play, and a game disseminated over 800 portals, with literally plays from every single country in the world, save for 3.

Most of the reviews were very positive; a few users complained about difficulty, the slow running speed of the players – or the weirdness of the Weapon wheel (mea culpa!) but generally, people enjoyed playing the game a lot.

The following day of release, we starting to see users posting walkthroughs, video reviews on Youtube – one user even took the time to translate the whole game in Spanish!

As the game started spreading, we got the honor of several reviews from gaming websites : PhotonStorm.com, Jay is Game, e4.com, browserRousers.com, and DYIGamer.com to quote a few.
Squize provided stellar “customer service” by tirelessly updating the game, correcting some major bugs and fine tuning the gameplay here and there to correct some of the main community complaints (did someone mentioned the running speed? )

Fallout

Today, Outpost: Haven is still generating a strong 15.000 daily plays, and sits on top of more than 5 million games served. We are both very pleased with the reception the game got, and by the fact that the community expressed strong interest continuing the story in the upcoming Outpost 2.

In the meantime, we created a version 1.5 of Outpost, focusing on the Swarm mode, and computer-controlled IA co-op gameplay, but that’s for another Post Mortem

Play the game on Newgrounds, and let us know if you enjoyed it!

http://www.newgrounds.com/portal/view/586969

and now, the usual screenshots

Outpost went live today!

Thanks to our awesome partner, Newgrounds for sponsoring this game: you guys are awesome!

You can play the game at this address : http://www.newgrounds.com/portal/view/586969

WASD to move – Mouse to aim and fire – SHIFT to change weapons – P to bring the handheld and pause the game

If you guys are members of the Newgrounds community, don’t forget to vote for our game (if you feel like it, of course )

If you don’t know about Outpost yet, you can check the trailer hereunder:

I have been so busy lately that I haven’t really had time to update my blog! Anyway; here are a few Work In Progress screenshots of Squize and I upcoming title, Outpost – it’s a loose remake of a very popular early 90s game, Alien Breed. Hopefully, more on that topic soon!

If you have a high tolerance for heavy (Texan) accent, misuse of words and silences filled with “heuuus” and have a remote interest in Gamification, Social Networks and Revolutions, then you might enjoy listening to the Adverve latest podcast

Bill and Angela were nice enough to have me over at their show, and since they are much better writers than me, I’ll just “borrow their entry”:

McGameification, Aka, that big, juicy badge in the sky. It was one mic/two guys as Bill took a roadtrip to Savannah to join one of his co-strategists in crime at BFG. The Frenchman Known As Cyril Guichard (@luxregina) went live and uncensored as we kicked back for a high-rolling adventure on the topic of gameification.* It’s probably a word you’re sick of, but he takes us deep into the philosophy of gaming, and why sites that “gameify” – like Foursquare – aren’t games, per se (but will need to be).

Want more? We also find a way to pose that age-old question: can social media sites like Twitter really be used to construct the governments of tomorrow? Learn all the nuanced answers to this riddle, and others, this week. WE EVEN TALK 3D. Of course we also take our trademark™ left into fun areas like politics and discuss how Gen My dealt with the end of Osama, if at all.

(Also, learn why you’re becoming a symbiant.)

Their post is Here > http://advervecast.blogspot.com/#8861499324055810544

The Podcast can be downloaded here, or, if you are like me and despise I-Tunes, directly from my site, here

Thank you again guys for having me over, had a blast!

Genesis

High Five Studios approached me to help with the graphics/Art Direction for their upcoming, first I-phone game, Puzzle Pegs. Puzzle Pegs is (or was, as you’ll see the game evolved slightly as we were working on it) a physic-based puzzle game, where the player controls a ball, and must accomplish certain combination of points by bouncing the ball on various pegs… At least, that’s how it started, if that doesn’t sound like your cup of tea, just stay tuned, cos the game ends up being quite different from the premise listed here

Giving the game some “personality”

The guys at High Five are talented coders, there is no doubt about it, and they know the game business: the first thing I got to work off was a rather detailed Game Design Document. Bliss! – most of the UI was even grayboxed, so it was rather easy for me to start diving in the project.

Now, from my “creative” eyes, a game needs to be more than just a system; it needs personality, it needs to draw the user in, to have an emotional stake in playing it. It’s often achieved through compelling storyline, art, etc. In our case, I wasn’t sure the storyline would be the right way to get people in (even though, we do have a “context” for the game to happen, as exposed later in this post). But I knew we could give personality to the game through a compelling art style!

Usually, I’m known for my pixel-art proficiencies ( Two Kingdoms, Sylvaniah, Ionic, Knight’s Quest, etc). That’s what I naturally started to explore. However, there was one problem: the game targeted both the I-phone and the I-pad as a support – this meant various screen sizes and resolutions. Of course, we could have found a way to make it work, but I felt that the pixel-art style was too much of a risk at that point.
Outside of pure technical considerations, I was also afraid that the pixel-art style would pigeon-hole the game in a retro style. The I-platforms are a rather slick support, and I felt that the game might benefit from a more modern approach.

Instead of going the pixel path, I decided to go with vectors – which is rather rare for me (at the exception of some of the graphics of K-million, I guess.)
Since the game was called Puzzle Pegs, I assumed that it would make sense to turn these different pegs into some sort of personae, that would differentiate them to the eyes of the players. The pegs becoming the central element, it seemed only natural to explore a look and feel and a logo based on one of them.

Obviously, I went with the “cute” style – I treated the world with very basic shapes and colors, but relied on subtle textures (more on that later) to give it a bit of an “edge”. The Peg really becomes the star of the show: slightly stupid (after all, it will spend most of the game being hit by a ball!) but with distinct facial features, and expressions as it’s being slammed by the player-controlled ball.

Designing the world

Now that I had the peg idea coined, I needed to find what type of environments they would be living in. I already started laying out that environment in the logo, but needed a tighter concept, that could be expended to additional worlds, so that players would be rewarded with additional environments, as they progress through the game.

I decided to go with very natural environments, each based on a season or an element, and an instantly recognizable and limited color palette. Here, you can see the “Green” nature based, summery world, and the “Blue” ice based, wintry world. This naturally opens doors for a Gold-palette, summer-ish world, and a red/orange world that feels like Fall.

As you can see on the images, the worlds are very simplistic, yet (I hope) poetic and compelling. The use of the paper-texture overlay, as well as patterned textures in the backdrop disconnects them from reality, and definitely pays homage to the handcrafted look of Little Big Planet.

All the assets are executed in vector, the textures are then added as an effect layer overlay directly in Flash. It’s a little more work at the moment these need to be exported as PNGs, but it guarantees flexibility, which, as explained later, I’m very happy I went for

The User Interface

Now that I had a world, a game look and feel, it was time to mock-up the User Interface as described in the GDD. I went with a very simple approach, as seen on Angry Birds or Cut the Rope. Buttons are rather plain, and the whole interface is pretty sober, all executed in vector, directly into Flash: no crazy textures, or glows, etc. Whether I like the sober treatment, it’s what’s popular right now

Warning, big image ahead!

What the static image doesn’t show, is that because all of these UIs are built directly into Flash, I was able to animate them all, showing the dev team what transitions, and characters animations should be.

Backtracking on the GDD

At this point, a lot of the game art was quite advanced, from my perspective. But, internally, we started having discussions: the Guys at High Five really liked the whole character approach, but felt that the Pegs shouldn’t be the main character, but instead, that the player controlled element should be the real star of the show. Which made total sense to me, eventhough I wasn’t looking forward going back to the drawing board

Another point of discussion was the gameplay: as I realized when creating the art for the various pegs, the whole game premise was rather complex and math-intensive from the player standpoint (hitting the pegs in the appropriate order to reach a particular point combination required some fast math/addition/subtraction capabilities: while there is nothing wrong with that, it could have ended up being very frustrating for a part of our audience.

So everyone went back to the drawing board – the gameplay got completely revised: the player wouldn’t bounce on the pegs anymore, but fling a character from one peg to another, collecting points on the way. This allowed for more player control rather than launching a ball once. The overall gameplay would become more paced, and more accessible to new users. The pegs started inheriting “behaviors” rather than points: The basic ones could be “grabbed” by the player, but more evolved ones would get specific properties (attraction/repulsion, explosion, etc).

Introducing Pietr the Podocculus!

Our main character wasn’t a ball anymore. It had additional behaviors and moving capabilities. In order to design it, I decided to boil it down to the fundamentals:
- It needed to be able to propel itself through the levels, or from one peg to another.
- It needed to be able to move on the floor of the level.
- It needed to be able to “grab” a peg to stop moving.
- It needed to be able to “see” the environment, identify pegs or threats.

When I say I boiled it down to the fundamentals, that’s exactly what I did: A foot to hop at the bottom of the level, and jump towards nearby pegs, an arm and a hand to grab them, and a huge round eye to see where it’s going! The Podocculus was born!

The introduction of the arm, foot and eye to what was previously just a ball opened doors wide open to lots of animations: Pietr can express more than 10 different actions/emotions!

The character was animated directly in Flash, to benefit from the tweening capabilities, and the whole spritesheet is then exported directly from Flash – there again, not the easiest way to do things, but definitely the one that is the most “modifications-friendly”.
Talking about modifications, Pietr comes in different flavors, unlockable by the player – various colors, or even body skins will be available when you play the game.

We all liked Pietr so much that we decided to also turn it into a plush-toy that could be purchased in toy stores, and would grant a complimentary download of the game, via a QR code cleverly placed on the foot of the toy.

(Re-)Designing the Pegs

Most of the pegs-behaviors also evolved compared to the original document. The challenge was to successfully convey to the player what was the behavior of the peg he/she was about to it without having to use tooltips, etc. Therefore, each peg needed to look very different from one another, and also be quite representative of it’s properties within the game.

All the pegs are animated: some trigger specific animations when it by Pietr, some feature looped animations, some move around the screen, etc.
There again, everything was drawn and animated directly into Flash, which easily allowed to repurpose some pegs (nested movie clips are a true gift for iterations!).

Level Design

It’s one of the rare case where I’m not involved at all with level design: instead, High Five provided to a couple level-designers a tool allowing them to build hundreds of levels quickly. It works rather well with my graphics, as they really are “stand alone”, as foreground or background elements, and are pretty much independent on how the level is actually built.

The current build has some interesting variations from my original graphics: coders being coder, they found ways to slightly change the lighting of my environments, for example, in order to introduce more variations (various hours of the day). It actually looks very good, and I’m truly impressed by the amount of polish these guys can come with. I know that the final product will be something I’ll be proud of!

“Your mom’s so awesome she disappeared!”

As the Pegs and Pietr were being designed, the backstory became more and more obvious: poor little alien lost in a cute world, trying to reach an escape point in each level, while collecting stars to get an high-score, blah blah blah

At some point, I thought it would be a good idea to have the exit point being the little alien’s mom. It would introduce a new character (and potentially a new plush toy!) and would contribute to give even more personality to the game.

When we tested the game, the Mom character didn’t go too well – seems that people were confused about the addition of a new character. Retrospectively, I would also assume that this new character might have over-emphasized the kid-friendliness of the game, restricting us to a niche audience. So we decided to get rid of the mom, and go for a more neutral “portal” as exit point. Seeing the final product, it was the right decision, but I still like the Mom – I find her rather funny, so I decided to revive her, and post her here!

Current State of the game

At this point, High Five Studios is securing a deal with a publisher, to give its best chances to the game. As far as I’m concerned, Art production has been finalized, although, I fully expect to have some revisions once the publisher as signed us in. A playable demo exist, and seem to gather very positive feedback through the various playtests we went through.

Here is a video of the few first seconds of the game. Some things have changed from the screens I’m showing here (most notably, the logo doesn’t show the original peg anymore – but instead, an ingame page. I still prefer the original logo, so that’s the one I posted here: my blog, my prerogatives! )

The video shows a capture of the demo, running on an I-pad. The first few levels aren’t that challenging and are mostly a tutorial to learn how to play and move the character. As the game ramps up, so does the difficulty, so expect some nightmare-ish levels after a few minutes of playing

As the game gets closer to completion, I’ll post more about the art evolution. The game is tentatively set-up to go live at the end of the summer. Waiting for that time, here are a few screens from the demo build:

Genesis

Knight’s Quest is an action-RPG, released in late February 2011 on Facebook. It mixes Hack’n'Slash mechanics (think Diablo) with a social layer as for a lot of those “social Facebook Games“. The particularity of Knight’s Quest is that it aims at a slightly different demographic, targeting the more “hardcore” players, the nostalgics of dungeon-crawling, the ones that want their quick Diablo-fix in between two posts to their friends.

Knight’s Quest was originally supposed to be a port/update of Two Kingdoms on Facebook, but the game sort of drifted in another direction, which I will explain in the “post-mortem” section.

It was produced with the folks at Gaming Your Way, and financed by Utinni Games. I was in charge of everything graphic (direction, production, and for some parts, integration…) and, at first, of the general game design.

Creating a comfy starting zone

The player starts in a quiet village, in the Goldweat Province. The village (whose name will be chosen by the player) serves as a base camp for the player: both a home and a quest HUB. The village is where most of the social interactions will take place, and needed to feel welcoming and quaint.

Often, in the old 16 bits games, the “Town” areas felt somewhat blend to me, like if designers had spent way more time giving personality to the dungeons than designing a town/village that felt welcoming. While it may make sense for a game where players never spend too long at the same place, in our case, the village is a place that players will see again and again, after each dungeon crawl, after each quest, etc. To achieve that truly welcoming feel, I knew that diversity was paramount: the town itself has more “unique” tiles than any dungeon in the game.

At that point, Knight’s Quest was still supposed to be a port of Two Kingdoms – so I was able to tap in a wealth of tiles (Two Kingdoms included more than 150 unique tiles for the village set-up, and Knight’s Quest uses 118 of them). All the tiles were created pixel-by-pixel in Photoshop, then assembled by hand in Flash.

One really nifty feature of the game is that all the level design actually happened within Flash: no need for cumbersome XML editors – the maps where assembled directly in the Flash IDE – still layered, to separate what belongs to the background and that will end up being back in a big image, and what needs to be Z-sorted with the player, in the foreground.

Using the IDE was a blessing, as Flash includes some nice features that are not always available in the custom map editors. Another nice feature was the possibility to place any element of the background wherever I wanted, without having to respect a grid based layout (although, I didn’t use that option that much, as my tiles were previously generated for a full grid based layout, and their “squareness” wasn’t looking too great with the freeform level design).

The final Village level really pushed the Flash IDE to its limits – copying and pasting tiles was bringing Flash to a crawl! This said, the result in-game is incredibly more fluid, as the biggest bulk of those tiles, the background, is baked at runtime to be one big image: all the advantages of a large image (the engine doesn’t have to move thousands of elements) without the inconvenient (file-size is small, because all that is downloaded are the small tiles).

The in-game map is rather large: the whole area covered by the village is roughly equivalent to 2000*1000 pixels: enough to have a good walk among all the houses hosting your Facebook friends!

From being comfy at home to dwelling in dangerous places.

Of course, what would be a Hack’n'Slash with no dungeons to explore?
The first dungeon is always delicate to design for several reasons: it needs to be easy enough, almost “low-profile”, so that players can learn the ropes of your game mechanics, but completing it still needs to be an accomplishment – the player needs to feel like he/she went through something epic. The first dungeon is there to hook you up to the game and leave you wanting for more.

I originally thought of BoneChewer’s Lair back in the day, when I was designing Two Kingdoms Heroes. The dungeon (or more accurately, a network of connected caves) was supposed to be right next to the village, easily accessible by the players. Because the whole Goldweat map needed to feel bucolic, it couldn’t be too apparent, hence to choice of the cave. From there, I started to come up with various dramatic stories that would support the quests and rewards pushing the players towards that first dungeon experience.

BoneChewer is a fabled giant wolf that wanders around the village, occasionally abducting cattle or small children. The villagers are too afraid to really go after it, and it will be the player’s task, as a hero, to put a stop to BoneChewer unpunished actions.

Designing the first main villain (Boss)

To create BoneChewer, I worked with Brandon Moore, a very gifted future concept artist, currently studying at SCAD (and featured in these columns for the project Ragged Edge).

I told Brandon what I was looking for:

Bonechewer: is the first Boss the player will encounter. It’s a big, scary wolf – the animal has been “perverted” by the crystals, so it glows an unhealthy green, and blows greenish smoke. I originally envisioned some sort of tribal collar made up of the skulls of its victims (stuck in the hair) around his neck

and let him work his magic – He came back with a series of sketches that were very satisfying – We picked the best iteration (I like the white wolf a lot too, but it would have looked “off” in a predominantly dark environment) and he moved ahead to the “action shot”

Brandon has been working with me for a few months, on his portfolio. I thought it would be a good exercise to take the concept character further, and refine it to a more fully “illustrated” painting. Additionally, having that more refined image would also help me greatly once I was to redraw the character pixel by pixel.

Brandon blocked the tones in greys, defined the general composition, attitude and we worked together on an appropriate color palette. I wanted a very vibrant, almost comic-like approach, that would make the animal ridiculously menacing, and after a few tries, we found the right tonalities.

Now that BoneChewer was alive under Brandon’s pencil, it was time to turn it into a game asset. I basically took Brandon sketch and started to redraw the monster, pixel by pixel – using shading brushes to give it a smoother look. Because BoneChewer was sporting some very recognizable features (the skull neck piece and the glowing wounds/tattoos) it wasn’t too hard to convert it to a small isometric asset. This is where one realize how important “original” character design is.

As usual, the frame by frame animation is what took me the most time. The BoneChewer sprite-sheet includes various animations, ranging from walking cycles, attack cycles and even a death cycle. All in all, the BoneChewer sprite-sheets sports 35 frames to cover all needed animations. Aside a few glitches on the walk animation (the poor Wolf’s hips bones are barely noticeable under the abundance of fur on its back)

Unfortunately, it was later decided that dungeons would not include Bosses, so BoneChewer and his minions never made it to the final game .

This said, I would expect to see more of him once I get Two Kingdoms under production

Giving our monster a place to haunt

All that was left ( O.O ) was to build a place worthy of our terrifying monster. There again, the concept art went a long way providing me hints for how to build the environment, the color palette, etc. Designing the cave was also an occasion to refine the mythology around BoneChewer, and I started carving a rough storyline in my head, as I was drawing the tiles.

BoneChewer’s Lair was becoming more than a scary dark pit. The bones collar around the monster’s neck hinted that the animal had once been worshiped by humans (or humanoids) … maybe fed through sacrifices. It is very possible that this stopped at some point, and that the famished wolf had to actually find its food elsewhere, which would explain its excursions outside of the cave, and the abduction of villagers, children, etc.

So, aside the usual rocky walls, dusty tiles and other various stalactites, I decided to give the cave some tiles that would hint at a past civilized presence: destroyed tiled floor, columns, totems and run-down temple elements. This also allowed to give much more personality to that first dungeon, and would allow to bring some rhythm in the level design as well.

One particularity of Knight’s Quest is that all the dungeons are randomly generated. Now, there are several ways to randomize a dungeon, so let me give a little bit more detail on what KQ’s approach is: a dungeon is basically a succession of rooms and hallways. These rooms can have various sizes, and the hallways various lengths and directions. We build, and designed all the possible variations for hallways and rooms, in sets of “chunks”, each being 4*4 tiles. The engine then builds a sort of labyrinth using these chunks to connect hallways with other hallways or rooms. The end result is a semi-designed dungeon, that still carries the feel that it has been carefully put together (for the amount of detail and level design one can inject in one chunk) while allowing the extreme replayability of completely randomized dungeons.

For those interested, you can find a more technical explanation here and here.

Giving ownership of the main character to the players

I toyed with various ways to “render” the character, from 3D models to realistic sprite and ultimately locked my choice on the “cute” anime-style characters that players loved in the Final Fantasy series, for example. There are various reasons to go with that art style: first, it’s an all-time favorite for players, but it’s also very simple to animate – the character design is simple, and the limbs don’t “fold” – particularly to create the clothes and various equipment items, it would prove useful.

The sprite sheet renders all the animations, in the 4 isometric cardinal directions. The character can walk, stand breathing, fight unarmed, fight armed, perform magic attacks, and finally, die

As you can see it’s a lot of frames! and it’s even more frames when the character needs to carry visible equipment. Character fine-tuning and equipping are staples of the RPG genre. I knew there was no way around it, so I searched for the most efficient way to handle the multiple sprites this would require.
The character spritesheet handles the “naked” character (well, technically, you can’t get naked in Knight’s Quest, you’ll always wear shorts and a shirt ). Clothes (and weapons) are independent spritesheets that are overlaid on top of the character, as shown in the following image.

by multiplying the overlays, the final result shows an animated avatar that can wear recognizable equipment. Carefully designing the equipment so that several pieces can share the same spritesheet is of course a trick to decrease the needed amount of assets … nevertheless, Knight’s Quest at launch featured a little over 55 different “wearable” items, at 92 sprites/position per sheet, it’s more than 5000 sprites designed

Designing the User Interface

The UI topic could take a whole new blog post, but I wanted to quickly cover style, over substance (for substance, I’ll pick another game ) – I’ve done a LOT of UIs, for a whole bunch of games. Going back on my portfolio, I realized that my interfaces can usually be a bit too crowded. I always like to tie back the UI to the game look and feel, and I usually use colors, textures and little decorative elements, so that the UI feels as part of the same world as, let’s say, the sprites.

Looking back on some past UIs, I think it was a mistake - Two Kingdoms‘ interface, for example, didn’t age very well: it was pretty cool when the game came out, but almost 10 years later, it just doesn’t feel right anymore…

For Knight’s Quest, I approached UI differently: I tried to keep the decorative elements out of the way of the interactive elements, and design the user areas as simple as possible, relying on slight gradients/lighting rather than texture to keep a “rich” feeling, without visually cluttering the whole experience.

So, as a result, this set of User interfaces sports much less textures, graphic work than my past work, but I honestly think it’s for the best – now, feel free to disagree with me in the comments, but that’s where I stand for the moment. I’m impatient to design my next RPG UI to see where I can take this further and refine the style…

Note: since launch, the UI has evolved in places that I didn’t designed – and that I don’t necessarily like – Unfortunately, as time goes by and the game evolves, new UIs, new sprites and new environments will be introduced, that I didn’t have control over.

Post Mortem

This was, to say the least, a learning experience.
As I mentioned in the “genesis” introduction, originally, Knight’s Quest and Two Kingdoms Heroes where the same project. Squize and I had been pitching to various investors the concept of a Two Kingdoms Heroes version for Facebook. Basically, a single player RPG experience, storyline driven, that would also incorporate key social components in its gameplay.

As I noted in an earlier post, it wasn’t too successful: we had some investors interest, but it clearly became apparent that without a working demo, we wouldn’t be able to collect the fund to start the project (ironic, isn’t it? ).

When Utinni Games offered to sponsor the project, and inject some funds to help quick-start it, it felt like a dream come true: being self employed, I had some free time (although working on the finishing touches for the space racing game, Ragged Edge, that was due within the next few months) and it was something I would have worked on, regardless.

For the first month or so, everything was going fine – everybody was satisfied, the project was moving forward, and I was getting really excited about the prospect of trying my hands in that first Social Gaming project.

Then, things got bad.

One big mistake that I made was to accept the project without getting signed-in on a somewhat detailed Game design document – this will NEVER happen again!

Instead, we started diving in making the game right away, writing the documentation as we were moving forward.

Of course, Two Kingdoms Heroes had ample documentation ( around 70 pages of GDD goodness) – but it didn’t come to my mind to get a “social-network tweaked” version of this document to our financial partner before starting the work. We all had various talks of what we wanted to make, but now, I know that we failed realizing how much our individual approach on the genre were different.

As I was writing the documentation on storyline-driven quests, dungeon design, bosses, loot, etc, it became very apparent that we had major disagreements on what that project was supposed to be

That’s where a second mistake comes in – We collectively agreed on some very generic deadlines, assuming that a lot of the assets needed for the game would be covered by the Two Kingdoms Heroes assets (I have multiple “worlds” and tilesets already created, and even mapped, for some).

As some key features were cut out of the game, or pushed against, I realized that the game wasn’t going to be the RPG I wanted to make, so I became very reluctant using the assets originally created for 2KH. It was too late to backtrack on replacing the assets that were already injected in the game (the village, for example, or some tiles in the “Caves” dungeon) and there was very little time, or budget left to create what was missing.

Now, I feel that to be completely fair, I need to explain a little bit my stance on the assets creation: although the original funding was a very honest attempt at paying our development time on the project, it was also not in line with the time actually spent on creating the various tiles that I had created for 2KH. Actually, the time I spent mapping the village in Flash, or laying out the various dungeon rooms, combined with the time creating and laying out the UI completely covered the “art budget”.

As long as this project was a partnership, to bring the essence of 2KH to Facebook, I was fine providing more and more assets at no additional cost – they were readily available, the Facebook game was supposed to be a glorified version of 2KH, and I was thinking about the long-term investment, the big picture…

But when it became apparent that very little of what I originally wanted for Knight’s Quest would make it into the final cut, I realized I was pouring my assets into someone else’s game, for a fraction of the fee I would have normally asked for. Rather than put these assets on sale, I decided to carry on creating the rest from scratch, and salvage my 2KH assets for further usage.

To add on the disastrous unfolding of  events, as the project was lingering on, I stopped being “self employed” and took a full time position at my former employer. At that point, all the “deliverable” had been met, the V1 of the game was fully functional, and I was free to move on.
But when Utinni Games decided to add more assets, to create additional dungeons, monsters, etc, it was too late – I wasn’t able to commit to their short deadline, as I could have been if I had worked full-time on it. That marked the end of my collaboration on the project.

Learnings and final thoughts

I think that with a stronger document to start with, and to agree upon, a lot of this could have been avoided – if I had understood at first that Knight’s Quest was to become Utinni’s sole responsibility and property, I would have created everything from scratch on day one, and we would all be in a happier place now – (however, the game would certainly be thinner in terms of assets). Instead of what, I feel robbed of my “baby”, and I’m sure that on their side, they feel that they had to put up with some sort of diva. in short, the experience has been a headache for everyone involved.

As far as the final product goes, the frustration comes from knowing the potential that this game had to provide a deep RPG experience within Facebook, which, to my knowledge, no social game have done yet. Instead, in my eyes, Knight’s Quest is a very well executed, pleasant RPG, but that really never deliver the goods to keep me playing. I have no sense of progression, I don’t care much for any of the places/dungeons or enemies, because there is no story to cling on – or because there is no dramatic payoff, like a boss to beat.
Basically, I don’t have a sense of purpose, which I believe is one fundamental aspect a RPG should deliver on.

Indeed, I do believe that dungeons need climatic ending, with Bosses, to tell players that they achieved something epic. And these Bosses don’t impact the dungeon replayability – quite the opposite, as World of Warcraft clearly demonstrated.
I do believe that piling up dungeons and quests in the same hub is a mistake, that players need visual and intellectual progression – from a village, take them to a town, with more houses to populate, and new logical (I mean, logically related to the area) dungeons to explore. Sense of progression is a must have.
I do believe that storyline shouldn’t be sacrificed for replayability’s sake – that if you are going to send players slay spiders more than once, you’d better have a good reason to do so.
I do believe that throwing a few dungeons and a few baddies in the mix, for players to kill, isn’t going to make a very compelling experience without an over-arching goal, something big to defeat, or an intriguing story to unveil.
I do believe that RPG stands for Role Playing game, and that the first two letters are the most important – and that playing a role when you ignore the context is a difficult task
I would argue that randomization of dungeons floor plan is not as an “acute” factor of replayability versus well designed content, clever and climatic floor plans, that people want to experience more than once – beating a labyrinth because you came to learn it is a powerful thing, particularly if the place has a fun design, and if you can somewhat relate to it as a real, scary place. Now, randomization of rewards, in the other hand is a compelling “replay” factor, but that means that you need to have bosses, and multi-drop tables per boss

Well… there are many things that I believe, and that are not in this game…yet…because I’m sure it will have to happen, by players’ demand, or investors requests.

Knight’s Quest has been reviewed twice, and aside the reviewers being occasionally too demanding for a game that they tested in “beta”, I agree with a lot of points mentioned – no need to cover them in this post-mortem

Read the first review at: http://www.insidesocialgames.com/ and the second at : http://www.gamezebo.com

In a sense, this whole experience is laying out the bases for what my next RPG on Facebook should be – and definitely brought to light some weak aspects of my original game design on 2KH that will have to be corrected to provide the best, hardcore, gaming experience on the social network.

I’m just terribly disappointed that Knight’s Quest couldn’t be the opportunity to do that

You can play the game, and see for yourself, on Facebook, at this address.

Additional material

Since some UIs or elements of the game were cut, I thought I’d post here the mock-up screenshots