Fearless
Introduction
Fearless was created in 3.5 weeks using Unity. We had 3 members on my team: Raven Johnson, Anna Traynor, and myself. Raven Johnson was given the duties of implementing the design specifications in code, as well as finding or producing sound effects. Anna Traynor was given the duties to create concept art, some models, and make the UI graphics. I came up with the original concept idea, led the project by organizing meetings and setting sprint goals. I also designed the level's environment, worked on balancing the game's mechanics, modeled almost all of the graphical assets- Also testing the gameplay and environment, making adjustments where necessary. This was the second game I worked on as a team leader, and I tried to incorporate lessons learned from the first.
We accomplished a great deal in those short 3.5 weeks, with both good and bad outcomes. What I felt went right was: the allocation of duties, group communication, and the tools used. What I felt went wrong was: the game's focus, distribution of work, access of documentation.
What Went Right
In previous works, I struggled mainly due to a lack of diverse skills by my group members. Going into Fearless my team was comprised of a programmer(Raven), an artist(Anna), and a designer(myself). This meant, to me, that the bulk of work necessary to produce the game would be covered by our areas of focus. Raven is quite skilled at programming, so I was very grateful to have her as a member. Anna is definitely a much better artist than I, she produced several concept art images that got everyone excited for the project. I found that it's very helpful to have the right people with the right skills going into a project like this, but that alone will not produce a finished product.
I had worked previously with Anna, so I already had her contact information,
and I quickly reached-out to Raven to stay connected. We hosted bi-weekly
Skype meetings, as we were all online students, each meeting had a basic
structure but it was the only time we really got to have immediate feedback
from everyone in the team about a decision. I typically began a meeting
looking at where we were in the project, commenting on what was done last
week, and projecting the work we would need to do until the next meeting.
Weekends were the time where I often sat with Raven on Skype for a few
hours while we worked through problems specifically about implementation.
With game projects like this, I've found that it is best to be communicating
daily. A great deal can change in only 24 hours, and it was good that we
stayed in contact.
When the idea was first proposed, the team needed to decide on what IDE to use. Raven had worked with Unity before and felt comfortable with it, so have I. Anna wasn't familiar with Unity, but instead worked with 3DS Max and imported her work. Since Unity is such a robust program, there are also many plug-in tools that people make for it. Such as a 2D side-scrolling tool, or for our purposes- a pathing tool. Early on, I struggled to figure out the best way to implement the main method of gameplay and with Raven's help we discovered a simple way to achieve this. It essentially meant the player's ship was tethered to a dummy object. The object followed the path of the level, so this would allow the player to move all around while following the path of the level. We found a plug-in that was able to produce this, but I think it was mostly used for non-interactive objects. Strange results occured, as you may see in the final demo version- when the ship was tethered, the pathing became incredibly slow. Still, without these tools, we would have been really far behind during production.
This is the main menu that Anna created.
What Went Wrong
Looking back now, I feel like the game's focus was a major issue. But, I do believe that it could have worked out just fine had we truly polished it. The focus was up to me, and several things about the situation and my personality led to improper placement. In the class where Fearless was produced, each student had to come up with a game concept and then pitch their idea then decide, as a group, which game would be made. Anna's game idea had to do with making a social simulator for an ancient and fictional Egypt. I wanted to incorporate her idea into the game, so we made the setting on Egypt. And then I came up with an elaborate storyline to explain the gameplay. Especially after playing the game, I think that rather than making it follow a curving path it should be a straight line, but with objects to 'almost collide' with- more akin to a rythmn-based flying game. But at the time, I felt like I needed to make 'lots of stuff' and so the Egypt setting had many set pieces, the level was long but lasted about 3 minutes at the average speed, and many of the cooler features to make the game more fun were not implemented due to difficulty, time, and resources. I lost focus and was building the level with blinders on, I took my eyes off the gameplay entirely at times. The set events in the level, that would be crucial to balance and fun gameplay, were haphazardly thrown in due to time constraints; and this likely conflicted with the plug-in for Unity as well.
The work distribution was a major issue, as well. I believed the simplicity of the models and textures would mean less time spent working on them, but that wasn't really the case. I tried to do too many things, and took it upon myself to model, texture, and rig almost every model used- Anna was struggling to keep up with the number of assets. I tried to make the period accurate to ancient Egypt, which required research to find out about the basic landmarks like Abydos, Abu Simbel, and the Great Pyramids. Then I wanted to model environments that resembled these surroundings and objects, but with clear signs of alteration by the enemy forces of the game. Again, i'm not the best artist in the world so my models were like hammering a square nail into a round hole. It might fit, but it won't be pretty and it also won't be that stable. In addition to all of these models I created the path of the level, produced a prototype in Rollercoast Tycoon III, white-boxed the level while also working on models. Then I implemented these models, built the terrain and lost a great deal of time when I had to adjust the path, while models were already in place. As the level got bigger and bigger, even while hiding a grand majority of the objects, Unity would move at a snail's pace and often the thing slowing me down was the program itself. I implemented the collision code made by Raven, to work properly it meant everything that was in the direct path of the player needed 3 separate collision boxes at the same origin. The outermost box gave a small boost, the middle box gave a larger boost, and the innermost one was a 'kill box' if the player hit it, they would crash. Overall, I took on too many jobs and spread the quality of the final product too thin.
Lastly, access of documentation. I was originally going to put 'lack of documentation' here, but I discovered weekly post-mortems that I wrote on the project. It is, however, one of my weaker points that I tend to keep ideas in my head and that can cause issue when trying to communicate an idea to team members. Raven informed me after the class had ended that we used Bitrix to keep our documentation available for each other; I had completely forgotten about it prior. Unfortunately, the Bitrix account was closed, so now no one in the group has that documentation. This isn't just feature lists, sprint duties and so forth, but it also incorporated research that we did and even the example I used earlier of the ship being tethered to a dummy object. I mean, there's a reason that games' have development Wikis and Design Documents- a 'Bible' indeed.
In Conclusion
Do not sacrifice gameplay for 'content' had I focused less on making an authentic-ish ancient Egypt, and more on mapping out the design of the level for best enjoyment, then I think the game would have been awesome. Also, whenever you change or introduce something new- take a bit of time to think how it might affect things. Like the ship's scale being weighted to the dummy object and how that would affect the speed of the player through the level. Lastly, to document and record as much as you can. Not only on a website(that may close your account) but keep back-ups ready just in case you need them.