interactivedesignlife-blog

[interactivedesignlife-blog]

Homemade pizza and new spline tool. Now this is living!

[interactivedesignlife-blog]

EOYP - Week 2 - Part 3

We’re nearing the start of week 3 and things are beginning to fall into place now.

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.

I am in no way as over confident as I was a week ago, but progress is good and I have a small amount of hope that this project will not only be finished on time, but might actually be fun too.

[interactivedesignlife-blog]

EOYP - Week 2 - Part 2

OK, so producing a game is a lot harder than I was expecting. Don’t ask me why I was expecting it to be easy, but it turns out that handing out tasks and being good at communicating with the team is not enough. If a producer can’t keep the team on focused on the current goal and not adding extra work to the project, then said producer needs rethink their approach.

Read on below...

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.

That being said i’m still very new at this, so it’s not like i’m giving myself a hard time. It is however important that I learn from these experiences and I may as well share them while I do.

[interactivedesignlife-blog]

End of year project - Week 2

So the dreaded end of year project is upon us.

I’m currently working with a team of two artists, two programmers and two designers (not including myself) in an attempt to concept and then develop an entire game in around two months...

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.

[interactivedesignlife-blog]

Printing Advice 101

Do a test round well before you need the final product. No matter how much you think you know that colour differs in print, you'll still most likely end up with a dull, washed out version of what you wanted.

[interactivedesignlife-blog]

Narrative Unit - Prototype

In the same fashion as the last few units, the time has come to create a vertical slice/prototype to demonstrate our understanding of the content we’re being taught. 

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.

So far I've knocked out 99% of the greybox, with all the gameplay elements and functionality added as well. The next step is to create and add all the art, so you’ll get another post when I’ve managed to make the project look a bit nicer.

[interactivedesignlife-blog]

Narrative Devices 101 - Part 1

The unit i’m currently in at the moment revolves around the telling of stories using narrative devices. Due to the medium these devices differ from standard literary narrative techniques, but the end of the day the concept remains the same. A narrative device is (regardless of your chosen trade) a technique/method/device in which to portray narrative.

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. 

[interactivedesignlife-blog]

32 colour palettes in and I still have no idea what to choose for this level...

[interactivedesignlife-blog]

Procedural Fun: Explosions

First time touching any kind of procedural and I’m pretty happy with the results. The code itself is pretty basic, but it’s the aesthetic that really does it for me here.

[interactivedesignlife-blog]

Class Project: Click To Move + Projectiles

Today the class got to working on something that might look pretty familiar to those of you who have seen my last post and there’s a good reason for that.

We essentially made what I've been working on for the last two weeks in about 2 hours today. Now you might think that would be a little frustrating, but there was an interesting (albeit unintended) point that I took away from today and that’s...

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?

Now these aren’t guaranteed to fix the problem for me (or anyone else for that matter), but they do at least get me to think about why I’m doing that particular something and hopefully that’s enough to save me even just a few hours in the long run.

[interactivedesignlife-blog]

Programming Project - Basic Movement and Camera

The other day I shared a simple endless runner that i’d been working on in class, but today i’d like to show you the beginnings of something a little more interesting. Behold my amazing game!

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.

Next in my long list of things to do is add enemies that slowly approach the player before firing projectiles at them when they get within a certain distance. So until I work that bit out I’ll leave this here for now.

[interactivedesignlife-blog]

Endless Runner

So I’ve been a little busy recently what with moving house, booking flights to Queensland and other such things, but with so much happening in my course lately I figured it’s time to put up a post.

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.

This GIF here is what we did today. It’s a very simple project with one script telling the level to generate in front of the character and another script telling the character to move forwards. On top of that I managed to work out how to move the character side-to-side, add a basic jump and detect if it’s hitting the barriers. That’s pretty much everything other than the art assets you can see in the GIF.

[interactivedesignlife-blog]

Animation

Yesterday was a crash course in animation, so keep in mind that we had a little under 4 hours to cover an entire career worth of knowledge. That being said, here’s some of what I managed to get out of the exercise.

Continue below:

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.

[interactivedesignlife-blog]

Maya: Lighting

Spent a few hours playing around with lighting today. You should read bellow, there’s not much writing and some very nice pictures.

Went from this

To this

There was a few post process effects going on at the end here, but most of the aesthetic was generated by the intensity and hue of the lights. 

[interactivedesignlife-blog]

Not quite sure as to the purpose of this game, but after patiently shoveling shit for the last 30 minutes or so, my patience has finally come to an end. There appears to be no reward for cleaning up after this bunch of pixels other than maybe the small amount of satisfaction from watching the days progress. Other than that this game appears pointless and has lost my interest.

  That being said, for a short period of time this very simple mechanic was rather enjoyable and got me thinking of working on something similar. Sort of like the old Digimon/Tamagotchi toys we used to play with as kids, but for the mobile phone instead. I’m fairly sure it would have been done already, but that doesn’t mean it can’t be done better.

[interactivedesignlife-blog]

Game Analysis: FTL

In case I haven’t mentioned it before, part of the requirements for passing the course i’m doing is to post a monthly game analysis. I believe the idea is to give us practice thinking of games from a design perspective rather than a gamer’s. I forgot to post this one the other day, so without further ado I present last month’s analysis: Faster Than Light (better known as FTL).

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

An average exit point would vary depending on time available, but would generally consist of 1-2 playthroughs. This is especially true if the player is defeated early in a run, as the desire to do better pushes the player to try again.

[interactivedesignlife-blog]

Old Work Post

I figured I should put up a few images of things that I’ve made in the past so that I can compare them to what I’m able to do at the end of this course. Keep in mind that most of this stuff was either based on tutorials or purely experimental and should be consider WIP at best. 

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.

There’s a bunch of other stuff, but none of it ever really appealed to me at the best of times and I’d like most of the content on this Tumblr to be my progress moving forwards while at AIE as opposed to what I've done in the past.