smasheverythinggame

[smasheverythinggame]

[smasheverythinggame]

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.

[smasheverythinggame]

Saving Scores & Names

This was a big feature that ended up being broken in our demo, which was quite unfortunate. And frustrating, too, as the functionality actually worked correctly in the Unity editor but broke in the build.

This was the code to save and check for new high scores.

The code to write scores to the leader board.

This was part of a larger game over script, with checks at level both instances of level cleared/success and game over.

[JP]

[smasheverythinggame]

Smash Everything Demo

[JP]

[smasheverythinggame]

Platform Textures

Our platforms have been living as orange squares since the beginning of its prototype, to the point where we started to wonder if that’s just what they looked like. Admittedly, it was fine, just kind of visually bland.

Since we came up with the overarching toy theme, checkerboard and floorboards had been in the plans for a while - the kind of floors that show up in toy shops. Either a vibrant kind of checkered pattern or a more antique/vintage looking shop with floorboards. Problem was... they didn’t really look that great slapped on the platforms.

We needed something else that looked better, and found it in some of the early concept art. Originally, along with enemies, Smash Everything was going to have some Smashables as well - just breakable objects that were pretty much hammer fodder, but they ended up just kind of quietly fading out of existence. But we had some concept art for various inanimate objects that could be Smashables. At one point, we thought we would spell out the game title with the alphabet blocks, but then we deviated a bit from that heavy toy store theme.

But the blocks seemed perfect for the platforms. So the platforms became full on squares and got textured with letters and, because it’s the cheeky kind of thing devs would do, the letters are the first letters of each of our names. Maybe spelling out S M A S H would’ve been better, in hindsight - get the subliminal message going - but that’s besides the point. The point is, the blocks look great as the platform textures: they’re simple, they’re vibrant, they fit. 

And I mentioned they were simple right? These textures came very late in the game-making process, not to mention at the end of the semester, so it was crunch-time and there wasn’t a great deal of time to mess around with these. They were made pretty speedily in Photoshop using two square shapes, lettering, and simple bump maps made just using the emboss filter. Prefabs were made in Unity of each letter block, duplicated, and recolored for some variety. 

Had it been done less hacky, blocks would’ve had randomized spawning from a generator or pooler and randomized coloring as well, or at least an array to choose from. But I am not a coder and it was easier to just put it all in manually and have static level configurations.

In the end, it looks good, and it was quick and easy, and that’s really what counts.

[JP]

[smasheverythinggame]

Playtesting

Smash Everything held some fairly casual playtesting of its current build. No questions or scripts, no prompts or hints. Players simply opened the game and played it how they thought was appropriate and their play and comments were observed and recorded. 

In the current build, there are 5 platforms which can spawn enemies and an orb on each which controls these spawns. There are several platforms which players can jump to. Only two enemy types exist in this build: a melee and a shooter ranged. The player has only one attack - a hammer smash with small AOE effect. 

Several players did a speed run of the level and competed with each other for the fastest time. After they did this, observer prompted them to go for a high score, as there would be a high score feature implemented later down the line. One particpant in particular really took to the idea and spent hours chasing the best strat and score and recorded his best attempt.

A few important issues, bugs, and general complaints came from the playtesting:

1. Players are trying to speed run instead of going for a high score on initial start. While it could be fun to have a speed run option, this game isn’t quite built for that so we need to find a way to shift the starting player’s mentality. (Hopefully placing the score counter where the timer currently is will be a good start.)

    -- A new spawner has been implemented that circles around the platform and takes multiple hits to destroy - preventing players from racing off and immediately destroying the spawner before it even spawns anything

2. Each spawner has a set amount of waves, and there’s some player confusion about if the spawning is meant to end or not. Also, once pool max was reached, if players culled pool back under max the spawning still would not resume. (May need UI to show wave number.)

    -- Pool size increased. By a lot.

3. Enemy tanks are too hard, is the general consensus put politely. Main issue being hard to dodge their bullets, especially if they spawn near you and are already looking at you. (Can look at adjusting bullet speed, tracking speed, shoot delay; enemy spawn indicators will also go into the game, to show where the enemy is about to spawn, which may help solve this issue.)

4. Perspective makes some of the jumps hard to judge/creates depth perception issues. (Can adjust the camera angle.)

Despite some of the issues and all of the features not yet being implemented, feedback about the game has been really positive, which is great to here. Many of the playtesters have come out saying it’s a fun little game, then come back a few days later going, “this is addictive!”

[JP]

[smasheverythinggame]

The Preproduction Process

There are four team members working on this game, all of us uni students with limited amounts of game-making experience. We were somewhat randomly placed into our groups based on the game pitches we voted for (each student in the class had an hour and a half to come up with a two minute game idea pitch) and our abilities based on a survey we completed.

Once we had our team, we sat down to dole out roles (figure out who can do what, figure out who can figure out how to do what) and discuss how the game should work, where immediately new ideas started to come out. Between this and some early level concept art trying to imagine what the game looked like - we had a lot of ideas (jumping puzzles, powerups, multiple smash attacks, obstacle courses, multiple difficulty settings). But we only had a short amount of time to work in and certain criteria to meet, so stuff needed to get pruned. Ideas were held up against our personas, our game pillars, the assignment criteria, and even against the game title and retained or discarded accordingly. Some ideas hovered in between and needed further discussion and reworking. The ideas that were retained were worked into a few different new game concepts that would keep the game small and simple but still hopefully fun, challenging, entertaining, and team members had to pick one. This did not necessarily end new ideas or changes right away, but at least set us on a definitive, more restrictive course for the game.

This allowed us to fill up our Trello board with most of our major tasks, as even if we made more game changes we would still need certain things - like a main character, animations, enemy models, textures, sounds, music, UI, code scripts.

The process of getting our main character knuckled down was surprisingly arduous, as we had a very early concept that we all loved. Our biggest issue was that while we all liked the idea, we all had wildly different art styles and ideas of what it should like that ended up deviating pretty far from the concept art. This meant spending extra weeks on exploring the character and coming to an agreement on the style and proportions of the character, and then further time to explore and lock in the design, colors and outfit of the character. Arduous, but worth it, as not only are we happy with the main character design but playtesters now comment on what a great character it is. 

After such long processes with the game design and main character design, enemy concepts got quite streamlined. Team members filled out a sheet with four empty squares with a sketch of their ideas and one ability that each enemy could possibly have; all the ideas were correlated into a giant survey and members voted on their favorite designs. Designs with the most votes got selected, and tiebreakers resolved by picking one done by someone who hadn’t had an enemy design selected yet. 

Level design was our most difficult challenge, as we all sort of struggled with it for various reasons. At first because we had no idea what the game should look like and then because our game design idea was still too up in the air, but ultimately we just weren’t great at storyboarding or expressing our ideas and so we really had to work for our level design concepts.

This pretty much concluded our preproduction and allowed us to move onto actually producing assets.

[JP]

[smasheverythinggame]

These images take us through the process of developing our main character for Smash Everything. At the idea concepting stage, we picked out the Toy Smasher as the idea that we liked and, from there, decided we would definitely like it to be a plush toy. 

Should it be a bunny? Are these the colors we like? Is that her outfit? What kind of markings should she have? Since sketches at this point kept coming out bunny, it seems like we were on board with the plush toy being a bunny. Colors, marking, and outfit were a bit more up in the air. Again, with markings, a similar patched quarter face kept appearing on her, so went ahead and made that a definite part of her character - though exactly what shape/how much of the face it took up was a finer detail to work out. 

From there, it was outfit design and nailing her color palette. We liked pink and purple, but on their own they were a bit much and so we tried out some other colors that looked nice with them. Final colors were chosen with consideration to appeal, design aesthetic, and readability. The outfit wasn’t too hard to nail down; we liked the idea of the long coat and having a higher collar that covered the bottom of her face - kinda cute and badass at the same time - and from the jacket designs picked our favorite.

The final character design is the one in the green square, which has a very charming coat with a bit of a dressy feel to it, pants so you know she means business, a pink ribbon at the neck of the coat and a repeating pink element on the pants to keep it tied in, and pale pink main body color.

[smasheverythinggame]

Some early stage prototype of gameplay, where players participate in an arena of endless mobs. Enemies spawn from the toy shelves and jump down into the arena, moving towards the player. Smashable items also spawn into the arena. At this stage, it’s pretty easy to keep up with the enemy waves, which could make for a good start to the game. From here, we will start adding in some enemy variety. Enemies which have their own unique ability and behaviors, casters, melee, perhaps some AoE slows and attacks.

Mostly this was a test and confirmation that the main mechanic of this game - smashing - feels good and is fun, as the whole game revolves around this.

[smasheverythinggame]

Game Design Revamp

Once team members were introduced to the game project, several new ideas were pitched that resulted in a theme for the game as well an altered game idea. The character would be a “Toy Smasher”, some kind of stuffed animal, and the game would be set in or reminiscent of a toy store. Rather than play like a side-scroller with static items to smash, the game will now play like an arena, with the character enclosed on a platform and waves of enemy toys constantly spawning. The goal is still to smash everything - though perhaps a more appropriate name is now Smash Arena? - and now also to survive for as long as possible.

The new game pillars:

1. Whimsical – Playful, vibrant colors and a silly game world. Nothing is taken too seriously. Light-hearted fun.

2. Destruction – Everything, barring the level layout, should be destroyable. Destroying things should feel good and make players enjoy and want to destroy more.

3. Inundation/Survival – The longer the game goes on, the harder it should be for the player to remain alive. (Survival is a broad term and genre, this specifically relates to, eventually, being overwhelmed by enemy numbers/enemy attacks)

The game remains in the concept stage as we work out our main character’s look, weapon, enemy types, smashable objects, level design, and even the overall game art design.

[JP]

[smasheverythinggame]

Initial “Smash Everything” Game Pitch

This game was initially pitched as a side-scroller-type game where the player tries to smash as many things as possible, as quickly as possible, always moving forward - never allowed to move backwards. Racking up points for a high score. The game pillars would be something like:

1. Whimsical – Playful, vibrant colors and a silly game world. Nothing is taken too seriously. Light-hearted, destructive fun.

 2. Destruction – Everything, barring the level layout, should be smashable. Destroying and smashing things should feel good and make players enjoy and want to destroy more.

 3. Race Against the Clock - Players should feel the need to be moving constantly and quickly, that pausing is a detriment.

[JP]