#thankfully a lot of the process feels the same as rigging something in 3D | Explore Tumblr Posts and Blogs

smasheverythinggame · 6 years

Text

Smash Everything Post Mortem

The most important thing to remember is that Smash Everything is a game made by students. It’s a unit, and it’s graded. As such, levels of involvement, commitment, and effort vary. Some students invest great amounts of time, some are looking to do bare minimum. Which is not a complaint, merely an acknowledgement of differing priorities and circumstances, and it is the most important thing to figure out early and manage.

Despite internal issues, the project was well-managed and, although the game is not complete, turned out pretty well for a group of people who had mostly never done a project like this, who were just taking their skills learned at uni and putting them into practice.

Things that went well:

1. Character Concepts

This was the group’s first task at the beginning of the semester when motivation and interest were still high, group members were keen, and everyone still had time. We were fortunate that from the concepting there was one idea that we all liked and agreed upon.

2. Smashing

We had a prototype up and running early in order to help us decide on a definitive direction as well as test out our core mechanic – smashing - to ensure that it felt fun. This is a great way to test and prototype mechanics – make sure they feel fun on their own and then build around them. The smashing didn’t really change from its early iteration.

3. Enemy Concepts

After some struggle to get other concepts and group agreement on other aspects of the game, enemy concepting had the benefit of being streamlined based on the knowledge gained from previous pitfalls. There was a simple template made that displayed exactly what was wanted from it: 4 empty boxes, asking for a sketch in each and one potential ability that this enemy would have. All the sketches were gathered and put into a Google form to get voted on by team members. Ones with the most votes were implemented. This could have potentially gone poorly had the group liked wildly different designs, but thankfully while there were some outliers most of the votes went into the same designs.

4. Enemy Models

By the time we got to this stage, we were a bit behind in the development process from where we wanted to be and decided to simplify our enemy models to save time. It worked out really well. Rather than being detailed models with texture maps, they become blocky, solid color shapes that were still surprisingly cute and worked well within our toy theme to seem like little plastic toys.

5. Animation

There had been 2-3 weeks allotted to animation, with another 1-2 weeks as a potential backup, as we had at least 7 models and 2 animations for each enemy and 5 animations for the main character planned. Enemy animations were smashed out in a week; they were simple, but they worked and looked great. Animations for the character took a couple weeks, which was within the budgeted time, but hit a couple snags (problems with the rig, some redos, and some animations were cut entirely).

6. Music

Some groups were lucky enough to get a sound student on board for their projects, but we were not such a group. I think that may have worked out a bit in our favor regarding music, as we were able to include several different songs from a cool royalty-free library. Deciding on the style/genre of music for the game was a breeze – we all agreed we wanted something upbeat, maybe techno or K-pop-py – and song selections were spot on.

Struggles:

1. Communication

A surprisingly big issue, despite using Discord, Trello, and having in-class discussions. This issue existed for a few reasons: disagreements on the second item on this list – the vision for the game, missed information, a lack of clarity and notes. The missed information was frustrating, as there’s no easy fix for either willfully or accidentally missing information – documents not being read was a big culprit, as they tend to be dry and boring to read, even if they do contain important information. Meetings likely would have benefitted from minutes and better note-taking, and definitely from being hard-copied and shared with everyone. Disagreements are harder, as communication is only going to continue to breakdown until everyone can get on the same page, and they aren’t necessarily easy to solve.

This could be a very long dissection of each communication issue, but instead here is how to try and avoid it: many students are shy or uncomfortable sharing with relative strangers – don’t be or force them to talk by specifically asking for their opinion. That being said, this is a course comprised of a lot of gamers and some of them have been molded by toxic communities – remind them to be respectful and considerate. If the team can’t come to an agreement, it’s up to the project manager to make a call – if the team really can’t abide by it, take it up with a higher authority, otherwise suck it up and move on, but still try to incorporate ideas from every member where possible.

2. Vision

Not being able to agree on a clear vision for the game was a long struggle that made progression a bit of a slog; unfortunately, it wasn’t an easy solve since there was no majority, just a lot of different ideas. In the end, a few different game concepts were drawn up and the team just had to pick one. It wasn’t possible to please everyone, and trying to was ultimately just wasting time.

3. Character Design

Concepts went so well it was a shock that the actual character design wasn’t smooth sailing. Once we had the concept we liked, a character turnaround came in, and suddenly it was clear that there was a big problem because the turnaround looked nothing like the concept art. There were two problems here: we didn’t have a definitive art style yet and we had skipped over some crucial steps in the design process (as going from concept to turnaround is generally a big no-no, there’s meant to be iterations in between to decide on a final look). This actually took weeks to resolve with character exploration, nailing down a look, color testing, and outfit designs. It was worth it in the end to have spent the time to do it right – no skipping steps! – as we had a character we and others really loved.

4. Levels

No one on the team was really a level designer, and our level concepts weren’t as clear as they could have been. That meant the whole level design process ended up being longer than it should have been. Concept art seemed to go better with some explanation text. Started looking at toy shop layouts and the kind of stuff that would be found in them, but realized that putting in shelves was going to be a bit problematic with our camera angle. Ultimately this was solved with a new/tweaked gameplay concept that ultimately ended up scrapped, but it introduced jumping and platforms and that stayed.

5. UI

No one on the team was really a designer or a UI designer, not even the person assigned to be the Design Lead. So we either fudged our way through it or left it really basic, where functionality exists but it could definitely use a makeover.

There was also some contention over how to structure the in-game UI. Early playtesters thought the game was something they had to do as quickly as possible and we wanted to try and correct that perception. Suspecting that the timer countdown being in the top center and therefore at the top of the visual hierarchy may have been a contributing factor, the score got moved central and the timer to the side. Players were no longer trying to speed through, but now some weren’t noticing the timer at all. This may still be solved by placing both items central, and using size to indicate hierarchy importance.

Problems, Failures, and Scraps:

1. Pipeline Processes

As mentioned earlier, students tend to want to put in the minimum amount of work required, and so one of the things that got lost in the process was the process. Workflow follows the same structure, if not always the same order, but generally looks something like references, moodboards, concepts, iterations, design polish, turnaround, final model. References and moodboards were rare to nonexistent for concepts and animation, as were iterations, polish, and turnarounds. Even enemy designs went straight from concept to final model; they turned out great, but that was truly just fortunate, and it could have gone very poorly.

2. 2D

Before Smash Everything had any kind of real identity, one of the things to decide was whether the game would be 2D, 3D, or some 2.5D mix. We had really only learned about 3D modeling and animation through our uni course, so there was good reason to go that direction. The downside being is 3D modeling, texturing, and animating can be quite lengthy – we obviously trimmed that work down to make it work. But before that was an idea, 2D was a fair solution for being quicker, especially for the amount of stuff we wanted to include. The downside being is that it meant learning new processes and software.

Compromised on 2.5D, a 2D sprite in 3D space, but ultimately it didn’t look great so 2D was scrapped altogether.

3. Enemy Behavior

Enemies were going to have all kinds of cool abilities when we were still young and naïve, like AoE slows, charges, stuns, whirlwinds, etc. That got cut pretty quick at the implementation stage, generally sticking with simple melee or ranged attacks.

One enemy had to have some drastic changes and cuts, the Snail, as originally he was meant to leave behind a trail of gas – that maybe dissipated or maybe lingered – that initially did a slow but since slows were gone it was just going to be another damaging ability of players ran through it… we just had no idea how to do it. So now he’s just harmless hammer-fodder that does his best to run away from your hammer. Slowly.

4. Skybox

This is one of those things where there is a surprising lack of tutorials on how to make one of these. Made an early skybox that was meant to be temporary as it was a bit of a fudge – made it seamless just by making a repeatable texture rather than through any skill, proper technique, or software.

5. Saving Scores

This was something mentioned in a previous blog post. Score counter, no problem. Saving scores and names, apparently not so easy. No one really knew how to do this, but for this there are tutorials, and so it should have been okay from there. Except it wasn’t. Unity allows input fields and character limits on them, so creating an input field with a 3-character limit for initials was no problem. Rather than use JSON, which may have been a bit out of our depth, went with saving scores and names in player prefs and then allowing the high score list to read from player prefs and adjust accordingly. And it worked… in the Unity editor. Once it was built, though, it was broken. Sometimes the score would save and write, sometimes, and names definitely weren’t being saved and/or written. Tried to even hardcore a cheeky fix in, but to no avail.

Not having scores save properly was a big disappointment, as scoring was kind of a big deal.

6. Smashables

Early in the game design process, Smashables were something that existed. Before we knew what we wanted to smash, it was just going to be a slew of items and inanimate objects. Even after we decided to include enemies, the Smashables idea persisted... until it didn’t. It just kind of slowly faded out of the game design as enemies were implemented, made a brief resurgence, and then just disappeared completed. No one missed them, they didn’t feel necessary, but they are one of those things that could easily fit back into the game - perhaps as a future addition.

0 notes