Design Life - A Student's Journey

Most of the pre-production documentation is done, so we’re almost at the fun part where all the mechanics and art can be worked on. On that topic, we had a bit of spare time for one of the programmers today and even managed to get basic movement going for a kart prototype.

The team is coming together pretty nicely too. While maybe not very active in chat, everyone is getting along and can be contacted if needed.

I’m also starting to get the hang of KacknPlan. The trick is to break up tasks into small chunks, so that progress can be monitored and help can be offered if needed, rather than allowing people to get stuck on something and just not mention that they aren’t making progress. Being able to monitor progress is also extremely important for keeping an eye on the burndown chart, so it pays off in multiple ways.

In the space of one day our game almost tripled in scope, with the addition of many new assets. I believe this is due to a lack of clarity in the GDD, so i’m now starting to understand why it’s so important for the GDD to be very specific about the direction of a project. If the artists on a team are coming up with ideas as to how a level should be put together (even after reading the GDD), then obviously the GDD needs to be updated to clarify that.

But at the end of the day my job is to make sure this doesn’t happen, so I’ve obviously got a lot to learn. In future, when confusion arises as to the direction of the project, the first thing I need to do is notify the designer, not talk to the artists for 30 minutes about the pros and cons of the ideas they’re coming up with. I’m not the designer, so I need to stop acting like one.

I’ve grabbed the producer role for this project due to my confidence with communication, public speaking and writing documents, but also due to my lack of confidence with the general design process. This gives me the ability to watch the other designers work and learn from them in the process, while managing the project’s documentation, scope, burndown chart, scrum meetings, the handing out of tasks to complete and mitigating any issues team members have during the duration of the project. So I’ve definitely got my work cut out for me.

So far the team has come up with a concept and been approved for production, but we have to a present our Alpha build in about two weeks to a panel of actual industry professionals, who have been tasked with essentially bringing the teams back down to earth by pointing out what we’ve forgotten or done wrong. So the pressure is on.

Oh and we also have a logo that one of the artists threw together for the team.

This time the “theme” revolves around developing a character and world on paper (which we’ve already covered) before attempting to use this information to tell a story through gameplay. Narrative devices/techniques are to be used to drive the story in a game, with extra points being awarded for less text and audio dialogue and more environmental gameplay. As I mentioned previously, i’ll also be doing a series of posts on the devices themselves, so i’d like to keep most of the descriptions of the devices to those posts and keep the project itself separate until the postmortem at the end.

The devices themselves and the way in which they can be implemented will vary and depend greatly on your situation, but I’ll list a few here to help paint a picture of what I’m talking about.

A few examples include:

Lighting

Background Audio

Textures/Decals

Particles

Color

Movement/Body Language of Character (not just the player)

Mechanics as a Metaphor

Framing

Placement of items within the level

Timing

Post Effects

The list continues well beyond what I’ve stated here, but an easy way to think of it is what elements in this game help to deliver a story (whatever that story may be). If you design a game well, almost anything can be a narrative device and to illustrate this point I’m going to break this up into a series of posts over the next few days, going into more detail on a few of these devices. I’ll then follow up with a postmortem of my latest vertical slice, explaining how I’ve used each of these in an attempt to drive the narrative. 

NEVER MAKE MORE WORK FOR YOURSELF THAN NEEDED! That may sound as if it’s pretty obvious, but you’d be surprised just how easily you can trick yourself. “My game would be so much better if [insert generic excuse here]” is a sentence that just keeps sneaking up on me and I’m going to have to be more wary of it. Just because your code looks neater, and/or is 50% more efficient does not mean that the time invested is worth it. So I've worked out a few questions to ask myself in the future (these are basically just the same question worded differently, but coming at it from different angles will help me not trick myself):

No.1 - Will the player even notice the extra effort or is it mostly just because you’re a perfectionist? No.2 - Will it help the game perform better? No.2.5 - Does the game NEED to perform better? No.3 -  Does the extra [insert reason here] REALLY justify the amount of time needed to make the changes? Is it proportional?

The GIF above is the result of a little more work than i’d like to admit, but over the next 4 weeks this humble beginning will grow into the first game that I’ve designed and then made myself. 

This is the process involved:

I have created a GDD (Game Design Document) specifying the functions and look of the project, put together an asset list on HackNPlan to keep all the individual tasks under control and then put the asset list into a burn down chart to make sure I even had enough time to make the entire game. Based on the image below I should finish up a week before the deadline, but I guess we’ll see how I go.

OK, so for starters please excuse the quality of the GIF. I just started using a new program and i’m still not quite sure how to lower the file size without deleting frames or drastically shrinking the resolution.

Now on to the main part: Over the last two weeks my course has been introducing everyone to programming in C#. For me this is my first language (other than about a week in Visual Basic 10 years ago), so it’s all very exciting and very daunting all at the same time. To top it off we only have another 4 weeks until we need to move on to the next unit, so it’s really not much time to wrap your head around a language. On the upside I’ve learnt so much recently that it’s actually difficult to know where to start.

The image above is an example of some simple key-frame animation in Unity. It consists of just rotating the light’s axis and turning a plane with a texture on it on/off when the light has its colour changed. The camera is also slightly tilted to add to the uneasiness of the scene.

This next image was the introduction to joints and rigging in Maya. Given no more than about 30 minutes, we were required to add the joints, attach them to the mesh and then animate them, before exporting the mesh to Unity and setting up the animation to play. Once again a relatively simple exercise, but a rewarding one nonetheless. 

Given the lack of time, we were unable to go over any of the techniques and/or principles of animation, but this link underneath provides a great introduction to the concepts.

Went from this

To this

FTL Analysis

By Christian Tydell

Overview

FTL is a top-down roguelike developed and published by Subset Games in 20012. 

Set in a futuristic universe where humanity has made it to the far corners of the galaxy, the player finds themselves on the wrong side of the tracks as they race back to their “safe” space with vital information that could give their allies the upper hand in the oncoming rebellion.

Gameplay

Gameplay in FTL is split between two major modes; travel and events. The player needs to plot a course between the beacons laid out in each system, simultaneously collecting resources to upgrade their ship and attempting to stay in front of the approaching rebel fleet. Each new beacon they arrive at has a procedurally generated event, meaning the player has no idea what to expect as they travel through systems. This creates an interesting mix between strategy and exploration, giving players plenty of reason to play the game again whether they win or lose.

The player also needs to manage the various systems on the ship itself, especially during combat. The ship is fitted with weapons, shields, an engine, life support, a medbay and a cockpit, as well as a few other systems, some of which are situational like drone bays and a cloaking device. These systems all fit together to create some very tense moments where the player has to decide if they should stay and fight for a potential reward, or run to fight another day.

Core Mechanics

Travel

Travel is handled via the beacon and sector maps respectively. The player is able to “jump” to a beacon adjacent to their current location, with the goal being to reach the exit beacon before the rebel fleet overtakes the sector. The player then moves on the next sector and repeats the process until they reach the 8th/final sector. Each “jump” costs 1 fuel, which is something players need to keep in mind or find themselves unable to move forwards. The ship is fitted with an emergency distress signal, but that risks drawing the attention of enemies rather than friendlies. If they do not leave the sector in time and the rebel fleet catches up, the player is forced to battle very difficult opponents and they are lucky if they survive long enough to “jump” to safety. Travel also affects the game’s difficulty as enemies get stronger each time the player enters a new sector.

Events

Events in FTL are procedurally generated, meaning the player gets a different experience each time they play. This is great for replay value, but can sometimes feel as if the cards are stacked against the player as they go from bad luck to dead very quickly. The events are activated upon arriving at a beacon for the first time. They include encountering enemies that are determined to fight, coming across allies that help out the player in one way or another and situations where the player is provided with a choice of actions relevant to the event. Each of the choice based events also appear to have at least two different results, meaning that choosing an action can either reward the player or punish them, adding to the random aspect of the game. There are also quest events where the player is required to travel to a particular beacon, these events can be difficult to fit into your time in each sector, but the rewards can be well worth it, with some of the quests even unlocking new ships for another play through

Combat

Combat can either be semi strategic or more gung ho, but successful runs require that the player plan out their attacks to maximise their effect. The use of the pause button is a big contributor to strategic play, allowing the player to take stock, manage the ships systems and time weapons fire to take down the enemies shields and deal damage to their systems. Weapons range from missile launchers that ignore shields (perfect for quickly taking down the enemy shields), lasers that are great for taking down systems when the enemies shields are down, ion weapons that ignore shields and disable systems rather than damage them and beam weapons that deal a lot of damage to the hull but are completely useless against shields. The player also needs to manage their own systems during combat as the enemy attempts to destroy them. This requires assigning crew members to different systems so that they can be repaired as they are damaged and upgrading systems when they are found lacking. If this is not handled well the player will soon find themselves without shields, weapons or the ability to “jump” away due to their engines being disabled. Overall, combat can be incredibly satisfying or completely disheartening, and yet the player often finds themselves having another go regardless of how dismally they failed previously. This speaks heavily for the game’s procedurally generated events and just goes to show that not knowing what to expect is great cause for replaying something.

Dynamics and Aesthetics

Travel and Events

The dynamic between travel and events form the majority of the player’s experience in FTL and create aesthetics of challenge, discovery and fantasy. Depending on how the player is doing, events can cause a range of emotions including tension/apprehension as the player limps between beacons barely surviving, or excitement when the player is doing well enough to not have to worry about encountering enemies and so can jump to new beacons with a sense of curiosity. On top of this the dynamic helps to create narrative as players learn about the universe they’re a part of, giving more weight to choices such as whether or not to allow the slavers to surrender, knowing that they’re just going to cause more suffering and how much you need that scrap vs the slave they’re offering for their safety.

Travel and Combat

Travel and combat create a great deal of challenge as they encourage the player to try out new strategies and tactics. As the player learns from previous mistakes they make different choices that can completely change the way the game turns out, be it for better or worse. This dynamic also makes the game competitive. Being defeated doesn’t mean the player isn’t good enough, but rather they feel they just haven’t found the right combination of weapons and upgrades and should try again.

Events and Combat

Some of the events do not immediately start out as combat, allowing the player to choose whether or not they want to fight. This dynamic offers the player a small sense of control helps sell the discovery aesthetic even when the player is only just surviving. The idea that the reward just around the corner might give them the edge needed to keep going drives the player on to the next beacon.

Other Mechanics

Ship Systems

There are a considerable amount of ship systems available, but the player is limited to only a handful at a time due to the cost in scrap, amount of power available and the type of ship itself. There is only so much power the ship is capable of producing, so choosing what to upgrade can be tricky and depends on how the player is going.

Standard Systems:

Cockpit

Engine

Weapons

Shields

O2/Life support

Medbay

Sensors

Door System

Situation/Ship dependent:

Cloaking

Drone Bay

Teleporter

Augmentations

Augmentations can be found or bought and provide a range of functions ranging from bonuses to weapon fire rate, to collecting drone parts at the end of combat.

Scrap

Scrap allows players to upgrade their ship, is used as money in shops and can be traded in events for useful items. It can be found by destroying ships, offered as a reward for quests/allowing enemies to surrender and found occasionally when jumping to a new beacon.

Shops

Shops sell items to help the player survive their journey, including crew members, weapons, augmentations, fuel, missiles and drone parts. provide respite by providing a space players won’t be attacked. Able to be seen from a beacon next to the player’s current location, they are one of the only places the player can jump to knowing what to expect.

Core Loops

The core loop of FTL is one of exploration. Players “jump” from beacon to beacon, fight enemies and manage ship systems. The order in which these tasks are performed varies depending on the situation, but an average loop could consist of traveling to a new beacon, encountering a pirate, fighting the pirate, repairing the ship and then repeating the process.

Level Loops

Depending on your opinion, level loops could either be what happens at each beacon, or the process of making it from one sector to the next. In this case i’m going to consider it from sector to sector, so a standard level loop would begin upon arriving at a new sector, exploring the sector, collecting scrap, upgrading ship systems and fighting enemies encountered along the way.

M2M Loops

The moment to moment loops are similar to the core loops, but with a lot more fiddling. A standard moment to moment loop during combat would consist of waiting for weapons to charge, pausing the game to choose what enemy systems to aim for, resuming the game and waiting to see the outcome, assigning crew to fix the damage on your own systems and repeating the process.

Exit Point

The images above were a collection of things I was working on at the time, including height/weight/angle based texturing of a landscape, a height map import of the Saint Lucia island in the Caribbean as the landscape itself and a day/night cycle/clock/calendar that was a combination of about 2-3 different tutorials on YouTube, with the majority of the code coming from Kleiner Baer.

Here is a screenshot of the node based material that I was using for the landscape.

This is a character that I modeled, rigged and then animated.

The helmet I was modelling for the character based on a saber tooth skull. I was actually more proud of this than the rest of the character.

And to finish it off I’ll throw in a map I made in Photoshop about 3-4 years back.