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.

The classic Amiga Hit, Alien Breed, released in 1991, by Team17

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.

The demo version I started working on, while using "old" graphics, was already pretty polished.

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.

The exact same level, and UI set-up, dressed with my graphics, this time.

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.

Some tiles, walls, and level elements from the Laboratory level

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).

The original first level, as laid out by Squize

...and the final layered version featuring the redesigned tiles.

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

The First Outpost Splash Image

(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.

Various steps of the Splash image creation, including the original, more muted color palette

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

Splash page, Mission selection, Briefing and Credits pages

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

A selection of some of the in-game UIs

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!

HR Giger's monstrous Babies

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!)

Checking the game release progress on my tablet, as I'm preparing the New Year Eve's diner: Yum!

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:

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!

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.

A good GDD makes working on a game so much faster and efficient!

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.

The 2 environments created for Puzzle Pegs

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!

Most of the game UIs, shown in both available environments

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.

Pietr various colors

(Re-)Designing the Pegs

Various animated 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)

Various BoneChewer concept art

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.

BoneChewer final color palette

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.

Some of the hallways and room bases designs that allow for dungeon randomization

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? ).

Disregrad the "Collect Taxes" and "Store" buttons - they are later, unfinished additions

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

You can move your friends in the village houses - I originally wanted to be able to enter the houses, and see the Friend's avatar "in situation".

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.

Spiders... Getting killed since the invention of modern RPG

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.

the light is always at the end of tunnels

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.

The Facebook Store

Additional material

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

The intended "Homepage" for the player to see its network progress and achievements, upcoming dungeons, loot, etc

Loading pages were also supposed to include useful tips

The loot box allowed for baddies to drop different items for the player

An Epic battle versus a dungeon Boss

2010

This being the last day of 2010, it’s the right time to look back at the year behind, and set the expectations for 2011

2010 has been an interesting, and quite frantic year. I left my job as an Art Studio Supervisor at Electrotank - I went full-time as an Independent Game Developer for a few months – and ultimately re-integrated my previous-previous job, as a Senior Art Director, in my former company, BFG Communications.

Aside from the career switches, which were motivated by various reasons, I’m rather happy to have output more games this year than I ever did before. So let’s look back at what was worked upon this year:

K-Million (released) – February

K-Million was a quick, and very pleasant, project with the coder from Alilm. It’s a very fun, family friendly puzzle/shooter that can be played here and covered by a few posts in this very blog here.

Top Tank (unreleased) – March

Top Tank is a re-skin of an existing multiplayer game, from Electrotank. To my knowledge, it is still unreleased to the public – but has been shown at various conferences to illustrate the capacities of Electroserver. The re-skin includes, of course, new graphics, but also a few new gameplay elements.

Game Developers Exchange 2010 – conference – April

I had the pleasure to be invited to give a talk at Savannah’s Annual Game developers conference. I talked about some of the design challenges (and solutions) one can run into while designing Virtual Worlds. This was a very exciting experience, and I hope I’ll get more occasions to speak publicly, about games, in the future. This talk was covered by this post on my blog.

The Indie Plan – Mai/June

At this point, I was still full-time employed, but really wanted to push my activity as an independent. Various opportunity were rising, and I was really committed to give them a shot. This wasn’t necessarily my most successful period, but hey, I’m glad I tried

One highlight for this “research” on how to successfully transition to a full time independent artist was the presentation given to the Mochi fund – selling my long-time project “Two Kingdoms Heroes” as a Social-Network friendly RPG, backed by rather solid business opportunities. Unfortunately, the plan didn’t raised enough interest from Mochi for them to commit to the game, and this project evolved into “Knight’s Quest”.

Ragged Edge (Released) – July/November

Ragged Edge is a futuristic space racing game, developed with French Company DK-Games. It runs on the new Samsung Mobile OS, Bada. The game was developed for the Bada Developer Challenge, where our game ended up in the top 10 of it’s category, but failed making it into the top 3 (where the real meat of the rewards was). Regardless of the competition, the game was a very fun project to work on, particularly because it was the first time I was making 3D assets. We will continue developing the game in 2011, possibly on new platforms.

Elysium / Old World (unreleased) – September

Elysium is an undisclosed project for Electrotank. Parts of it have been released to the public as “Old World”, through Jobe Makar’s latest book.
It’s a massive project, and one of my favorite when I was working at Electrotank. I did various maps and UI elements.

Knight’s Quest (Released) – July/November

Knight’s Quest is a social RPG, designed for Facebook. It was originally based on Two Kingdoms Heroes.
The game ultimately strayed away from the original design, to a point where I didn’t felt comfortable continuing using the original Two Kingdoms Heroes assets anymore.

However, at release, the game, at the exception of the second optional dungeon, is completely based on the assets I created.

2011

with 5 games made during 2010 (not counting the “big one” that I cannot talk about, due to Non-disclosure agreement) including 3 released ones, my “game-making” goals for 2011 are rather obvious: I’d like to release more games this coming year. I’d like to collaborate with more talented coders, and take on maybe smaller projects, that can be finished in a timely fashion.

As far as larger, on-going project go, I intend to create more tracks, universes and ships for Ragged Edge. I’m also looking forward to get over the somewhat disappointing experience with Knight’s Quest by working on the Facebook RPG Two Kingdoms Heroes was meant to be.

I’m also committed at updating this blog more often, with more “work in progress” posts, and maybe more articles on other people’s projects…

Well, these are good intentions, for sure – with a rather demanding full-time job, it’s going to be a challenge to keep (and improve on ) last year’s pace. Stay tuned, the 2011 posts will for sure be a hint whether my good resolutions were achieved…or not

Happy New Year!

This post is password protected. To view it please enter your password below:

Password:

As some of you might already know, Ragged Edge has won the phase one of the Samsung developer competition. YAY! we made the top ten of our category!

Now, it’s the tough part: we have to try our best for phase2! please everyone crosses a few fingers for us!

For those of you that don’t know Ragged Edge yet, let me present you the game (I posted some screenshots at the end of this post):

Ragged Edge is a space racing game, in which you pilot ships going on some loops-crazy tracks, at insane speeds (with the right power-up, you can reach 600 MPH).
The game plays really fast, and is a lot of fun so far! (more on the game itself in a few weeks, once the final product is released)

Genesis

Ragged Edge is a long time project of French Coder, Christophe Kohler, at DK-Games. Christophe is a veteran Playstation/Playstation2 developer, turned cross-platform specialist.

He originally approached me to take care of the User Interface, and everything 2D in the game, and I offered him to give a shot at also creating the 3D assets. That was definitely a risky move, as I barely ever touched a 3D program in my life, aside the 14 years old modeler AMAPI (and now long gone and unsupported).

3D assets

I will spare you the details of “learning” 3D Studio Max (although, it is definitely easier and more logical than I was expecting it to be – at least, for what I needed to do).

Let me just say I was happy it was a space-themed game, and not a pony-racing game, for example, as I can imagine that it is way easier to modelize spaceships from cubes than it would have been with any organic shape.

Indeed, the space elements were rather easy to model, once I understood the tricks. Most of the models are actually very simple combination and extrusions of 3D primitives, such as cubes, spheres, tubes and planes.

The Face extrusion tool was intensively used in the process, as well as Boolean combination, to arrive to the final shapes of each asset.

Each model has a very low poly count (albeit, not as low as a real 3D pro would have certainly achieved – I still need to learn the trade).

The next phase was the dreaded UVs unfolding. For someone that never really worked in any 3D package, it was quite something to engage.

Few trials and errors later, I was finally able to unfold my textures flat, and get ready for texture painting: that’s where the real fun begins!

Texture Work

If I learned one thing of importance in the whole process, it is how important is the texture painting. Some of my ships went through various texture tryouts, and I believe the later, final work really makes the simple models shine. A good texture allows you to bring much needed complexity and details in very simple shapes, and helps make them interesting on-screen.

A textured model for one of the playable ships

Textured UVs for the same ship

Luckily, texture work is pure 2D work, which is something I know better
I approached the textures the same way I usually do with flat pixel work: a combination of photographic textures heavily edited, with a lot of little details baked within. I tried to also bake a lot of lighting in the textures, to help reveal the various volumes in game (even the ones that are purely baked in the textures, and not part of the model itself).

I know that this section is certainly very generic and boring for people that work with, and know, various 3D packages – but for me, it was a true discovery – and I enjoyed every minute of it (to a point I had to force myself to put the program down in order to get moving on other projects, etc)

3D is truly addictive, and I can see myself playing with it more in the future!

Another textured player ship (this one is the first originally designed, and visible in the various screenshots, at the end of this post)

Textured Model for the Racing Starting station

Level Design

As I said previously, the game was a long-time project of Christophe, so he had a lot of ideas, and wish-list for the level design. Christophe built the levels using a custom MAX plugin he developed.

His original idea was to keep all the tracks in space, but have them built around visual landmarks. We decided that our first track would be built around a huge space station, and that the track would unwind thought various thematic sections, around the Station.

I made a quick “suggestion” mock-up in Max, and Christophe build the circuit, making sure that it was long enough to provide a significant racing experience, that the track would always go through, or around something visually interesting for the player, and that the various curves and loops stayed playable at high speed.

The final result is quite close to the original idea, and very fun to play.

Finalizing the track also meant having a few different road textures that make the road a true actor in the game, and always interesting to watch.

Some of the Track textures

There again, like the ship textures, I used Photoshop to create various tracks, some of them “position-themed” (starting track, warning areas before tight curves, etc).
I also used a lot of different lighting effects, to give rhythm to the track, make it visually interesting, and enhance the sentiment of speed.

Creating the Splash screen

I wanted to have a very visual “splash screen” to set the mood of the game: an illustration that had a lot of energy, crazy angles and over-the-top action, to catch the player as soon as he/she starts the game.

Brandon Moore is a young, but extremely promising Illustrator. He studies at SCAD, and also work with me on various “portfolio” material projects (you will definitely see more of his work in this blog )

After receiving his brief, and some screenshots/models, Brandon provided some rough proposition thumbnails

Various action shots mocked up by Brandon Moore

We agreed to pick the bottom right corner proposition for the final illustration, while adding the starting station (can’t help, I love that model )

Brandon final illustration is extremely polished, and completely captures the essence of the game: I believe it’s a very good introduction asset to our product: Well played, Brandon!!!

Final Illustration from Brandon, with a few details thumbnails

And now, the screenshots!

These screens illustrate our first delivery to to competition. As we get closer to the final delivery, our product will be polished, more track will be added, etc (and I will post more screens in the future )