Dare Blogs – Creative Genius

What is Silent Symphony?

Silent Symphony is a 2.5D puzzle game where the main character has the unique skill to see the colour of sound, and uses that ability to understand the mysterious magic that exists in the land of Symphony where music is magic and colour is life.

Using his magical flute our protagonist "Tago" must fight off mysterious colour stealing monsters and sound sapping creatures, and manipulate his environment to safely escape their threat and make his way home to warn his people of the impending danger.

What are the benefits of Dare to be Digital?

As a team, coming to the "Dare to be Digital" competition has given us all so many life changing opportunities and taught us so much about each other, ourselves and the gaming world in general.

As a team and as individuals the "Dare" competition has shown us what it is like to be in a real working environment, with real deadlines and real problems that professionals would face in the industry and not just hypothetical scenarios and exaggerated issues that you get in classrooms and regular studies.

As a combination of first and second years, our team has encountered many topics that have not even been mentioned on our respective courses, let alone covered to any extent, so our knowledge base has expanded tremendously and we are more aware of where we are in comparison of where we all want to be.

The benefits of this competition go passed just experience, but for meeting new people and networking Dare has been incomparable to anything we would be doing otherwise; and this is not just for potential employers and future colleagues, but also teachers, in the form of mentors and especially in each other. One team or team member may know something that none of our team does, and vice-versa. We help and teach each other, we grow together and it is a great feeling of productivity as a whole as we all move forward together.

Also, seeing how other teams gel and work together or even fall apart gives us good insight into team building and some of the problems that we share and must overcome.

An improved understanding of the importance of a good and well structured and well motivated team is one of the greatest benefits to being a part of this competition, as the games industry is a lot about teamwork and dependability on one another, not having a strong team around you makes succeeding that much more difficult a goal to reach.

What will you take away from Dare 2010?

A good lesson I have learned personally is the significance of organisation; it is not just good because it is practical and time saving but it also gives a good insight into where you are and where you are going, and makes it easier to track what you have done and where you have gone wrong.

Being well organized gives people perspective, it allows a team to know that they are progressing or falling behind, it lets them know if they are moving in the right direction when deadlines are met and milestones reached, motivating the team to keep working hard, or even to work harder and have more faith in the actual team itself.

Keeping track of progress and making regular updates and edits to the current schedule is vital, especially since whatever you have planned will NEVER be what actually happens!

Making sure that the objectives are kept "up to date" is another way of being organised and keeping track of progress.

On the topic of scheduling, plan ahead, have different side tasks for different members of the team; things tend to work in an Assembly Line fashion, where one person won’t have much to do until the person before them has done their job, so taking into account a slow assembly line or something that may (Or WILL) halt near the beginning of your queue.

You should have tasks that others further down the line can work on, important tasks and not just side jobs to keep them active and motivated while something else has been stalled.

How has Dare been for you so far?

Our own schedule has been very off in comparison to what we have done. We spent the first week getting ahead, we built our game engine, had some sample 2D mechanics working, and had the main character built, but our level designer did not have any hard materials to work with and had nothing but more designing and "thinking" to do, which from an outside perspective, did not look very productive.

As we entered our second week, we realised some problems with the character when it came to animating it, so our 3D artist was moving between level objects and editing the character.

After a few mentor visits we made some serious changes in our game concept, dropping several levels, and simplifying the controls, also rethinking the puzzles in our game to make for something more entertaining and thought provoking. Our engine began implementing animation and we had a sample character moving around on a screen.

On week three we had a new demo running with the updated control system in 2D, and we got our level construction underway, so only now did our level editor have some visible work to show. We changed our animation library to apply shaders, but that caused our character to stop working, this caused some major problems for us for quite some time.

Week four had our 3D demo running with the mechanics all implemented on a basic level, but the animator and lead programmer were going back and forth all week trying to solve the animation problem. We started to implement the game level and had something visible to show, but we did not have a working character or animation yet and we started to get worried.

In week five, we changed our game concept again, simplifying it to have more player interaction with the environment, taking out more features and implementing something closer to a levelling up feature.

We were very happy with these changes, but while the problem with our code was finally fixed, we still could not get the character animated, it was not an animation friendly build and the problems lead to the next saga in our epic struggle, but at least we had a running sample level, with a level two as well (though we officially dropped any others).

In week six, we changed our level designs and finalised some ideas with giant trees, less puzzles in the tutorial and nicer player interactions with the environment. Water affects and particle affects were quickly implemented on a basic level, and the final designs were within sight. We decided that rebuilding the character would be quicker than trying to animate it as it was, so it was reconstructed, starting from the weekend of week 5 and continued on from there.

We started combining our codes together to have a more complete project, as the level, mechanics and engine were all separate. From Wednesday we realised this was going to be a LOT more difficult than it should have been, but thanks to one of the mentors we were able to sort it out quickly, but by Friday we still had a great deal to do.

In week seven we have a basic idea of how the codes will be combined, but they are yet to be tested. We still don’t have a completed main character, and we can see how much we have to do and how little time we have left. On the other hand, we implemented level one, only need to add the interactive objects, and level two was started and nearing completion (in terms of final version).

Most of our art is finished now, but the issue of the trailer due in next week is a bit of a trouble. We have only just started implemented sound and seen how much work that will need so this is going to be a long weekend, as I intend to have the first levels puzzles completed, as well as the whole of level two done, even if it is only the shell without the puzzles within it. We already added a little mini-game feature, needs some work but it is a scrolling music mechanic that will be used several times throughout the game.

What advice would you give to those who are interested in taking part in the future?

As far as tips go to beginners or future Dare participants go, build a strong team, and by that, I mean a well motivated and willing to learn group of individuals with as large a variety of skills as possible.

Making sure they "Know" their field is important, that they are dedicated to their roles and willing to learn things about those roles that they do not know, but also, having a wide variety of skills and flexibility means that if someone in the team is struggling, other members can help alleviate the pressure by taking some of the workload, even if it is only simple object construction in 3D modelling, or building classes while the programmers work on complex solutions.

Humility is vital, understanding that anyone can help you, members of your team, members of other teams, people that are not part of your field or games at all is a huge asset to have, because everyone has an input and sometimes it is really helpful, no one knows everything, so don’t underestimate the power of a second perspective, and don’t be afraid to ask for help.

Taking responsibility for your actions is a big time saver, remember, blame is mainly used so that you know where a mistake was made and so it is not made again, not to punish or persecute someone for making it; shifting blame and being defensive doesn’t get work done any faster or prevent the same things happening again, remember this and know when you make a mistake, you won’t make it again, not that someone else is to blame for it.

Don’t be too proud, your ideas might not be liked, or might not be appropriate this time around, but don’t take it personally and try again graciously, on the other hand, don’t make it personal, if someone else has not done something how you like it, aggravating your team will only make things worse, period.

Finally, don’t lose sight of your objective, improving your ideas for the sake of a better game is great, but improving and changing are two different things, don’t change your ideas because people may not see the vision you have (even mentors) but don’t be too stubborn to adapt and edit them to make them better.

Now probably the most important thing I have learned from being in this competition is the importance of mutual respect amongst team members and faith in the direction of the team. Having conceited thoughts of believing that what you are doing is more important than anything else the other members of your team are doing, or the only important thing that is being done on the team is foolish and highly counterproductive.

The whole point of a team is to understand how each peace is needed for the final product, and only as a team is the project completed. Everyone in a team must treat each member with respect and avoid, rather than gear towards, situations that antagonize one another, and everyone should be prepared to have their opinions disputed or ideas rejected.

While it is good to be part of a democracy as a team, a final decision is needed, and it needs to be accepted, that is a large part of what it means to have a leader, to settle disputes or disagreements within groups. Team leaders should be prepared to admit defeat and know how the opinions of their team can benefit the project, but not lose their role as leader and have situations where everyone disagrees and doesn’t want to do things anyone else’s way.

The "Final Decision Maker" and the "Group Harmony" are both vital, but having both can be very difficult, and getting that balance can sometimes just be a matter of having the respect of the team, and having the team willing to give it, and that is one of the key necessities needed for completing a project as a team, because a well balanced team, is a successful team.

Anyway, this is the “Creative Genius” way of looking at things, we are not perfect but if we can stick to these principles as much as we would expect anyone else to stick to them, then even if we don’t win this competition, we will only be stronger for our next ventures and be able to give better advice to others that come after us.