A new entry focused on the different kinds of research and some useful techniques that can be applied to the field in which we are involved. We always have to take into account the criteria and ethical limits throughout the process, especially because the participants’ data gathering is a fundamental component related to these studies. Also all about the very last phase on the Rapid Ideation 2 project!
Rapid Ideation Two (part 2)
After having presented the idea during the last Wednesday 17 March session and kept developing the program’s basic structure, some things started disturbing me.
First of all, the concept itself had some weaknesses…
During the brainstorming phase, we had planned on introducing different elements on the scene that the piranha character might use as food to survive in a very polluted environment. Some of these items might be less toxic than others (for example, a worm or a bunch of shrimps would be less harmful than a rusty bike wheel or an oil slick). Consequently, the harmful elements would take life points away from our character, and the other ones would add life points.
In this scenario a doubt arose: why a player would eat the most harmful elements instead of getting into their stomach those less deadly ones?
It didn’t make any sense.
Looping for better prototyping
Instead of panicking, after reading chapter eight of ‘The Art of Game Design – A book of Lenses‘ by Jesse Schell, I wanted to experiment his approach on this prototyping cycle.
“At this point in the process, you have thought of many ideas and chosen one, and now it is time to move on to the next step: Try it out. And many designers and developers do just that leap in and try out their game. and if your game is simple such as a card game, board game, or very simple computer game and you have plenty of time to test it and change it, over and over, until it is great, you probably should do just that”. (Schell 2015)
By the end of this chapter, the author also gives good advise about how to conduct a productive prototype. From the 10 tips he explains I decided to focus on the first two in order to find a solution to our problem.
Prototyping Tip #1: Answer a Question
Every prototype should be designed to answer a question and sometimes more than one. You should be able to state the questions clearly. If you can’t, your prototype is in real danger of becoming a time-wasting boondoggle.Prototyping Tip #2: Forget Quality
When working on a prototype, all that matters is whether it answers the question. The faster it can do that, the better , even if it just barely works and looks rough around the edges.
In our case, the question to take into consideration was clear: are the rules consistently (logic) enough?. For the second tip we decided to stop making any more art or addition animation and start testing right away.
“The process of game design and development is necessarily iterative, or looping. It is impossible to accurately plan how many loops it is really going to take before your game passes all eight filters and is “good enough.” This is what makes game develop- ment so incredibly risky—you are gambling that you will be able to get your game to pass all eight filters on a fixed budget, when you really don’t know if that will be possible”. (Schell 2015)
I also decided to put into practice something that we learned when studying the agile method approach for the creative process. As I recall, during the evaluation phase you look back over your work in progress to look for strengths and weaknesses, in a positive way, constantly reassessing and applying changes if necessary (more about this practice on my entry for the second week of this CRJ).
We don’t want to change the plan just for the sake of changing, but we want to change be- cause change means we’ve learned something or that we’ve avoided a mistake. (Cohn 2006).
So I grabbed pen and paper, start thinking over a little better and setting out improvements for the artifact gameplay and content level. After submitting the idea to Debbie Norton my partner in this project, she agreed with this right away.
After having reflected on it, the new modifications to the rules that we had established for the first version of the game are:
- The piranha should ate all kind of stuff without giving the player time too much time to think about it.
- Some items will add or take life points away from the piranha (after all, a sunken bottle can contain inside a nourishing algae colony which would counteract the damage for eating a few little pieces of chipped glass). Some others will only increase the energy counter and a few ones will do the contrary. All values are generated randomly.
- Provide the player with other possibilities of movement like dodging undesirable items by swimming away using the space bar from the keyboard.
- Include a timer to force the player not to think very much about what to do (in short, what to eat and what not to). When the timer goes back to zero, it will determine the death of our beloved piranha unless he managed to clean up the scenario from waste.
- When the level is cleared, a new one of increasing difficulty will start.
In relation to the content, I was also concerned about the game turning mostly into a survival adventure and forgetting about the environmental message to focus only on ability instead.
Then it crossed my mind that some objects, when being swallowed by the piranha, could show a short message popping-up on the screen, making reference to the ecological catastrophes which we intended to put under the spotlight. It would be information bubbles with data related to this issue. Debbie loved the idea and immediately started search for references of interest in video documentaries and books while I focused on the technical side of things.
Alive and kicking!
All these new elements made me feel much more satisfied in relation to our approach. We realized that there were lots of task to carry out. We also noticed that some of the ideas suggested in the beginning should be put aside and eventually left out to be added later, since we had three days left to present our work.
Almost, at the same time, we were told that the presentation would be carried out in two turns on Wednesday 24 March, the first one in the morning and the other one in the evening. We both preferred to do it in the morning, though this would make our schedule complicated. All this meant sacrificing overtime which was supposed to be used for testing and finishing the final creation of the playable version. Consequently, the ships and enemies we had planned to include in this phase did not appear on this first level. This left little flexibility to finish on time. Besides, we could eventually keep working on this project even after the presentation in case we felt like doing this.
With good reason Debbie also suggested the scoreboard to be replaced by something more visually attractive like a life bar which I found very convenient, the excess of visual information on screen (the time bar, the life bar, the bubble facts) made it difficult for the gamer to focus on one particular thing…
However, these changes could be perfectly introduced on the next stage of development since, after all, we wanted a functional prototype completed on time. This was the main goal to accomplish.
Happily, we got to finish the music and some other details this morning a few minutes before the presentation.
Personal goals
Though being different, they were essential to develop our common project. You can read all about Debbie’s objectives here, while I’m going to list mine below expressed as SMART goals:
| Specific | Learn to using Unity 2D and Playmaker add-on to know more about their scope and limitations |
|---|---|
| Measurable | The demo has to be made only using visual scripting nodes provided by Playmaker |
| Attainable | I'll work through Game Dumb Dev and Fauzi video tutorials and consulting the Hutong Games Playmaker manual |
| Relevant | This is a test field to decide if I'm going to continue using visual scripting to develop short games in Unity |
| Timebound | Over the course of this two-week rapid ideation project |
| Specific | Leave solo development and start working within a team mindset |
|---|---|
| Measurable | Use a Trello board and Agile approach to assign tasks and determine production times as efficiently as possible |
| Attainable | Share progress twice a day by email, chat or video conference in order to keep track of each other work's and provide assistant or ask for help when necessary. |
| Relevant | This is the perfect framework to accept to delegate responsibilities, trust on other team members and communicate more efficiently. |
| Timebound | Over the course of this two-week rapid ideation project |
This is the WebGL version of the second demo as shown during the presentation last week. (Move the fish with the A and D keys and jump with the spacebar on your keyboard).
Want went wrong and right during this Second Ideation
Based on the feedback given by Jamie White et Giovanni Rubino, I think we did a decent job. We are both satisfied and pleased to achieve our goals too!
| Problem | Solution | Way to accomplish a solution |
|---|---|---|
| Gameplay logic was confuse and boring. | Create a set of better rules for the player to understand the game scenario (score system, time counter). Create a more exciting challenge for the player. | Implement Icedip evaluation phase to look for strengths and weaknesses, in a positive way, reassessing and applying changes where necessary. |
| Game turning mostly into a survival adventure without any clear message to the audience. | Redefine the target audience adding descriptive content referencing the ecological catastrophes which we intended to put under the spotlight. | Add a 'information bubble cards randomly appearing when items are eaten by the player. |
| Creation of a new scoring system, a time manager and 'bubble fact cards' content, before deadline. | Focusing on the mechanics already developed instead on adding new ones (enemies on the ocean as sharks, boats throwing waste from the surface). Expand the game area to give more space to the player to search for different items and to add some extra room for the 'bubble fact cards'. | Create the energy counter, timer, bubble card and random points generator. Look for additional content through research of new facts to show in the bubbles from books and documentaries. Learn how to achieve all these technical challenges that I never did before using video tutorials from Skillshare / Youtube Playmaker channels and from the Unity / Playmaker user's guide and forums. |
| Deadline is approaching fast, presentation time has been advanced. | Some of the ideas suggested in the beginning should be put aside and eventually left out to be added later on following iterations. | Rescheduling of main tasks, reduce fancy stuff to the minimum as additional animation, items, sound fx, visual fx. |
| UI Canvas layout issues when exporting from Unity to WebGL, Mac or Windows. | Investigate the problem on Unity's Manual and videos | Use Unity's anchor system for Canvas for both relative and absolute coordinates on screen. |
| Too many things on screen a the same time! | Add a visual elements to replace the numeric counter and the time limit to simplify readability. | Add vocal narration to improve on the idea of the 'bubble fact cards' replacing large chunks of text with voice. |
User and audience research
Paying attention to an existing and mindful audience that is responsive to our creations is a must in any business. In the case of games or applications it is also important to research if our revolutionary idea has not been already created, failed, rejected or discarded due to the lack of interest on the market.
Getting to know our audience is the key to success. It is highly necessary to count on a mass of interested people in our products, otherwise all our efforts will probably be in vain. This will lead to a waste of money, time, resources and expectations. The enthusiasm and institution are not enough elements when seriously moving forward to a new project. Above all, these are not excuses to forget that the main goal is to design devices that have a concrete user base.
A common case is, for example, a programmer who plans to create their own video game right from scratch, building his own engine and the necessary tools to bring their ideas to reality. It is very common to see how the use of the technology, mostly available for free, is systematically rejected by these ‘lone wolves’. Within several months and years, many developments do not make it to the end, lacking a stable or full version of the new engine and the long-desired game. Reinventing the wheel may not be the best way to push things forward.
‘Why on earth would we write our own game engine?‘ Gamasutra’s Blackbird Interactive CTO Yossarian King (2011) article states:
Don’t underestimate the time it will take to write an engine. Why not invest that effort into the game itself, and not into the foundation required to support the game? There is a lot to a modern game engine, and it is a huge effort to build one.
The enthusiasm and intuition are not valid elements when seriously moving forward to a new project. Above all, they are no excuses to forget that the main goal is to design artifacts that should have a concrete user base.
Humbly speaking, over the last few years I have done some baby steps in the amazing world of independent game developers, and during this period I verified that most of the time these principles, that could be considered more than obvious, are mostly ignored or put aside until the very last moment. Very often even just a few weeks before the release day.
Many game’s creators do not understand why the numbers on the “wishlists” are so small, and sales do not meet the team’s expectations, not even in the worst case scenarios.
That is why audience rating surveys are essential in relation to the first development stages. Such phases or suggestions must not be put aside. No matter if they go over the line of skills or available knowledge among the team’s members. Furthermore, it is especially important to keep in mind that this research is a multidisciplinary task including psychologists, technicians, designers and marketing experts.
Getting to know the audience
A noticeably wrong preconception, but at the same time rooted among the small programmers’ community, is to think that people share their same tastes, ideas, interests or passions. In fact the differences are the only common ground among the so called audience’s members. For such purposes experimental psychology teaches us two possible additional approaches when studying the potential recipients of our products and the quantitative and qualitative methods.
But how can we tell if our product has an audience in the first place? How to be sure that there’s someone out there interested in our creations?.
As independent developers, usually with very limited resources, a good starting point is getting seriously involved in community building.
Let’s take Discord for example. As Mike Rose (2019) stated on his GDC talk ‘Building a community for your game from scratch’, people who uses Discord actually do play games being this platform a perfect place to collect information about people who could be potentially interested in our game. By the way, if you’re not familiar with Discord, this same talk provides a step by step guide to set up your server and make great use of bots and scripts in order to know more about your followers.
List of figures
Fig 1 – Sketch to illustrate the possible new rules on the project. Made by the author.
Fig 2 – Aseprite sprite editor and Unity Animation Module. Screencapture by the author.
Fig 3 – Thumbnails for timing the animation of the seaweed. Sketch by the author.
References
Williams, R. 2001. ‘The animator’s survival kit‘. Published by Faber and Faber Limited, London.
Dumb Game Dev. Youtube channel. ‘Speech bubble canvas for NPCs‘. [online] Available at: <https://www.youtube.com/watch?v=_zeJkokhlOw&t=655s> [Accessed 21 March 2021].
Hutong Games. Youtube channel. ‘Using Playmaker at runtime’. [online] Available at: <https://www.youtube.com/channel/UCll8FyIFgevUyLfd-jhhskA> [Accessed 15-24 March 2021].
Etherinton, L. 2020. ‘How to Think When You Draw‘. Vol 1. Published by the Etherington Brothers.
Cohn, M. 2006. ‘Agile Estimating and Planning‘. Published by Pearson Education, Inc.
King, Y. 2011. ‘Why on earth would we write our own game engine?’. [online] Available at:<https://www.gamasutra.com/view/news/128765/Opinion_Why_On_Earth_Would_We_Write_Our_Own_Game_Engine.php> [Accessed 22 March 2021].
Hutong Games. ‘Playmaker Manual’. [online] Available at: <https://www.youtube.com/channel/UCll8FyIFgevUyLfd-jhhskA> [Accessed 22 March 2021].
Fauzi, R. Youtube channel. ‘2D Platformers using Unity and Playmaker 2020 update‘. [online] Available at:<https://www.youtube.com/channel/UCbjQvNpDaHBrlBhpk65OQgA> [Accessed 22 March 2021].
Lord.P and Sibley B. 2010. ‘Cracking Animation’. Published by Thames & Hudson.
Unity Forum. [online] Available at: <https://hutonggames.fogbugz.com/default.asp?W1> [Accessed 21-23 March 2021].
Schell, J. 2014. ‘The Art of Game Design – A book of Lenses‘. 2nd Edition published by CRC Press – Taylor Francis Group.
