Woods of the Dark Arts
1. Project Description
This started out as a remaster for a largish game company but it turned into our own roguelite game project after the plans for a remaster was cancelled. The whole team is comprised of students.
I was the project lead throughout the first year or so of the roguelite development and assistant team lead during the earlier remaster phase. In addition, I was a programmer and designer throughout both project timelines.
Client: Xamp Game Studios
Team and Roles:
Toni Tiilikainen - project lead/producer, "senior" programmer, lead designer
Joni Helén - lead programmer
Luna Berger - art lead
Nero Nikolaev - programmer
Knosta Karttunen - programmer
Essi Kykkänen - UI artist & design
Ding Yifan - artist
Saku Nurmiranta - audio design and implementation
And half a dozen others with so far very limited input in the project.
Design: The design process was largely a group effort.
Achieved: A functioning demo with many mechanics programmed in that doesn't have art to implement yet.
Future: The project will likely continue without me as I allow a new project lead to take my place. The exact direction depends on whoever replaces me, but current focus is in implementing the HUB area.
Schedule: The early development was in a daily format. A transition to weekly format happened as school started for everyone three months after XGS greenlit the roguelite.
2. My Tasks
Project lead/producer: Scheduling, making decisions, recruitment, helping everyone be on the same page/communication, and helping everyone understand their tasks.
Giving opportunities: I kept it as priority throughout the project to allow people to learn new things and use the project to further their studies in ways I found feasible.
Project management: I learned how to use Jira and Confluence for the use of management. Neither was a completely optimal tool, but I did see the value in using them.
Reviewing code: We set up pull requests on git. I helped review code, comment, and approve the PRs.
Design: For the longest time all design decisions went through me or were made by me.
Architecture design: I used a significant amount of time creating UML diagrams and documentation with the lead programmer. This allowed the rest of the programming team to create some of the systems in the way we needed them and understand how the different game core systems could be interfaced with.
Technical art design: Using 2d art in a truly 3d environment proved to need a lot of interesting art design and programming architecture choices.
Player character: I programmed all the player functionality other than the stat mechanics.
Camera movement: I made a short script to make the camera Lerp softly between the mouse and the player character. It apparently turned out rather pleasant.
Input system: I created the input system with Unity's "new" input system.
Game manager: I programmed the core class that oversee the state of the game. I used a singleton class that initializes itself before any Awake or OnEnabled is triggered by Unity.
Prototype physics: The prototype had custom physics to allow for some interactions to function easier. Some of these were later added in to function with the player character alongside Unity's own physics.
Prototype AI pathfinding: I programmed custom pathfinding early on. Though it was functional, I decided to go with Unity's NavMesh for the later iterations of the AI.
Prototype AI: This was a simple FSM AI. Nothing really to say. Basic melee and ranged enemy.
AI: I programmed a base for a somewhat modular behavior tree that could be used to create all the AIs of the game. The AI has some ability to communicate with other nearby AIs. Otherwise somewhat simple AI again.
Behavior tree visual tools: I programmed editor tools to be used in creating new BTs.
Blackboard system: I programmed a blackboard that used hashtables and custom dictionaries. However, I decided it was overly complex to use for a task I intended others to be able to modify later on.
Utility system: I programmed a simple utility system to allow for the enemy AI to exhibit some low level adaptation. I ended up scrapping it as it didn't serve the game's design in the end.
3. Problems and Solutions
Varied motivation in the team: I don't believe I am good enough of a leader to get people interested in doing something, if they themselves can't. Having discussions about motivation doesn't really seem to lead to more motivation. The largest problem was the non-existent effort of the early art and art recruitment people. A lot of problems arose from this that could probably have been avoided if I had taken a harsher stand earlier and started recruitment by myself.
Communication: Leading a team of about a dozen people is taxing for me. I don't think I want to do this unless it is the only thing I'd be doing in the project.
Inbalance in team composition: First 3-4 months of development happened virtually without artists and there is still no dedicated designer. This was a problem with recruitment effort initially and later student motivation to jump into projects was likewise problematic. In the "real world", this would have been solved by simply hiring new people and firing those who refuse to work. As it stands, students do what they want with the motivation they have.
Overly complex programming architecture: I recognized this as a problem fairly early on, but failed to address it mainly because I saw the solution as more design work. The design work we simpy had no one to do on the skill level needed.
Skill level disparity: The complex programming structures built by the more experienced programmers couldn't be used by the less experienced ones. We attempted to solve this by creating UML diagrams of the game's main systems, but this only partially solved the issue. Another solution was to pair the less experienced programmers with the more experienced ones occasionally - this seemed to create better results but the overall problem remained.
School priorities: This wasn't merely a scheduling problem and I am very much at fault here myself. The behavior trees I used for the AI were overly complex for what I needed. I knew this deep down when I began creating the system, however I wanted to write my thesis on this complex hybrid AI system. The solution to this is to prioritize the game over your own curiosity.
4. Testing
We started out with a dedicated tester. However, I noticed early on that this was a person who would likely never get the testing done (for personal reasons or otherwise). For this reason I allowed this student to use the project to learn about testing but never relied on them producing results.
5. Screenshots
Picture 1. A screenshot of the demo with player inventory open.
6. Demo Gameplay Video
7. Conclusions
I think this was a great learning experience if nothing else. I learned a lot about leading a team, several differnet kinds of pitfalls you can fall into with regards to people as well as design and scheduling. I also learned a lot about my own limits in terms of how much I have energy to perform extremely varied tasks for a perlonged period of time.