Postmortem - Tu Berlin

Transcript

Postmortem by devRandom Graphics: Matthias Holländer Gameplay: Raul Mircea Gigea Content: Peer Müller Lead: Falk Köppe Inhaltsverzeichnis 1 Introduction 2 2 What went right 4 2.1 weekly meetings . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 role distribution . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3 general organisation and communication . . . . . . . . . . . . 5 2.4 useful theoretical concepts . . . . . . . . . . . . . . . . . . . . 6 2.5 high motivation and activity . . . . . . . . . . . . . . . . . . . 6 2.6 constructive criticism . . . . . . . . . . . . . . . . . . . . . . . 6 2.7 good coding skills . . . . . . . . . . . . . . . . . . . . . . . . . 7 3 What went wrong 8 3.1 feature stop . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2 only singleplayer game . . . . . . . . . . . . . . . . . . . . . . 8 3.3 time pressure and the last 10 percent . . . . . . . . . . . . . . 8 3.4 underestimation of complexity . . . . . . . . . . . . . . . . . . 9 3.5 discussion cycles . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.6 nobody is perfect . . . . . . . . . . . . . . . . . . . . . . . . . 10 1 1 Introduction The game 'RotationWar' was developed by a group of four students at the Technical University of Berlin as part of a game programming project. The main focus of this course was centered at rapid prototyping, which means to quickly develop an idea into a playable demonstration that visualizes the core concepts of a game idea. We learned dierent techniques, investigated many examples, got in contact with business activities and read a lot about game testing, ai programming, general game development etc.. We met every week either to hear a lecture about one of the topics mentioned above or to demonstrate our progress with the current game we were working on. At almost every session we had discussions about what could be improved or in what direction we should further focus on. This way, within three month an idea, not more than an a4 paper, was further developed into what is now called 'RotationWar'. The main idea was to create a singleplayer game for the XBox360 where the player controls a set of units with dierent abilities in order to defeat mean enemies in the middle of the screen. With the help of tactical decisions, the knowledge of unit abilities and their co-operation and a comfortable handling of the XBoxController the player is able to reach any of the ten levels provided. Additionally the player can upgrade his/her units with experience points he/she gained by mastering a previous level. Those experience points can be used to either give an unit more hitpoints or to increase the damage an unit deals. Support units like the medic or the sapper increase their healing or the hitpoints of the barrier. For people starting the game an interactive tutorial is given and also an ingame knowledgebase provides answers to almost any questions related to the game. All concepts are usually easy to learn, but hard to master and sometimes it is not as easy as it might appear in the beginning to reach the next stage. A comprehensive hint system guides the players through all missions and some story elements are build in, to make the player feel more involved into the game. All graphics are selfmade and the music is selfrecorded. An intuitive menu system is present within the entire game and the player can always repeat a level he/she already nished, to earn some 2 more experience points. In general we hope that everyone playing our game will have fun going through all missions. If you like to have more information, please visit our course webpage1 . If you think the levels are all but impossible than you might nd some video solutions on YouTube2 . 1 Game Programming: http://www.cg.tu-berlin.de/gamepro.html 2 YouTube: http://de.youtube.com/ (search 'rotationwar') 3 2 What went right In the course of developing our own game, we did a lot of things, that apparently went well and that we will likely do again on our next projects. 2.1 weekly meetings During the entire time of the project we met each other every sunday at someones home. Those meetings helped us in several ways. First, we could make sure, that everyone in the group knew the thread through the developing. Each member could therefore play a major part in the whole process and the game strove the way it was agreed upon. We also found the meetings as a huge inspiration resource, because within the interaction of playing the game, talking about the game and planing the next steps we usually came up with new ideas or solved problems, we could not nish alone. Sometimes we had ve to eight hours coding sessions, where we often split up in two pairs two focus on specic problems or we just had some shorter meetings where we discussed how we will proceed in the future or distributed the work within the group. 2.2 role distribution Right in the beginning of the course we had to assign a role to each member of the group (gameplay, content, graphics and lead). Eventhough you can't be sure in the beginning, if the roles will t all persons perfectly, you have a way of measuring each other and of beeing aware that it is usually a good thing to split work achieve faster development. In our case the roles didn't not just t the people, but we all started to like our roles and to really contribute whatever was in our power to do. The roles made it easier to keep track of the progress and one could faster determine if things went the right direction or not. An important thing about the role distribution is, that really everyone feels comfortable with his/her role, otherwise you will have to pay for this at the end. 4 2.3 general organisation and communication Something we all probably will never want to miss again is our 'trac'. 'trac' is a online project organisation tool, that combines a ticket system, a subversion system and a wiki. All three parts alone are a huge benet for a project with that size. The ticket system gives you an overall overview of the entire development process, it makes it possible to estimate how much time certain things will take and how that ts into the general timeline. It also lets you decide whether an assignment is rather dicult or not and on the other hand it includes the distribution of work automatically and relates the tickets to a specic role. If everyone in the group takes the little eort and that little bit of overhead of beeing synchronised with the ticket system, the whole group can benet a great deal and it will pay of at the end. Without a subversion system, our project would have not been possible. We used that system from day one of the course and had about 1000 commitments in only three month. We don't want to imagine how that would have worked out, if we wouldn't have used the subversion system. This is not something you can get too early. The faster you get used to working with a subversion system, the earlier you can focus on your game itself. Besides these two treasures, we used the integrated wiki to organize some ideas, planed our weekly meetings, exchanged phone numbers and other stu that counts for organization in general. We also used instant messengers and an irc-channel to communicate live often to solve minor problems right 5 away. It also was convenient to chat about the last details before the ocial meetings every wednesday. Because icq is time independent we could also direct specic work assignments or bigger changes at the people, which are aected by those topics. Our organisation and communication was good, because we didn't had to bother with both of it and could concentrate on the game. 2.4 useful theoretical concepts From time to time Andy Nealen gave some lectures on topics such as programming patterns, game design, physic engines or prototyping in general which all have been more than helpful, because in comparison to other lectures through out the semesters, those things were really needed and you could apply that knowledge immediatly into the game, the week after. We know it sounds stupid, but there ist nothing better than to see the modell-viewcontroller principle riding your game, or implementing a nice state machine for your articial intelligence or to hack together a prototype you will throw away just a week later. 2.5 high motivation and activity Throughout the entire project we spend a lot more time than estimated by the six semester periods per week we got for the course. The good part was, that each member of our group decided to really dig into our game and that almost everyone did an equivalent amount of work in their specic role. Specially right before the weekly meetings on wednesday or the days after our meetings on sunday we've been very productive and got a lot of work done. That high motivation and activity made it not only possible to present a working, playable game every week, but also we included a lot of changes and improvements suggested the previous week. 2.6 constructive criticism Something that was important to get along with each other, was the fact that criticism was completely acceptable and desired and therefore often lead to new improvements or just better ideas. We also discussed a lot of things and not always we found a solution right away, but the tone was characterized 6 by constructive criticism and not by just aming about the work, somebody else did. This way we found bugs and errors early and were not afraid of telling each other about them. Every idea was worth debating about although sometimes they didn't make into the game out of other reasons such as time or complexity. 2.7 good coding skills In the beginning, everything is kind of overwhelming. We all didn't develop a project like this size before, we all didn't know anything about C# or the XNA Game Studio and the idea for the game was agreed upon within four or ve hours. Everything that was just mentioned was not a problem at all, because it had nothing to do with how well you can program and develop a game. Once again we noticed that the tools are important, but the ability to solve problems in an abstract way, to understand coding paradigm, to really focus on the game, not on the techniques and to be able to adopt to any programming language without major prejudices is quite more important and detached us from solving selfmade problems or stubborn ideas. 7 3 What went wrong Obviously, not everything turned out to be right. We also made a lot of mistakes or noticed at the end, that we could have made things better. 3.1 feature stop Our approach of implementing a lot of features in the beginning, such as weapon types, units, menus, upgrades, projectiles etc. was not bad itself, but we missed the time, we should have stopped developing on those features and turn to tie these things together. We missed that time for about one or two weeks, so we had some trouble at the end of the project to get the game to feel nice and top it o. After a while we noticed that not the features make a good game, but how those elements are interlocked with each other. It was often easy to come up with new ideas and features, but we had a hard time to make a meaningful whole out of everything. 3.2 only singleplayer game Although some of the other games have a singleplayer part, our game was the only one which relied completely on a singleplayer mode. That wasn't a bad idea at all and we think it turned out pretty well, but we didn't know about the higher complexity that came along with our decision. In a singleplayer it is even more important to think about the gameplay early, because it is something fundamental we had to implement by ourselfs instead of something that evolves by two to four competing players. In that regard it also made a dierent of what type of criticism we got within the course, because all other games often discussed about the interaction of players, instead of what makes a singleplayer fun and meaningful. We've learned, that we need to take into account that a singleplayer has some aspects (specially the gameplay) that are more challanging and complex than we thought in the beginning. 3.3 time pressure and the last 10 percent Time pressure is something that we all knew before and we also knew that it will catch us at some point. Still, it is not conceivable how unprepared it hits you. Everything seems to be ne twelve hours before the weekly meeting 8 and just right before you want to copy everything, the game doesn't compile anymore, someone missed to upload a le into the subversion system, you pulled out the usb stick to early so the stick is empty when you want to present everything, you forgot to prepare a presentation, the last update before the meeting is about 200 mb big, because sound made into the game and it takes you 45 minutes to download everything... . The funny thing is, you can't be prepared, because if you could prepare yourself, you would not have the pressure! That statement played a considerable role in the end, for our last ten percent. The last 10 percent let us change our focus completely from developing some cool stu that looks good and is somehow awesome and terric to how do we rid of all the unnished, left behind parts we pushed torwards the end of the project? Translate everything into english, remap the controller and keyboard settings, improve performance issues, include navigation help, tie the missions together and write a little story, remove bad looking details...to sum things up, we had to top o the game so it looks and feels like a real game and not the prototype we've been working on for the last two and a half months. 3.4 underestimation of complexity If we heard one fact every wednesday it was that we should not make our game to complex and that we should focus on rather simple things that work well together. Well...yes, we should have done that! The thing is, that we didn't plan on making our game overly complex, but always added up one detail after another. In the end we had that huge monster sitting in one really long xml le waiting to be tackled to integrate another unit, some other weapon, a new level or whatever. That is probably ne in general, but we just didn't have the time to really sample the pleasures out of it. As we mentioned earlier, the time we spend by adding those details and features we should have put into combining and improving them. 3.5 discussion cycles Sometimes our discussions about various details of the game went in circles. One day we decided to do A and the other day we decided to do B, which is of course the opposite of A. We know now, that we will never do everything right the rst time, but it is just a waste of time to argue about suggestions that 9 you can't decide on whether it is right or wrong until you see it implemented in the game. We should have implemented more of our ideas and see what it feels like and come to a decision afterwards, instead of talking rubbish about it. 3.6 nobody is perfect At some stages our expectations were higher, than we could achieve because we've been all more or less new to this type of project. We had to admit that not everything works the way we come up with in our minds. People can have bad days or just other important things to do in their lifes, some of us t more nicely into their role than others and we all had slightly dierent working habits. It was an every day challenge to balance all this and stay on the road at the same time. We usually drifted from good to bad and back again. 10