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 Mydealt with the end of Osama, if at all.
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!
Pietr in Action
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:
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
BoneChewer in action
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
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 Quest log was making tracking multiple quests at once somewhat easier
The loot box allowed for baddies to drop different items for the player
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-Millionwas 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
Ihad thepleasure 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
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 )
The Curse of Sylvaniah is a Action/Platform game that I worked on, in collaboration with Mattias Stridsman, aka Strille. It was released in November 2004 and was an instant success across multiple portals: within a few weeks, the game served nearly 15 million players, and even got covered by a Spanish Game TV program.
The whole project started after coder Strille had released his supertile-based engine, using Sonic graphics. The engine was quite a step up, in the world of Flash based platform engines: it performed extremely fast, and was way more flexible than most of the engines that existed at that time. Such a beauty was screaming to be turned into a “real” game, and not just ripped graphics of a well known license
By the time, I had released Two Kingdoms, which was well received, benefited from some attention from Flash developers, and I had been in discussion with Strille for a little while on a possible collaborative work. Both of us had nostalgic memories playing Ghosts’n'Gobelins, and with such an engine on our hands, the next move was a no-brainer.
The Story
The Levels map (zoomed in)
While not being very important for the gameplay (well, less than let’s say, a RPG) I wanted to flesh the Lore of Sylvaniah a bit, and explain a little the level progression through a simple storyline.
The Realm of Sylvaniah consist of a giant, idyllic forest inhabited by Elves, Tree-Ents and all sort of magical plants and animals. Unfortunately, all of this changes the day the dreadful dragon, Røyk enters the realm and pick the highest mountain to hibernate. Even asleep, the dragon still exhale deadly fumes that darken the skies and corrupt the fauna and flora of Sylvaniah. Magically preserved from corruption, the Elves decide to send their best warrior in a perilous journey to slay the dragon and free their realm from its deadly grip.
The Game
Levels unfolded to follow the storyline: the player would start in the Forest, then would reached a burnt-down town, before scaling the mountains to assault the sleeping dragon. Levels were laid out directly in Flash, using the supertiles system Strille had designed. The whole system, combined with the way our character moved made it very easy to mix the classic horizontal level unfolding with more vertical approaches: while the first level was basically played from left to right, in a very classic horizontal layout, the second level tricked the player a little bit: Players would run all the way to the right to discover a dead end, and realize that the key to the level was to actually scale those very high trees. The vertical design here is one of my favorite moment of Sylvaniah, as it completely took players of guard and significantly upped the challenge/danger already present in the game.
The options even featured a fully working dev console, allowing debugging testing directly in-game.
At the time, we got quite a bunch of comments about the controls (they are all customizable, by the way ) – and the game still generates some discussions on that level. I believed then, and still do, that the control scheme is just fine. Yes, the combo keyboard+mouse isn’t a very popular one, but once mastered, it gives you the precision and “control” you would expect in a platformer like Sylvaniah.
One thing to note is the amount of “customization” the game offered, which was pretty rare at that time: Strille really went the extra mile to allow the game to perform well of the largest range of machines possible, and players had a lot of options to turn on/off most of the game’s features!
One last noteworthy point of the game was the save-and-replays. I believe that Sylvaniah was the first Flash game to ever use such a powerful system: Each game input by the player were recorded, and saved with the hi-scores. When browsing through another player’s hi-scores, you could actually see them play the game, judge their performance, and learn tricks from the best players. As a designer, it was really gratifying to see how other players played through the game, and I learned my share of tricks by watching other people’s take on the level I had designed . If we had been further with the rest of the levels, it would have been a great feedback asset to design better, more challenging levels!
One interesting thing to note is that the whole game is written in ActionScript1!
The Art
The Curse of Sylvaniah shares a LOT of DNA with Ghosts’n'Gobelins, and more specifically, Super Ghouls’n'Ghosts, its more recent iteration. As for most of my games, Sylvaniah attempts to resurect the glorious era of rich, colorful 16bits pixel-art graphics.
Some of the graphics used in level 1
example of assets breakdown
Tiles
As said previously, the engine was tile-based, so the graphics had to be split into tiles that could be arranged and repeated on the map. But that’s where the supertiles system created by Strille was very convenient: I was pretty free on the size of my tiles – this means that elements that would be fit together would need to have the same size, of course, but from one set of element to another, I was free to change the tile sizes.
To give a concrete example, all my floor tiles, because they were meant to fit with one another needed to be one size, but the trees to would stand on top of the floor, or behind could be sized differently.
This proved very convenient, and much, much faster when designing levels and breaking down assets.
Background
In addition to the levels graphics, I wanted to have a very rich and vibrant background that would set the tone for the game (and help visually integrate the foreground elements. The graphic used had to big very big, to accommodate both the horizontal and vertical scrolling, keeping in mind that the levels in Sylvaniah are rather large.
The background was created in photoshop, combining photographies, hand painted elements, and digitally painted graphics, using very similar techniques used in mate-painting.
The whole setup was varied enough to provide an interesting scrolling backdrop, while not taking anything away from the foreground, where the game “really” happened. The general mood of the backdrop evolved from left to right, from “light” to “dark” and was reminiscent of how I wanted players to feel, as they were progressing further from one level to the next.
Sylvaniah was using only one background at release, although several (one per level) were originally planned.
Sprites
Sprites were handled a very classic way, mostly through spritesheets (meaning, one render per animation).
A notable exception was the end of level Boss, the Tree-Ent. Because of its sheer size (almost the full height of the screen) it would have been a very heavy spritesheet to generate the usual way.
Instead, we went with a Rag-doll approach: each moving limb was cut into it’s own asset, and assembled and animated within Flash.
This had two main advantages: first, the overall weight of the sprite was much, much smaller (no need to generate each step for an animation – but also, repeated limbs like legs and arms portions were only exported once). Second, it allowed us a much smoother animation, as the transitions were tweened, and not hand animated, unlike the other sprites.
This end-of-level Boss really needed to stand out, as a reward for the player, and I think that our approach really nailed it!
The player spritesheet was of course the one that required the most work. In-game, our character could use a lot of different weapons, and perform multiple actions. Each of these needed to be animated, on a basis of at least 4 frames per animation. The complete spritesheet for the player includes over 60 frames of animation!
Overall, the sprites drew inspiration from many classics, and even though I think that some could have been better, the look and feel of the game, at the time, was rather uncommon for Flash games.
Reception
When the game got released, it gathered quite a bit of attention! Strille’s engine was already known as one of the fastest and most efficient Flash platform engine. This existing popularity, combined with the brand new graphics and IP, and some refinements Strille had brought to the engine (Ropes physics, for example) really brought The Curse of Sylvaniah under the spotlights.
And that’s where the somewhat sad part begins.
In a matter of days, our game got hacked, decompiled, stolen or hotlinked on various gaming portals. We had some loose plans to get some sort of sponsorship for the game, but hadn’t really come up with any battle plan yet. It was too late: the game already had gone viral, and could be accessed on dozens, if not hundreds of portals linking to it, or even worst, embedding the stolen file at various screen sizes, aliasing or distorting the graphics.
The site hosting the game got literally hammered with intense, constant traffic, bringing our host to its knees. Within a month, the game had served well over 15 millions sessions, and counting. At this time, Sylvaniah.com made the top 100.000 of the most visited websites in the world (90.000 something according to Alexa.com).
We never made a dime on this game, and if it wasn’t for the generosity of our host (Nils at 2iceMP.com - if you read this Nils, give me a shout ) we would have lost quite a bit of money!
Post Mortem
Some of the research and concepts that were done for Stage 2
Well, first and foremost, I learned a valuable lesson: don’t-ever-make a pre-release for a game you haven’t secured a sponsorship for yet! – NEVER!
Aside that, the whole project was a blast! It was my second “real” game, and working with Strille has been smooth as ever. The project was completed in a timely fashion (6 months from idea to completion, working on week nights (some) and week-ends(all!)) and got very positive feedback. As with Two Kingdoms, it helped me put my name on the map as a game designer/illustrator, and generated “professional” contacts and friendships that are still kicking in nowadays
Strille got very busy, and ultimately landed a job in the game industry – I got busy as well, and we departed ways, never really finishing the rest of the game levels. At this day, only the first 4 levels are accessible, the rest awaiting to be finished…
The Curse of Sylvaniah, thanks to Nils dedication, is still available for play here : http://www.sylvaniah.com.
(if you feel like it, of course 
)
.
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).
Sprites were handled a very classic way, mostly through spritesheets (meaning, one render per animation).
Andre Michelle