This article is about my thoughts, ramblings and rantings about the development of Drop Da Piew.
Bear with me, I’m not a native English speaker, if you find spelling/grammar mistakes in this document, please be kind enough to point it out in a comment, I’ll be sure to correct it.
Drop Da Piew is my second finished/released game. Like my first game Space Jinx, it was made in the frame of a contest on Scirra.com.
From the beginning of the development I already had the idea to release this website to support it, I wanted the game to be some front end of what can be done as a HTML5 game (on my PC the game is fluid on FF and Chrome, the sound plays good and the general gameplay/controls work as expected/designed so far).
One thing I know though, I’m not an experienced graphic artist. I can make some stuff in Gimp, enough to have some elements that fit enough to feel like a game, but I won’t brag about any skills there. What I had to heart though was to rely on my tastes to provide some coherent aesthetic. And I think I did.
The simple graphics (easy to silhouette shapes, simple “main character”, coherent “roundy” UI) along the gameplay and the sound/music (mostly done by voice) give a light tone to the game, when the challenge is not that easy to overcome.
On start of the development, I also knew I wanted the players to be able to make and share their levels. Also, to provide play for the user, I needed to provide levels anyway and so needed a tool for making the levels. The levels provided with the game were made in the very same editor the game provides. This also allowed me to be sure players could make playable content.
A point that feedback brought me: achievers like score.
I had implemented a score system early in my design and hadn’t really put much thought into it more than “how to compare the way two players played on the same level ?”.
Considering the level is displayed the same for both players, the rotation degrees are the same, the blocks, the locked and unlocked handles…
That’s where the movement score appeared. As any mechanic, it needs some feedback, so while the the user is grabbing the handle, I displayed the current movement score the move was to make.
It was displayed in red and added points to a starting null (0) score on ungrab and jump.
Playtests returned me that it was confusing and the idea of having a set score from which the current movement was removed from was proposed. I had already thought about it at some point in the development and believed it would be too hard for me to explain simply through the game.
Finally it turned out to be what the game needed in my opinion and it makes sense. Not for 100% of the users, but enough hopefully.
The feedback I was able to get from the WIP versions/first public releases was really a great help.
And here brings me to an important lesson: PlayTest is everything.
Getting as much feedback as much and as early as possible and all along the way. I know I failed at that, once again. But on the other hand, as late as I did have playtests, it ended valuable.
As I were building the game mechanics I had some early playtests for them in the irc #Construct room. where I idle most of the time.
I also have had help for some of the maths formulas I needed and that make the mechanics.
I know the people there, the people knows me and we are all mostly game developers. It allows to get some feedback without “ass-kissing” nor condescension.
And it’s various feedback too, touching wide areas/aspects of the game.
But for a long time I “went under” adding stuff, “making my game as I planned”.
Showing the game to selected people and analysing their feedback, I was able to direct the game in a more efficient way.
The Piew theme only arrived less than two weeks before the (extended) deadline.
It allowed me to lighten the game and the UI and to go back to the essential.
As usualy said K.I.S.S. (Keep It Simple Stupid). And indeed, I was going in too complicated/bloated ways.
I had too much lists, too much informations displayed, the whole presentation was too bloated, too full of itself.
A close friend made me notice. In two nights, I had removed most of the stuff and the Piew were born.
From this moment, the sound direction became obvious and I was able to fulfil my wish for coherent and light aesthetic.
Another thing I learned from this game: Extreme programming is manageable in C2, but you really need some solid base knowledge of making games, using C2, and even then you’re in for some hairs pulling and teeth grinding.
Nevertheless, it’s fun, and as I said still manageable (the version for the contest is 882 events spread in between 6 event sheets and 4 layouts)
Using only the comment as TODO/DONE lists helped, as well as focusing exclusively on this project.
I still recommend to write down and plan what you want your game to look like, do, it will earn you some valuable time.
Working for the Scirra Arcade also brought his fair share of challenge and frustration.
For this project I would have loved a built-in “Function” plugin/system. I know there’s rexrainbow’s “Function” plugin, but one of the requirements here was to upload to the arcade, and the arcade does not support third-party plugins (yet).
Interface programming is tedious without function. And families would have done me no good. I did not use the families at all for this game, they were released as beta in the middle of the development, I did not wanted to incorporate it on the fly with the bugs risks.
Moreover the game itself stood manageable without them despite the tediousness of making interface without a function plugin. (Yeah, that really frustrated me a lot while making the interface)
Another important point I had in mind, was a lesson learned from my first game.
I wanted the “tutorial”, the teaching/learning of how the game plays to be natural and progressive, and not just reading a lot of lines.
I remember games from the 90’s had an introduction with lot of text (later voice-over), tutorials were also about fixed screenshots and quite some text to read, it doesn’t cut it anymore in 2012.
In my playtests, I was told at some point that I should have something like a video showing the gameplay. It is a possibility.
For various technical reason and the fact that I still wanted the user to be active in this learning process, I chose not to go this way.
As I said I wanted the user to be active, and so the first levels provided with the game act as tutorial.
The very first “Let’s begin” teaches well the goal of the game in my opinion.
You press the “Drop” button, a Piew is dropped in the device, reaches the Nest, the level is completed, congrats.
This clearly teaches the principle of the game to the user. Action/Reaction/Reward
The second level teaches another basic of the gameplay, moving a handle.
It also happened that a lot of players believed they had to move the handles “in real time”, once the Piew is dropped.
At the very beginning, that’s what I had planned too, to be honest. Once again, for technical reasons, it was better to have this “delayed” gameplay.
And so this second level also teaches the player that he’s supposed to “prepare” the way for the Piew BEFORE dropping it in.
It wasn’t really planned, expected, but apparently did the trick.
Then the next levels display (in my opinion) the effect of the shapes on the Piew, but through levels where the only interaction is to drop the Piew.
That’s probably a mistake on my part, not following my own motto of letting the user have interactions.
I tried to correct this along the rest of the levels, proposing different possibilities to experience the different effects.
I hope it does the trick.
I don’t really have ways to know though. I’m bound, as far as feedback on forum or IRC goes by what the people are telling me.
Unlike playtests where I’m hovering over the shoulder of my Mum as she tries the game and see her reactions, questions, attitude and get more data from it, data she wouldn’t even think about giving me, since it’s about psychology and thought process, sometime even not at a conscious level.
That’s a very interesting matter to deal with though.
Man hours of learning and tweaks could be achieved in the very specific range of “teaching how to play the game” and a critical point belonging to the “5 first minutes” time period in which you hook or lose potential gamers.
Seeing by the voting results so far on the arcade, I guess I still haven’t made a good enough job on this part though.
I guess that wraps up this article about the development of Drop Da Piew for now. I hope it has had some interest for you as it had had for me laying my ideas down, making the point after two months spent head down in this project.
Don’t hesitate to register on the site and leave comments or levels and scores !