Future Development

Now with playtesting over, I believe it is time to talk about the future of this project. Since playtest has so far been positive, after asking my muse if she would be willing to help me complete the project and take it beyond, to which she responded very happily, admitting that she felt a bit privileged, but that is only due to the nature of the circumstances.

One could divide the future development of the product into four main columns:

First, the aesthetics. From an aesthetics point of view, what is important is to finish all artwork and polish that. Firstly, model and animate the character. Make the player feel attached to it by polishing the main character as much as possible. Afterwards, start modeling the environment and by that the direction will be of using clouds as inspiration and making them look somewhat cut-out, similar in vein to Little Big Planet. Afterwards, creating different enemies and modeling them and creating the ocean will be all that’s left before going alpha and testing it again.

Second, the sound system. That has to be done from scratch but with an aesthetic already planned, that should be more than possible. The music might be a bit harder as tense classical music is a bit hard to find, and Wagner sounds a bit too epic rather than tense. The sounds will have to be taken off the internet but I plan on doing it on a pre-alpha stage so as to map exactly what is needed and then proceed according to that.

Thirdly, the levels. Using what I have so far and what will be built further on, I will want to build a lot of small levels that take full use of the mechanic of rotating a 2D space in order to use a 3D space environment. Probably creating similar worlds would be a plus as it would give the player a sense of progression and then dividing everything into chapters. Currently, I am planning on working on a demo, thus I believe that the first chapter will be up in the heavens and use the mechanics found there. That will also be what will be developed and released as freeware. If there’s enough public support, the rest of the chapters will be released as episodes through sales.


Fourth and final, the programming. The code will have to be slick, clean and as free from bugs as possible. Besides that, new mechanics or enemies have to be prototyped and turned into prefabs. Using a modular approach to building the code and levels would decrease time spent on production significantly and allow for a better flow of assets within the game.

That being said, I hope to actually do as much as possible with this game and if possible, submit it to an indie or student contest. It’s a good enough game I believe that will use what Fez has started and take it to a different level.


The Muse’s last playtest

We had our final playtest. You can check the build over here: http://www.vtanase.com/Files/UxP_Prototype/WebPlayer.html.
I’m not sure if I have uploaded the build that I will be handing in, as it has a couple of minor modifications but even though I had planned to have it be the second last playtest, due to external events it ended up being  cancelled and further playtests will have to occur should I choose to develop it further. (Check my ranting on housing in Denmark for more details).

The results of the playtest were quite positive. They were not only positive though, bugs were still found, nonetheless, her overall impression was that it had evolved quite well since our last test. I had to take out the music and I will have to compose something different, the reason being that it was too peaceful and not tense enough. I guess that is a problem with classical and baroque music, though I believe I shall still use a string quartet for that case, even if it will be all made using a sound composing program. I have also gone through the art style that I have thought of for the game and reached an agreement on many points. In the end I believe this game will be fantastic once it is complete. Currently, I believe that it is important to create every element and test it and then have the levels simply fall into place. Continuing to work on the prototype to produce something better is the next logical step I think since every playtester has not stopped at the first level, but has continued trying it out several times over, showing that there is something “fun” in all of that which keeps players in. Something that could be tapped into to produce something good.

Playtesting with others

If you do a user-centered approach to design, should you allow others to try your game? The Answer: YES!!! Even if you are designing for a muse in particular, attempting to test on a user level allows for more flaws and quirks to be seen than through one person and besides that, one could see if the game is fun for more people than just you, and that is not just important, that is vital! Having the game be accessible and seem fun by many people is what makes the difference between a good game and a bad game. Make your game friendly. Make your game polished and inviting. Have players get sucked it and have the theme elements flurry them so that to daze them.

Besides that, what else could one learn through having external playtesting? Well, for starters, one could get fresh input. Your muse may know what you are trying to achieve or may have the experience of trying the game earlier in production and then getting accustomed to it, or in other words, start loving it. This could make her  less careful about what the game is supposed to transmit in general and it could make her not notice certain bugs or elements that are supposed to be different.

External playtesting is also good for PR purposes as they can not only provide good feedback, but they could be used to create hype around your product which in turn could lead to a good turnout in sales, something that if you want to sell your game, you should do.

Digital Considerations

Time for a post on my reflection of what tools to use when going digitally.

In order to properly Assess, I guess I should go through each of the skills in order:

Programming – I’m good with it, I have a bachelors in it. This means that I can handle most code you can throw at me. This means that I might be using something that could be complex as well. For this reason, I have to choose between Actionscript, Java and  C# (Unity 3D) but due to the fact that Java does not have a proper game engine so to say and Actionscript is not something for the future, Unity was my prime choice regarding programming as it is not only growing, but it also looks ok on your portfolio.


Art – Here I guess my skills are a bit lacking. I’m not that much of an artist I could say, except some vector graphics and pixel art, I’m not that great. I’m a newbie when it comes to modeling despite having done a modeling class and I have no clue when it comes to animation. Animation is like a foreign language to me, one that I have not yet had the time to properly learn. Thus, I will try to keep this to a minimum if possible, try to make my prototype mechanics work first, then focus on the game. I will most probably be using Adobe Illustrator and Photoshop, since I have some experience with them, while I will be using 3D Studio Max for modeling.


Sound – For this I will be using Ableton live, as well as cool edit pro when it comes to editing sounds. Ableton will be used exclusively for music, except some quirky sounds that might need an instrument to produce, while environment sounds will be taken off of freesound.com or similar sites that allow of free use of sound samples. I will probably be doing sound last as it has to fit with the art design and with the general flow of the game and one could get a better grasp of these once they can better see them.

Rice Pudding Interviewing

Now with a new muse, it’s time for the interview. I have decided to sweeten that up by using rice pudding to bridge the gap between us, but before I go further into why it’s good to pamper your muse in order for her to open up, I’m going to present my muse a bit.

She is Korean, around my age, and is a non-gamer, again, though we have played a couple of board games on and off again with friends of mine, every thursday before dinner. That way I noticed her style of play a little. She did not like acquire or munchkin but she really enjoyed Guillotine, showing that she likes simple games. Not too hard, not too complex, but simple. What made me choose her as a good contender for a muse was the fact that she was my flat mate which made things a lot better in terms of communication.

Now, back to the interview. It is important to get to form a cozy atmosphere for you and your muse, and I mean cozy, not romantic. This opens up the minds of both parties involved and allows one to be comfortable to open up, even to describe little quirks about ones personality. Why Rice pudding then you might ask? Simple: Because simply she did not ever have it, despite the fact that she is Korean. Actually, since then, I showed her that you can actually buy and that’s what she’s been having on a weekly basis. That and she started playing her favourite game, Rayman again. That’s good now, isn’t it? It means our discussion was simple enough to make a connection in that she learned new things and started fixing her nostalgia, while I gained vital information to my project.

Going Digitally

With a new muse, I set about to a difficult task: research on the muses likes and dislikes, create a paper prototype and then create a digital prototype, all in 10 days. Researching was easy: just sit down and talk to your muse a couple of time, finding out what her likes and dislikes are. The hard part is when it comes to put those ideas to paper.

I had a stroke of luck though, I must say. Around that same period I had decided to make all kinds of different prototypes that I would use in a sort of repository so that if I would need one mechanic, I would know where to get it from, without resorting to google and trying to adapt some foreign code. While working on a prototype for a platformer side scrolling controller, my muse was around the same room I was in, and noticing me working on that, told me that she found it quite interesting and that she likes how it is as an idea. I took that to consideration and decided to expand on that prototype and add basic enemies and collectibles and an ending.
I had her try it to which her feedback was that this kind of prototype was exactly what she wanted.

I was then in some sort of Limbo: should I do a paper-prototype if I already have a digital prototype that fits my muse’s needs or not? Asking the lecturer, he told me that it would be OK. There would not be a great need to develop a paper prototype if the digital one already fulfills the right functions, thus I went digital with it.

Thus, I want to say: “Thank you, Unity”. It is so simple and friendly to work with, even though its bugs can be pretty nasty sometimes. It is unity’s rapid prototyping capabilities that enabled me to build a digital prototype faster than I did a paper one and I was also able to test it on my muse without explaining the muse and acting as a gamemaster, in a way letting my muse believe that there is no random or alea element in her play, giving her feel like the rules are there to help, making the game more of a agon play.

For the basic prototype that I handed in I had just used Unity’s primitives, but on further instances I had added models created in 3Ds Max and music created using Ableton Live, though I did try some classical music.


Muse do’s and dont’s.

So I have a muse. Had. Have again.

I guess when the course started I did not take the whole muse situation seriously, but it was a very important lesson, nonetheless. What was very important was my underestimation of how you much interaction you need with a potential muse. Sure, it is possible to have a muse that is far away, but that involves a lot more work and that is mainly due to the types of communication available. Having access to all three forms of communication: verbal, non-verbal and paraverbal is most important in such a case where you want to get as much information out of your muse as possible. This led me to have to drop my muse and change it quickly.

The process was not easy. It was like being in a comfort zone and being forced to take initiative and change the current equilibrium. Something that had to be done, not that was wanted to be done.

The end result is not bad though, in my opinion. Which led me to develop a couple of do’s and don’t when having a muse:
1. Communicate. A LOT! If watching your muse sleep helps you, do it, but the best way you can learn things about your muse is by talking a lot to her, which leads me to…
2. Spend time with your muse. The more time spent together, the more you know about your muse through both indirect and direct methods. This is closely tied to…
3. Have a muse which is close by. This may be more optional than the previous ones but it does make the job very easy. The accessibility to all three forms of communication should be noted.
4. Don’t treat the muse as a co-designer or a patient. There is a great difference between them. Don’t let the muse have complete creative freedom, let her come with her likes and dislikes and then give feedback over the prototypes on what she likes and dislikes.

5. Test, feedback, develop and repeat. Always test, always use the feedback given for developing further and try to use it in a structured form. This could make the muse feel more comfortable because she feels like she is being listened to, while you are happy that you get feedback for your work which is a good trade-off.

Keep those in mind, and you should do fine.

Prototyping, Prototyping, wrah wrah wrah

Ah, Paper Prototyping, or the art of trying a mechanic in a cheap and creative way that allows you to iterate on it with few resources in a very short time span. For last week I had an assignment to make a paper prototype for a game. Though the teacher said that we needed to make it according to our “buddy” or feedback partner, the course blog said that we just have to make a prototype so me and a group of people who organised ourselves to make a “creative session” decided to go for ideas we had in mind.

I myself have not played a good space sim in a while so I decided to go with that genre in mind. I had started from the idea of a military prototype, how would it be playing in such a situation? How would you use the environment to your advantage while avoiding and attacking different types of enemies? Then I wanted to do a commercial simulator to see how the player would do things: would he go for the item that grants him an end to the level or will he try to improve his craft? With these two ideas in mind I then thought about: “Why not combine them?” Why not make a prototype that is both commercial and military? With that idea in mind I rushed home and created the draft.

I made a map using paper that had math grids and placed a space station, the place where you buy your supplies, a couple of debris, for hiding, and then I proceeded to create the enemies, 6 types of them, all with different stats. Then I made three levels of difficulty which affect your stats, then I made the icons for all the enemies and then I made the items, each with its own price. The way you gain enough credits to buy the items is through killing the enemy and collecting the bounty off it’s head and each craft has it’s own price.

 What was then left to do was to actually make the thing. Good thing I had cardboard from an Amazon package lying around in Analog so I had enough material to make the icons. The prototype would basically be a turn-based game where you control your own ship, destroy enemies out to get you and collect the money off their heads to get out of there.

And that’s where the first fail came. You can’t just not fail in this field. The problem was that I cut the unit blocks too small, so that they would be the exact size of one tile. Good from a size point of view, hard to move. Even when drawing the icons I realized how cool it is to have two pencils: one for holding the tile and another for drawing. Crude, but effective. I only realized that it is unplayable when I tried to playtest it. Seeing how it was a fail it was time to improve on it to make it playable. The solution: increase scale by 200%.

I decided to do it quickly and just alter the size of the units but not of the playfield, debris or asteroids. The result was that the game actually started to be playable, but it would take too long, even though my “lab rat” was playing on easy mode. What to do? Turbo mode :D Simply double all the stats except your health points. This would make a quick and fast game, though it did take about 2 hours. Nevertheless, he liked it so much he asked me: “Why not turn it digital?” Which does not sound bad at all. A turn based space sim where you battle your enemies and collect booty in order to get the right technology to get out of the sector. Sounds good, should do a prototype on this for sure.

I also had a photo of a prototype that belongs to my colleague, Ioana. She had envisioned a co-op or competitive game where on the co-op level, you had to either control a rabbit version of Mario or the tetris god and place the tiles so that the other player gets to the end, while the other player must not move too fast or he’ll die or something and on competitive play they have to achieve their goals: for the rabbit to get to the end and for the tetris god to place the wrong tiles to confuse the player. Cool game and I’ll post a link to her entry on it when she has it.

Another cool game was that of Emil’s. He managed to do a pretty interesting puzzle game that you can read more on HERE.

Sorry Emil for not detailing your game as much as I did Ioana’s but I didn’t get to test it :)

Anyway, Paper Prototyping. Simple, easy and it can give you great ideas. Just imagining the real-time part of it is quite hard. If you want to read more on the subject, Tracy Fullerton describes it quite well in her book: Game Design Workshop, 2nd Edition: A Playcentric Approach to Creating Innovative Games. Morgan Kaufmann, February 2008.

On Participatory Design

Q: Participatory Design (PD) is rooted in a real concern people have that technology and design will overshadow them.  They basically want to have a say in how they conduct their lives and how design choices will affect them.

But an argument could be made that games are-in a sense- voluntary.  People don’t have to play them, at least not in the same mandatory way they have to deal with design choices made in their workplace environment. Thus, the design of games may need not have the kind of political overtones that PD automatically gives off.
But is this true?  Agree or Disagree?  Is this more or less applicable for some types of games than others?  Discuss.A: Isaac apologizes for the question, I think it would be nice to forgive him… this time.

Alright, returning to the question: When it come to participatory design, the general idea is to have the game created by treating the user as either a muse or a co-creator. If the user is a muse, then he will inspire most of the design of the game but he will not be responsible for creation or design of any content, just the generation of ideas. Should the user be treated as a co-creator, then the degree of participation will be greater, as the designer will then come with guidance for the user, based on his experience, while the user will come with ideas into what he thinks will be useful for him, as well as being the creative motor behind it, as Sanders mentions: “The authors take co-creation to refer to any act of collective creativity, i.e., creativity that is shared by two or more people. Co-creation is a very broad term with applications ranging from the physical to the  metaphysical and from the material to the spiritual, as can be seen by the output of search engines. By  co-design we indicate collective creativity as it is applied across the whole span of a design process, as  was intended by the name of this journal. Thus, co-design is a specific instance of co-creation. Co-design refers, for some people, to the collective creativity of collaborating designers.” (Sanders, 2).

Such interesting design pieces come for instance in the popular Dungeons and Dragons, where each user describes his actions orally with the game master who is also a player taking the story into different directions. Here the rules are only meant to keep the game rooted somewhere and provide a certain framework, while the players themselves take the creative actions, with the game master responsible for connecting the creative actions with the stats, practically connecting the art with the math. Another example is the Forum Theatre as mentioned by Brandt: “Here a group of factors play a conventional piece of theatre. The audience are asked to suggest changes in the play according to their preferences, and after a debate the play with incorporated changes is performed again.” (Brandt,3)
This term however, can not apply to other types of games, for instance arcade games, board games or other games that require complex gameplay mechanics. Such games may actually come out worse through the efforts of co-design, due to their complex elements. However, most of the games might actually benefit from it, and by the way it is practiced today, it might be very useful, as Sanders points out: [it] “is focused more on the exploration and identification of presumably positive future opportunities than it is on the identification and amelioration of adverse consequences.” (Sanders, 4)
After looking through these arguments, one would think “why should we not give it a try?” The only drawback might come from the time needed to spend with the co-designer but in a world that is becoming more and more consumed by technology, that slowly starts looking somewhat like the silent film Metropolis (1927, Fritz Lang), communication to create might actually be more of a breath of fresh air that could help the creativity and possibilities of a game, even an app.

On Game Jams and the User-centric Approach

Q: Do you think user-centric approaches are at odds with the Game Jam approach?  If the idea is to get a player involved early in the process, how does this fit into what goes on at a Game Jam?

A: I’m a second year games student who has already either participated or been witness to a couple of Game Jams. Game Jams are made to be fast paced game development gatherings that usually end up being better in networking or a good game idea than in a finished product. I honestly believe prototyping is a lot easier since it fits in a Jams time frame and has a potential to provide cool ideas for a product, something that could be expanded, while when making a game you have to be lucky sometimes to make it really work out.
The problem starts from the way Game Jams take place: two days of work round the clock, thus it’s practically a group of people crunching away and designing a game from scratch. The only problem with it is usually the scope taken by teams. A game with a big scope has very small chances of being done in two weeks, let alone two days. The speed of production could also come into conflict with the user-centric approach.
In order to get a player involved early in the process, a team has to have a target already. That is one of the main rules of marketing when it comes to making a product: establishing a target, whether it is a niche or a wide audience. Target audience influences design and needs at least one representative from the target audience in order to continuously provide input. Besides that, constant communication must be present, meaning that in order for a game jam to work it needs to have the user be part of the team and yet separated. Constantly communicating and inputing information but being in the dark enough in order to make playtesting be attuned more objectively.
Due to the nature of game jams, I would say that game jams are generally not user-centric, but they could be made that way by getting either outside people to be “users” and thus the target for the teams developing. If that is not possible, then the users could be the members of other teams, though that might influence the design of other games. It is complicated to say which could be the right choice of action but in my opinion, user-centric approaches are more or less at odds with game jams as babysitting the user might require too much effort considering the strenuous and necessary development.