It happens: sometimes you get a student team that doesn’t have a major skillset usually needed to make a game. Not that it’s impossible, but it means the team mentor has to consider what to do to make sure they are able to get a game out.
Now that’s actually not impossible: there are one-person games out there, and my previous research did focus on ensuring designers could survive a worst-case scenario of having no one to work with. With regard to student projects though, there’s a specific goal: the game has to showcase the students ability to conceive, plan, develop and finish a project.
Here are two student teams that had this problem that asked me for mentoring.
Dark Circuits (2016)
Dark Circuits is a game made in 2016 by two programmers: Chan Yuen Theng and Ho Weng Yew. All they can rely on was their programming abilities, and they had to figure out how to do the design and art for their game.
So it brings up a question, or rather two. What should they do, and what shouldn’t they do?
In this situation, it’s easier to answer the shouldn’t. One quick answer is : they shouldn’t do a game design document. This is because there’s only two of them. Whatever decision is made, the other person will know. And if one of them did not implement a feature, the other will know. In this scenario, there was no need to use a game design document as a production bible to keep everyone in track. As a pair, they’ll keep each other in track. Thus there was no need to complicate what they do.
What they should do to make up for this lack? Constantly build. As programmers, they have the advantage of being able to build and test any idea they can come up with. They can quickly confirm whether or not the implementation of an idea is fun to play, thus by constantly building, they can slowly but surely build up a combination of fun features.
What else they shouldn’t do? They shouldn’t focus on art. It’s not their strength, period. This is fundamentally dangerous for presentations; as mentioned here in my previous design post there were cases of industry guests being unimpressed with a game due to the perceived lack in art effort. However, art is simply not something they can learn to be good at within the limited time of their FYP.
So, again, what should they do to make up for this lack? The answer lies on the real purpose for the FYP. The goal is not to promote a game. The goal is to promote the students as game developers. Whatever they do with the game has to impress to others that it was done by people who understood what needed to be done professionally to get a game done.
So what should they do? As programmers, they need to talk in terms of builds. Their process in building a game is to constantly add improvements and fix issues by rolling out new versions of their game. Their art may be lacking, but as #blocktober proved, blocky art is a regular part of a game development process.
#blocktober will always be one of the awesomest thing to have happened on the Internet.
So as programmers, they should talk not about the final game, but the process they took to get there. Thus, what they should do was to show progress by builds.
During the Jingle Mingle session of 2016, it was obvious that their game did not get traction initially because of how it looked. However, during their presentation, they announced that they have done 148 builds of the game.
That got attention.
They even went further and showed their failures; game mechanics they tried and decided to not pursue. This demonstrated an emphasis on process, instead of them simply saying they tried to make a game. It showed they have the willingness to see through a project regardless of difficulties they faced. Once the audience was clear on who they were and what they had to deal with, the game got more attention. And attention was all it needed, because people played the game, they understood how much effort the team put in into the gameplay.
You can download their game, along with viewing the development details at their itch.io pages:
https://ytchan.itch.io/dark-circuits
https://howengyew.itch.io/darkcircuits
This game was nominated as Best Student Project at LVLUP KL 2017’s first SEA Games Competition. A Youtube reviewer iwanPlays even found and reviewed their game. So hey, cool beans.
The very next semester after this team presented their FYP, I was mentor to another incomplete team.
For The Gods!
For The Gods! (FTG) is a game made by one programmer and one designer. It just happens.
As the programmer Desmond Pang puts it in his blog:
“When Baxter and I initially started on For The Gods! we originally wanted to do a story focused action RPG. However, during the preamble where we were recruiting our fellow students into our team I realized that the artists were all taken, and also that it would have been impossible to achieve the vision we were aiming for within the time frame we were allotted, especially considering the level of experience that the artists in our batch have.”
I’d write more about their development, but I don’t really have to. Desmond maintains a blog on his development works, and he provided a detailed weekly breakdown on how For The Gods was developed from January till July. So you can go through his posts and see how he and his designer colleague – Baxter Rhodneyson – made their game.
You can even see their process by playing their builds. Desmond, as a programmer, provided builds every month, and towards the end of their FYP development was able to provide weekly playable builds. So you can go ahead and see for yourself how their development pans out compared to their process.
What I’ll give here is a mentor’s perspective, which you can compare with what Desmond reported on.
January
https://desmondptl.wordpress.com/2017/04/17/for-the-gods-development-process-january/
Among the first issues to settle was priority: what are the features that should be done first before others? The students were already confused by perspectives from different lectures, who had different ideas on how their game should develop.
Looking back at Dark Circuits, what worked for the team of programmers was reminding them what it means to make a game. It is not the bells and whistles that makes a game, but a complete experience loop, planned from the start till the end. That team was able to make their game work because they never ran away from the need to implement a complete game loop. If there was any feature that could not be part of the loop, it does not go in.
So for FTG, I emphasized that one of the pillars of development should be delivering a complete play experience as early as possible and to maintain it. For a team with a minimal crew, it’s important that they establish what were the key features of their game, and the best way to do so is to establish a game loop. By starting off with the game loop, they now have a filter – any idea they have (or received by others) will be tested in value by checking whether or not it can belong within a playable game loop.
February
https://desmondptl.wordpress.com/2017/04/26/for-the-gods-development-february/
Having on artists on their team, one thing in doubt was their ability to deliver “good-enough” art
By splitting up every feature into five states – “Idea, Placeholder, Rough, Refined and Polished” the developers were forced to consider what constitutes a complete state for each feature. The situation we are avoiding is where a game feature could not be tested because the accompanying art feature is not finished. Thus they have to plan out placeholder states for all features so that there is no impediment in prototyping any feature. Once placeholders are done, the team can choose to upgrade any of the placeholders depending on their ability and the time limit.
See for example, Boss B and Boss C. Since they’re using free assets, they naturally had characters with textures and rigs. However, having no animators within the team, they knew they’d struggle with making the animations not just work, but fit within the constraints of the game. Once they decided they won’t implement the other bosses, they can confirm that their AI Controller and Boss Character features can be left at the refined state. The refined state for those features were determined to ensure they can be tested early – e.g. test out AI for one boss so it becomes a template on how to implement other bosses’ AI – so Baxter was able to provide bug reports on early as they work based on playable builds.
This fits the earlier determined goal that having a playable game loop determines what features would continue development and what other features need to be killed. One of the features that was killed was lock-on. It was a feature they thought was a must because it’s common in the games they’re referencing, but once they realized they’re only working on a single target, lock-on became unnecessary.
March
https://desmondptl.wordpress.com/2017/05/21/for-the-gods-development-march/
Here, two months into developed, they have already decided to upgrade the main menu. You can go through Desmond’s March update to see that he did a lot of improvements, but I emphasized this because it’s an example of the two points I mentioned above.
- The Main Menu is a separate feature that can be upgraded independent of other features. They’re simply moving the State of the feature from Placeholder to Rough.
- By maintaining the feel of the game loop, they are establishing a base experience for the players to go through. All that by simply utilizing what was readily available during development.
Instead of focusing on big ideas, they are slowly but surely sculpting their game based on what they could deliver. Once they understood what they can do better, the game became better.
April
https://desmondptl.wordpress.com/2017/06/13/for-the-gods-development-april/
Up to this point, the team worked by having Baxter do a playtest, and provide feedback on bugs he encountered. The game was already constantly tested by the designer due to the early playable approach. By this month though, the game was ready for public playtests.
Here, Desmond did a public playtest at an IGDA meeting held near KDU. Public playtesting done early allowed the developers to see whether or not their initial opinions of their game features were accurate. This was a beginning for a lot of changes to the game, but the good news is that the changes were made based on player feedback, and that means the game is slowly being groomed for public appeal.
You may have noticed that I do emphasize a lot on getting testing done early. That’s not an accident: my earlier research showed that early and consistent testing is one of the key reasons games become good. And as I looked around and queried developers, it turns out that’s a general understanding among game developers. Below, for example, is a sampling for the GameFounder’s FB page.
There is a consistent answer here: get your game out to playtest as early as possible, and you get to settle a lot of issues. This team is benefiting from their decision to be able to playtest early.
May
https://desmondptl.wordpress.com/2017/07/02/for-the-gods-development-may/
Here, the benefits of early playtesting becomes clearer. Because the game was already tested publicly, Desmond has already figured out how to bring the game out and set it up for testing. That may seems trivial, but Desmond was able to put that in practice during Casual Connect Asia 2017 where he brought his game over to Singapore.
This is Chris Murphy, Unreal’s Evangelist. By pure coincidence, he happened to be giving a talk on Unreal development at Casual Connect Asia. Since Desmond has a playable Unreal build with him, he was able to get Chris to playtest the game and get useful feedback from an Unreal expert. While other students may only get an email, Desmond was able to get more useful assistance because the team has worked on making the game playable ages ago.
Desmond took the opportunity to do Usability Testing, by studying how Chris played the game. This was also a method I researched and I found to be practical for students: simply use your mobile phones to record play sessions. Desmond and Baxter used this to great effect, as they were able to analyze how people really played their game and make adjustments.
June and July
https://desmondptl.wordpress.com/2017/11/11/for-the-gods-development-june/
https://desmondptl.wordpress.com/2017/12/02/for-the-gods-development-july/
For the last two months, the team went ahead and worked on polishing what they had. Desmond focused on maintenance, and Baxter worked on adding appeal to an established gameplay.
For example, the top left and right images above showed a level Baxter made using the free assets from Infinity Blade. While serviceable, there was a problem: one of the initial appeals of the game was that the player was fighting in a blue-sky ocean platform. It seems odd to say that the need to put blue skies in games still matters, but in this case, that level design did eliminate the blue sky appeal. So I made two suggestions:
- Make sure one side of the Colosseum is open so that players can see a different view depending on where they face, so that the level does not feel monotonous.
- Establish a “strictly-no-changes” area where the player character is playing, so that the designer can just go nuts with what’s outside that area.
Once Baxter ‘went nuts’, the level became a lot better.
Key to this decision was that we established early on that Baxter need to have access to the build, and have the ability to change what’s inside without unnecessarily disturbing Desmond. This was necessary early in development to allow Baxter to run playtests and let Desmond work on improving the game, and this proved useful later when Baxter was able to do level design directly into the build.
In the end, the game has vastly improved compared to its initial offering. Please feel free to check out Desmond’s blog to find out all the details and to try out his builds.