Puzzle

Postmortem – The Sound of Music

A SCRAPS postmortem by Matthew Mathis

What once was is now no longer…

This is the story of a world in shambles with multiple societal casts that dictate the quality of life throughout the world. This is the story of SCRAPS. Scrappers are sent out into the wastelands to retrieve scraps of things leftover from a time when the world was still in one piece. But our story had nothing to do with getting any old junk left around the world. Ours didn’t bother worrying about the cast system or the morality of sending another person out on a potential death mission just to get some dusty old can of soda. Ours was about the preservation of the last known piece of music in the world. The only beautiful thing left in a world devoid of beauty.

We were lucky in as much as having the core elements of the story and gameplay laid out for us beforehand. Our team set out to make something that would take the preexisting SCRAPS story to another level. We had heard what other teams had done before us and we wanted to make something a bit different. While other teams would be recovering items, we were recovering music. Going after the intangible seems like a very difficult but worthwhile mission indeed.

What went right?

Dreams – By Thomas Gaff

Finding the right piece of music was far easier than we thought it would be. Early on the team decided to use the idea of a world devoid of music except for one last rumored piece of it. But with music comes usage problems. We couldn’t just take any song off of the radio and place it in our game. We needed something that was fitting to the mood of the game, but was available, and that the composer provided consent to use. It all fell into place at the end of the first week. While surfing Twitter I stumbled across a post by composer Thomas Gaff, a close personal friend of mine, talking up his upcoming album. So, letting curiosity get the best of me I followed the link to the sample clips he had and there it was: Dreams. It had the right feel, it had the right ambience, and it was the right length. It was perfect. One of the hardest elements to procure fell right into our laps. I called Thomas up and asked if it would be okay if I added it to our game and he immediately said yes with the simple caveat: just give me credit, done. That provided the footing with which to base the rest of the game off of.

PerFORCE your updates

Our initial impression and thoughts of Perforce (the software used to keep everybody’s workspaces synced up throughout the project) were honestly, abysmal. It felt clunky, user friendliness was out of the question, and the documentation to use it was basically written for a high level programmer to skim through as toilet material. It seemed hopeless. During the entire first week we struggled with un-textured materials and work reconciliation not coming through in the depot. Thankfully we quickly discovered that it was a user side error and that the program was actually very efficient at the task it performed. During the second week we had some major issues with uploads not coming through, it ended up with a team meeting in which we walked each member through the process of getting the latest revision of the software and uploading their changes. This ultimately led to the ability of team members diagnosing problems in other members builds and being able to quickly implement the changes on their side and FORCING them over to the other persons client. This allowed us to debug the game at a pace that would not have been possible using any other method. This form of forced streamlining led our build and compile times to decrease dramatically each week from 2 minutes in the ALPHA week, to 45 seconds in the BETA week, and finally to less than 10 seconds in GOLD week.

All your SCRIPT are belong to me

One of the challenges we faced was to resolve the problem of each team member writing their own scripts for the same function. Initially this was not a problem, but when you have four different scripts for opening doors or sending a GUI message it can become a problem. We were making Unity save memory slots and think about scripts that all did the same thing, but had to have their own reference. One of our most successful steps toward optimizing the game was the use of consolidated scripts. We made a few scripts that had universal functionality. By toggling serialized Boolean statements on a universal trigger script the designer could toggle audio, text, an interaction, wake up another object afterwards, destroy an object, play an animation, trigger a story sequence, activate a respawn location, or even adjust the setting of the over world such as toggling the world light on or off and setting the world darkness to the appropriate level at the appropriate time. Hell, we could even deal damage, play a sound, update health, update speed, and track the player location, all with the use of one or two scripts working in tandem. Getting the world optimized by using similar scripts also reduced the bugs we had to chase in the long run, since changing the master script would resolve ALL similar problems throughout the world. This in tandem with perforce meant that a developer could state a problem, a scripter could go type a line of code, and it would update everything it needed to, resolving the problem and any future problems that could have been caused in similar situations, all without ever actually touching the other designers scene.

Nice desktop background bro!

Skype played an instrumental part in our team’s success during this project. It was the main method of contact between all of the team members and the screen sharing functionality allowed team members to share visually the exact problem they were experiencing. On more than one occasion we had team members who claimed that the problems in their world were resolved, but when everything was checked in the persistent scene on another computer, the problems were not resolved. Initially this resulted in small skirmishes in which each person was trying to prove that their work was functioning as intended. Skype put the kibosh on all of that by allowing us a simple and quick way to confirm or disprove the functionality of a specific build of the product. Often this lead to an advanced reconcile or a forced update of perforce to resolve the issue. Without it the debugging process would have been so much more painful than it ended up being.

What went wrong?

Did you just touch me bro? I’m pretty sure you just touched me.

We had a pretty significant problem with colliders throughout development. We literally had items falling through the world all the way up to the GOLD build. While the implementation and use of colliders is really simple and straight forward we ran into a few case situation in which it caused nothing but headaches. On occasion an asset would be considered “open” and when a mesh collider was attached to it Unity would spam the screen with critical errors, occasionally leading to a lockup of the system. It was discovered, in the last week, that some of our team members were attaching colliders to empty game objects, causing the error. This was happening because some of the assets consisted of multiple sub assets combined and held in place by a parent object, which was empty. Colliders were being applied to the parent object, with the expectation that it would place a mesh collider around the entire object. Well, it didn’t, and you know the rest…

You said “15 minutes”, it’s been 2 days…

One of our team members was consistently absent from the team. Throughout the month he would sporadically show up and get work done. The main problem was that his work would just appear in the depot without anybody knowing about it and the team would then have to spend time debugging the new problems that just basically appeared overnight.

You’re breaking up; I think we are losing our connection…

Being a team of individuals everyone had a different time slot that they were available for peak production. Some of our members did the majority of their work at night well into the wee hours of the morning. Others did work in the morning, and left by early afternoon. Some had to deal with circumstances that required their time be spent elsewhere for unknown amounts of time while still others just didn’t show up. The team was almost never in full sync which slowed our production cycle significantly. This was most apparent when work was all but halted while waiting for an update from another designer. While this marred the team throughout the month there were moments of clarity and it eventually led to the development of the unified script to allow for offline alterations to be made to other designer’s scenes without requiring them to be online or interacting with their world directly.

Pride comes before the fall

Some of the team members were not happy about the use of universal scripts to consolidate the functions of the game. This resulted in certain areas of the world being less optimized than others due to their refusal to use the assets. It also resulted in lengthy debugging sessions during which time the best method of solution was screen sharing with others and explaining what it happening, and how to fix it.

Takeaways (Advice)

Don’t overreach but don’t sell yourself short.

During the first week, make a level you think you can make, and then scale it down. Your lofty ideas are likely bigger than you have the time to achieve during this class.

Treat it like all you can eat sushi or a buffet.

Don’t try to build an entire encounter at one time. Pick one of the elements of your level and get it working perfectly. Then you can move on to the next one. Don’t do anything just halfway. If you got only halfway, it should be scrapped (forgive the pun).

Don’t get ahead of yourself.

Do what is required per week, don’t get ahead of yourself. Don’t worry about polish in the first week. Get your systems working, get your puzzles up and functioning as intended, debug them, and do it again. Short of throwing a quick texture on pink objects, don’t worry about that until week 2.

Learn perforce early.

Don’t wait until the end of week one to make sure everyone understands perforce and how to reconcile and submit. Get the entire team understanding perforce and its use as early as possible. This will save you so much trouble in the long run. Also, DON’T DELETE THE DEPOT. Got that?

Set a deadline and stick to it.

Don’t use the end of the week as the deadline for submissions. If everyone submits on Sunday, that leaves you NO TIME to debug and test. Require a submission from every team mate by Friday at the latest, then you have the weekend to tweak it and fix problems. This does not mean that once you submit on Friday you are done, you can still work on it during the weekend, but if you haven’t turned anything in until Sunday, how is the PLK supposed to stitch the world together or how are you supposed to bug test the whole world? Simple answer: You can’t.

If you saved, SUBMIT, unless….

This one is simple as it gets. If you just saved your project in Unity, upload it to the depot. If it was important enough for you to save on your end then surely it is important enough to backup. You’ll thank me later. The only exception to this rule is if you have a critical error in your scene. If you submit a scene with a critical error in it, DOING THAT WILL PREVENT EVERYONE ON THE TEAM FROM WORKING ON THE PROJECT. Don’t be that person.

Disable your FPC!!!

Before you submit, disable you FPC and ensure your level is working as intended. Believe me; not having to search the hierarchy for a pesky FPC who is ghosting around the level triggering all sorts of random stuff is worth the 1 second it takes to disable it before saving.

Conclusion

For whom the bell tolls…

Overall this project was a fun and exciting undertaking. Along the way we had our highs and we had our lows but overall we came out on top. From a purely personal standpoint this was one of the best experiences I have had at Full Sail up to this point. It allowed me to flex my creative muscles but it also led me to a deeper understanding of what a team project will be like in the future. A deeper understanding of many programs followed the tasks that were required throughout the weeks. I learned more things about Unity than I previously knew, I learned a bit more about re-mastering audio using Adobe Audition, and I learned texture creation in Fireworks, Paint, and Illustrator. I learned light mapping and creating glowing materials. I discovered the usefulness of linking scripts up to each other both through the inspector and by getting components from unlikely places. Last but not least, I learned that a team can achieve a lot more than an individual can.

References

Simche [username]. (2014). Sound of Music HD CLEARLOGO [image]. Retrieved from https://fanart.tv/movie/15121/the-sound-of-music/

Game Journal – Triple Town

Designer/Developer: SpryFox

Platform: Web Browser

Release Date: October 2011

Game Location: http://www.gamefools.com/onlinegames/play/tripletown.html

Explanation

In this game, players combine groups of three shrubs to create more complex structures. Players attempt to build towns and villages using the combination of threes to upgrade structures. Additionally players have a point goal they need to reach in each stage before they can move on. Players are provided with different objects to drop on the screen that alter the way the game is played. For example players can be given a bear that moves around randomly on the screen blocking the player from dropping shrubs or upgrading certain objects. There are items like crystals that allow the player to receive a free combination bonus and there are also robot items that allow a player to clear a used spot on the game board. Between stages the player is able to purchase items and decorations from the store. These can be used to upgrade the player’s home (like Farmville).

Screenshot

The game has a lot going on within its play screen. Starting in the top left corner we see two buttons. The first is the players Capital City, next to it is the options button. Top center is the player’s current score and in the top right is the progress bar showing the percentage completed for the current level. It also shows the total amount of points needed to upgrade to the next town type. Below that is the player’s money followed by their inventory. Players can purchase items from the Item Store that will appear in the inventory slots. In the bottom left corner notice the combination formula. Depending on the spot that the player is currently highlighting and the type of tile they are holding a combination will be displayed. This is used as a player aid so that they don’t have to remember all of the combinations in the game. On to the main part of the screen; here in the left most 2/3 of the screen we see that the game consists of a 6×6 grid that has many different types of tiles on it. The tile being selected by the player is shown with the black border and darkened background.

Strategy

Players should attempt to combine more than three things at a time to decrease clutter and optimize play space.
Using a crystal in the center of a cluster of similar items can save a lot of space and give the player a decent score boost.
Destroying pesky tiles with the robot can help the player get out of a tight spot.
Fencing bears into a small path can be a useful way of eliminating them without leaving gravestones behind (requires 3 or more bears).

Dynamics

Because players are forced to match three items to create one superior item the puzzle space gets reduced quickly, which steadily increases the level difficulty as the player progresses.
Each level requires a higher score than the last; this means more moves are required which further increases the difficulty.

Additional Notes

This game makes me think of how Farmville should have been. In other words, it should have been an actual game that one can play rather than a farming simulation, which, let’s face it, is hard pressed to be called a game, since all you really do is sit around and wait for crops to ripen or spam your friends to give you gifts (That may be too harsh a representation).

Similar Games

Bejeweled

Hexic

PuzzleQuest

FarmVille

Design Ideas

This game makes me think about what other types of game combinations would be fun together? A Racing MMO – FPS Farming – who knows? It also makes me wonder what types of gameplay can be taken and turned casual or puzzle based. What about a sort of chess/FPS/puzzle hybrid where the player has to match units against enemy units that have countering abilities. Like a sniper can kill a soldier, a soldier can kill a rocketeer, and a rocketeer can kill a sniper. Paper – Rock – Scissors style but tactical, and puzzle based. It would be a puzzle because the battlefield would be set up in such a way that the player would have to clear the field with a limited number of personnel. Hey, it could be fun.

Game Journal – Valiant Hearts

Designer/Developer: Ubisoft Montpellier

Platforms: PlayStation 3, PlayStation 4, Microsoft Windows, Xbox 360, Xbox One, iOS, Android

Release Date: June 24, 2014

Game Location: Variable

Explanation

Valiant Hearts is a side scrolling puzzle adventure that tells the story of the soldiers during The Great War (aka WWI). The player takes the role of four characters throughout the game: Emile, Karl, Freddie, and Belgian nurse Anna. Emile is the main character in the story and he joins the military to find his son-in-law Karl. An unfortunate circumstance of the story is that Emile is a Frenchman and his son-in-law Karl is German. The German army conscripts Karl into service and forces him to fight against the people he has lived with for many years. During Emile’s journey he meets an American soldier named Freddie. The soon discover that they are both seeking the same people. Eventually Anna, a Belgian nurse becomes a playable character and as a group Emile, Anna, and Freddie attempt to find Karl while defeating Germans and saving each other. The gameplay is quite robust for a side scrolling puzzle adventure game. Throughout the game the player is tasked with solving puzzles that require reflex, timing, pattern memory, and reasoning. The player almost always unarmed, receiving the required equipment when and only when they need it to advance the game. A dog is also provided to the player to aid them in retrieving items required for advancing the game.

Screenshot

As players proceed through the game they encounter items that reveal facts about The Great War. The facts often reveal the horrendous conditions that soldiers had to face while fighting in the trenches. While following the story of the characters players are placed into high-profile situations and events that occurred during the war like the battle at the Marne, the battle of the Somme, and the Nivelle Offensive. The game progresses through a myriad of backdrops and scenarios ranging from dank and

bleak destroyed cities to bright and colorful county sides. The image above shows an example of an information snippet provided to the player during gameplay. Below is the scene of a zeppelin crash were the player controls Anna who is hot on the trail of Karl and has tracked him to this crash site.

Strategy

To discover all of the objects the player should always progress left in each area first. By doing so they will typically discover one or two items that they may have missed if they had progressed to the right as is the natural tendency of the typical player.
The game does a good job of showing the player the attack pattern of the enemies they encounter. In order to progress steadily the player should take a moment when encountering a new situation to study the pattern of the enemy.

Dynamics

Because the character is only able to utilize one item at a time it is often in the player’s best interest to pick up whatever item they come across as it is more often than not the item they will need to solve the next puzzle.

When the player is assisted by a dog they can give an item to the dog and leave it in his care for the duration of a level. That way they can call the dog at any time and swap items.

When going for 100% completion of the game the player need not worry about getting every item in every level on their first play though. The game will allow the player to replay any level or mission again after they have played through the game.

During the driving scenes in the game the bombs typically land on the quarter notes of the song being played. The machinegun fire often comes during times in the song that use 1/16^th notes.

Additional Notes

I found this game to be compelling in both story and gameplay. Aesthetically the game is amazing. I spent a good 20 minutes when I first started playing the game trying to determine what type of design they used to create the scrolling backdrops. At first I thought that they were using flat 2D backdrops and a parallax algorithm to move the background appropriately but then I saw the side of a building coming into and going out of view. That led me to wonder if they were using 3D assets in the background and 2D assets in the foreground. After a bit more studying I determined that they were utilizing a combination of 3D and 2D assets in both the fore and background. That is not to say that they were though. If the game was utilizing dynamic 2D lighting techniques it could very well be completely 2D. But I will stick with my combination theory.

Similar Games

While I am hard pressed to find games just like Valiant Hearts a few do come to mind.

Never Alone (Kisima Innitchuna)

Dust: An Elysian Tale

Bastion

Design Ideas

This game is almost too good for me to get any ideas from it. If I were to make a side scrolling adventure game I would want it to have a compelling story, an amazing soundtrack, and relatable characters. If I had to choose something I would say that this game gives me the idea of making more games about events that people are likely undereducated in. I think as a platform, Valiant Hearts is right on the money with a game that can be just as fun as it is educational. If educational game designers took a page out of Valiant Hearts playbook I believe they could successfully transition from mostly boring games with good ideas to good games with good ideas and a good method to convey educational lessons to people of all ages.

Game Journal – GeoGuessr

Designer: Anton Wallen

Platform: Web Browser

Date Played: May 6, 2014

Game Location: http://www.geoguessr.com/

Explanation

The game is a simple point and click game. The player is provided with an image of some random place in the World. They may look around and even follow the road forward or backward. Using just the image available the player must attempt to figure out where the image was taken in the World. Then the player clicks on a map in the upper right corner of the screen to make a guess. Scores are provided based on how close the guess was to the actual location. This is repeated 4 more times for a total of 5 rounds. Players may create challenges and issue them to friends for an added level of fun. They may also race against the clock to see just how fast they really are.

Screenshot

This image shows the play UI for the game. The two arrows near the bottom center are your navigation arrows. They allow the player to travel up and down the road (to a certain extent). Zooming and looking can be performed with the tool in the upper left corner or by using the common mouse functions like click, drag, and scroll. The map in the upper right corner is for making a guess at the location of the image. It too can be zoomed and panned. Beneath the map is the points earned last round, total points, and the round identifier. There is also a reset button that will snap you back to where you were in the image when you first saw it. Across the top of the screen are the Help, Feedback, Share, and Set Time Limit/Create Challenge buttons. The white oval in the center of the image is the mouse indicator, it changes based on the terrain and action you may perform. For example, when it is an oval clicking will cause the image to “jump” to that position, but you are still restricted to the road for the point of view.

Strategy

This game focuses on finding clues about your location. This can be done in many ways:

Identifying foliage
- Knowledgeable players may use the plant life in the image to determine the location or the region in which the image was taken.

Determine Driving Direction
- Looking almost straight down a player will see the blurred out vehicle that takes the pictures. While the vehicle is not visible, the blur is, and players can determine what the front of the vehicle is to determine driving direction. Looking for the side view mirrors helps a lot (this is not always possible).
- After determining driving direction players can determine which side of the road the vehicle is traveling on, narrowing the possibilities somewhat.

Find a vehicle
- Finding a vehicle can be very helpful. Players can look at the shape of the license plate to determine if they are in Europe or not (European plates are long rectangles mostly).

Find a road sign
Mile Markers
- Sometimes they will have the mile and highway identifier on them (unless blurred out).
Speed Signs
- They may identify the highway, but at the very least they will show MPH or KPH which can narrow the results.
Street Sign
- Finding the name of a street can be helpful; it may even provide a language key to the puzzle.
Distance Signs
- This is the ultimate find. They may literally tell you the city, the highway, or nearby towns relative to the image position.

Get Familiar with Google Street View
- Will Oremus suggests getting familiar with Google’s Street View Map. It shows where street view has been, narrowing your search significantly. It is good to know that almost all of Asia is “unviewed” as well as half of South America and most of Africa (2013).

Dynamics

It is difficult if not impossible to receive the maximum score of 32395 because the location selection is VERY sensitive. A player must be within 9 meters of the image location to receive a perfect score per turn (6,479 pts/round).

The unlimited amount of traveling a player is allowed paired with the lack of a time limit in standard play lends itself to cheating via Google searching.

It seems to be impossible to score 0 points, meaning that no matter where the location is a player will receive some sort of score even if they guess in Antarctica repeatedly.

Similar Games

GeoGuessr (Android, clone made by Felipe Caldas), Where Am I?

Design Ideas

This game made me think of a sort of first person survival game where the player is dropped off in a random location and must navigate home or to some preset location. Another idea would be to play the game in reverse. Give the player a location. Then provide a selection of images. The player must try to choose the correct image relating to the location provided. This could be a good casual game on a mobile platform, players could even take pictures themselves and upload them to increase the amount of “challenges” the player has.

Resources

Oremus, W. (2013). How to Beat GeoGuessr, the Insanely Addictive Google Maps Guessing Game. Retrieved from http://www.slate.com/articles/technology/future_tense/2013/05/google_maps_guessing_game_geoguessr_tips_and_cheats_to_beat_the_game.html

Matt Mathis

Matt Mathis

Puzzle

Postmortem – The Sound of Music

Game Journal – Triple Town

Game Journal – Valiant Hearts

Game Journal – GeoGuessr