Conclusion - Wrap it UP!
Looking at the game in its final state, we can see that at least our low target and parts of the high target were achieved. We did after all produce a game that offers asymmetric networked multiplayer for up to four crawlers and one VR master, with distinct class roles, distinct teamwork possibilities between crawlers and the master, a range of different enemies, a neon-infused art style of a downtown high-rise structure, animated character and enemy models, basic AI, a full user interface with a main menu, adjustable settings, ingame interfaces, at least basic error handling and more. The game gives players a clear objective and every tool necessary to achieve it.
Surprisingly, going from the alpha to final build included a number of notable changes. Through the playtesting milestone, the game saw the addition of master teleportation, limited master ability resources, increased level size, a complete ingame UI overhaul, sound effects and master ability resource pickups. Until the final release, there was another major update including the crawler-to-master ping, a revised crawler camera and most importantly, a full suite of models with animations and new weapons for the crawlers. All those changes combined make for a significant step up and forward for the game in terms of quality and target qualification.
However, even with those latest important steps completed, we actually did not reach the targets and state we had initially planned to arrive at. Our initial development schedule anticipated we'd include several game levels, more enemy types, dungeon manipulation by the master, procedural level generation, and more fleshed out crawler classes and enemy behavior. Basically all of these had to be scrapped due to insufficient time. We realized early on that our proposed targets may be reaching too high, and tried to prioritize core features. Fortunately we did not have to alter the flow of development, so to speak. We did not expect that integrating all our complex components into one big construct would create so much trouble. VR, networking, procedural generation. Those three things were the central challenges of our ideas. Each proposed its own unique issues, yet the only one we could not solve in time was procedural generation. As we've seen with project RogueGen, that topic on its own is enough workload for a single team to handle, and we quickly noticed that with all the other open tasks, there was simply no manpower and time left over for it. There is a valid question on whether we overestimated how much time each of us could and would eventually invest in the project, or whether we underestimated the effort it would take to develop and polish the items on our schedule. I firmly believe the efforts of the past few weeks since the alpha release, the crunch time so to speak, were actually more comprehensive than the course may warrant. It feels like we got so far ahead in the project that we did not want to leave it looking unfinished, so we picked the specific features or issues that remained necessary to have the game appear as a solid package. Interface, balance, basic visual appearance. Each of the milestones actually helped us focus in on these specifics, however the timing between each stage seemed somehow rushing towards the end. Specifically the shorter periods between alpha, playtesting and final release put a lot of stress on us to finalize, test, revise and fix things. It is likely an unforeseen consequence of our project's complexity, as noted in previous chapters about testing and troubleshooting.
Impressions - Paul
With all that said, one still needs to consider the final product. Our game, according to patrons at demo day, considering the length of the course, gives off a very polished vibe, aspiring to a high standard. And surely in part that is due to the approach the course teaches. While previous different courses often attempted to teach proper conduct of a project work, proper documentation, they never really enforced the extent seen here. This lab course felt like the first time a project was accompanied by full documentation, sticking to major steps of a project schedule and management. And while I am still not fully content with the result since I know its flaws inside and out, I truly believe that this is the first game project I am proud to put in a potential portfolio or show off when people ask about what I do in my degree.
One thing I might do differently when I am involved in a similar course or project in the future is to set lower targets in the first place. It feels more appropriate to adjust the project's scale opposed to criticizing the timetable given by the course. That way my expectation of the end result will be within a more reasonable realm and less conflicting. After all, an entire semester and the work of multiple people should be enough to complete a small game. Another welcome change in a future project would be to establish a clearer team and communication structure. Several times it felt like someone did their own thing and did not talk it through with the other members in a sufficient fashion. Instead, others would only get to know about a change after it had been integrated into the project, leading to frustration about priorities, troubleshooting and localized design decisions. Lastly, it would be immensely helpful if the course did some increased cross-advertisement and -recruiting from some art-oriented courses or departments, since almost every IGE team is usually starved of artists. And while that does not impact the technical finesse of a game by much, it definitely affects the visual representation, which unfortunately is one of the biggest factors when presenting the game to strangers.
Impressions - Artem
During this practical course, our team (and myself in particular) experienced wide range of impressions from total frustration to pleasure and satisfaction from the final product. Beginning with the former, I would like to confess that our initial plan was an overestimation, which lead to the fact that not all our ideas were implemented in the full scale. However, despite the fact that psychologically it is very hard to admit that substantial part of the game should be discarded, I am still proud that together we came to this wise conclusion and sacrificed level generation for the sake of completeness and quality. It is much more important that our final game is beyond being just playable: it is really appealing and fun and got very favorable reception from the demo day visitors (which would not be the case try we to stick to the faulty plan and integrate technically burdening level generation into our game). The final result turned out to be more than satisfying, since we are pleased to have many features that AAA games have such as fast-paced action gameplay, stable networking, cool graphical effects. I am also proud of many technical solutions we created during the development phase, and happy that our main feature: collaboration between the VR master and the crawlers - turned out to be fully implemented and successful.
Next thing I have to mention is a teamwork experience. At first, for me it was probably the deepest teamwork experience in my studies and I am glad that it was mostly pleasant. It was not, of course, completely smooth, but everyone was able to listen to his teammates and compromise, which finally made our collaboration, in a word, fruitful. There are still much to learn in terms of self-managing, but the important and pleasant outcome is that we are capable of working efficiently together, and always go forward despite of different view on some issues. It was really a worthy experience.
Finally, a few remarks about the course itself. I like that it gives enough freedom to the teams, while helps to manage the schedule and developing process with regular milestones and presentations. The course gives unique experience of implementing something complete, something that touches all parts of game development (some of which are not even represented very well in other courses, for instance, Game Design, or advertising the game to bring more visitors for the demo day). It would be even more awesome if the course somehow brought the collaboration with art schools into picture. I am sure that some art students would love to create beautiful assets for their portfolio, and it would also remove some burden from us - "complete" programmers.
Thanks to everyone: organizers, teammates and other participants - for the challenging and fun experience!
Impressions - Inshal
This has been my first time developing a game properly from start to finish with a team of like-minded and motivated (even more so than me!) individuals. I used to work on small game projects here and there in my spare time implementing inventory systems, maps, physics-based movements and the like. Working on a complete game from start to finish and see the final product received so well and well appreciated by others has been a thrilling experience!
The lab was structured very well and allowed me to go through the entire developer cycle that I read about in game design books. Though it was still really easy to fall into the trap of setting our expectations too high. It all seemed so easy in the beginning. However, during development, we had to cut a lot of our initial plans due to time restrictions. It was regrettable but gameplay-wise there was a lot that didn't make it in the final release. Perhaps next time it would do well to aim low, achieve that goal and then maybe shoot for the stars.
Another important takeaway from this course communication. We did establish weekly meetups and discussed our ideas but when it came time to implement things, it was messy. Changes kept getting overwritten, reverted, or broken. I feel more could have been done to track why a certain change was made and how it affected the rest of us. We were using a Version Control System but there is only so much the code can tell us. The intention behind the changes was always a mystery until the next meeting which was usually too late. We tried to remedy this by having a task list on the wiki near the end and discussing why a change was needed amongst ourselves. Another thing we could have used was a proper VCS flow. Having a stable branch, making changes in branches, reviewing them and then adding them to the main branch. It would have been slower but at least cleaner and easier to avoid code conflicts.
That's it for the bad, onto the good!
The best part of the course has been definitely my teammates. As I mentioned before, I used to learn game development through small solo projects. But through my teammates, I was exposed to several new things very quickly and learnt a lot within a short amount of time. VR, inverse kinematics, lighting, navigation meshes, networking and even proper code architecture for games!I'm definitely going to open up Unity again after the upcoming exams and try to experiment with these new tools at my disposal.
Presentations and the demo day were also great experiences. Rather than just work on our own game and show off the final result, each team demonstrated their games at different stages of their lifecycle. It became so that I was looking forward to days on which we had presentations so I could see how far the other games have come from their initial concepts and present our own to them. Demo day was even more fun since people came to specifically play our games and have a good time. It was so rewarding to see the laughter and panic on player's faces as they fought and the enemies we had worked so hard on using the mechanics we had tweaked so many times to get just right.
TL;DR: Lab was really fun and educational. 11/10, would do again.
Impressions - Jonas
"Oh man, there's still so much i'd like to change and add to this game: nicer models, nicer animations, all the features that we're still missing... but if i think about it, i'm happy that i don't have to." I remember saying this to someone on the demo day and if i think about it, it pretty much sums up my feelings right now.
This project was huge, fun, stressful, rewarding and frustrating. It was my biggest game project so far, if not my biggest project ever. And no one can say that the final product is anything but awesome, at least no one did so, the feedback on the demo day was overwhelming, ranging from "Did you guys really make all of this by yourself? How long did you work on this?" to "So when do you want to release it, i want to grab a copy!". In addition, just working on the project itself was really fun. This is pretty much my 9th semester programming with Unity, and while this gives me the luxury of having a pretty routined work flow, there was still so much new stuff to learn and implement. It was so intrinsically rewarding at times that sometimes i would just happily sacrafice my private gaming time to hang out in team speak and just do some coding with Paul. Sometimes i wasn't too happy about spending my nights working on the project and that's kind of the biggest problem we had in general.
From the very beginning, we had very ambitious goals. Yeah, sure, let's just make an online VR game dungeon crawler game with procedurally generated levels, what could go wrong? As a consequence of this, i feel like i sometimes had to spend a bit more time than it might have been intended for this project even when making quite a few compromises on the features of our game. Add in that the nature of our game makes development and testing quite inflexible and sometimes just a pain in the butt and communication with a team of various backgrounds and expectations complicating stuff at times.
But oh well, all of this just leaves me with mixed feelings, for one i'd really love to keep working on the project, on the other hand, it's probably good to just do something else for a change, especially given that fixing everything that bugs ME about the game right now would just be such a huuuuuuuuuge task.
All in all, i think we still managed to produce a solid and polished, hi-fi game. Compared to both other projects in this lab course and anything we saw on the demo day, there's nothing we need be ashamed about.
To give some feedback on the course organization: i think this semester's theme was brilliant. "Together" definitely gives some food for thought, but there's still so much freedom of interpretation in it. For us it meant to create a coop game and it made us think about what we could do to set it apart from the masses: VR! I'm still really proud of this idea, since i'm also not aware of any other game that tried to do anything similar. I also really enjoyed the concept of going through a typical game developement process, it definitely helped us to stay focused throughout the project span.
There were two things, that i wasn't much of a fan of though, for one the need to set up a detailed schedule for the entire project right at the start really seemed a bit unreasonable. Given that teams only formed a couple of days before and with a generally limited understanding of how long what kind of task would take due to a lack of experience, setting deadlines and milestones 4 months ahead just felt like throwing darts on a calender. The other thing was the paper prototype, i understand the motivation for a prototype and for some (, simple) games a paper protype might also make sense. But in our case it seemed like quite a mission to map this very chaotic and open game idea to the constraining space of a paper prototype. The final protoype ended up being really awkward (we had 3 maps and a really big devider) and thus not too fun to play while it felt like most of the core aspects of our game got lost somewhere along the way. Even worse, i caught myself and other team members still thinking in the constrained and simplified game mechanics, that still lingered in our minds from the prototype phase, much later on in the game.