RSS

Monthly Archives: July 2016

Scripting Time! Transmutation: Lighting

The game is set inside of a nuclear power plant, and nuclear power plants need siren lights in case of emergency right?

Siren Light.jpg

Like This One

My goal was to create something functionally identical to one of these siren lights. Surprisingly it was extremely easy. It took two lines of code.

Siren Light Code.JPG

Set a rotational speed, and make it rotate in the direction by (time x speed).

Light Gif.gif


Fiddling with such a simple light had my lighting senses tingling. I though what else needs some lighting? The elevator perhaps?

14012953_10206991253404328_1765396985_o.jpg

Inspiration piece. Yes I took a photo of an elevator.

Elevator Lights.JPG

Excellent! But perhaps they would be better off only activating when the elevator arrives? The elevator would need to know to activate it’s lights when it arrives. Because the elevator is already counting to when it arrives I could simply insert another method that would activate the lights.

Elevator Inside Lights.JPG

Elevator Lights Gif.gif


I felt like the elevator could be improved on just a little bit more. If the game is supposed to be 4 minutes long and the goal of the game is to escape via the elevator, there should be an indication of how close the elevator is to the 5th underground floor.

6 lights. From left to right (-5, -4, -3, -2, -1, Ground). Next was to change these lights to show the elevator moving.

The elevator would need:

  • An array of all of the lights. = GameObject[] lights;
  • Which is the current light. = int current Light;
  • Which light to change to.
  • The time since the game has started. = float lightTimer =  Time.time (in start).
  • How often the lights should change. = float lightRefreshTimer;

How often the lights should change is determined by the length of the game. If there are six lights, and the game is 4 minutes long, the light should change every lightRefreshTimer amount of seconds.

lightRefreshTimer = (elevatorTime / (amount of lights in the lights array – 1)). Because there are six lights, but the first one is already active, the elevator only has to move down 5 levels, not six.

So if the (Time.time – lightTimer >= lightRefreshTimer)) Change the lights() and refresh the time duration.

This slideshow requires JavaScript.

The SwitchLights() method sets the current light off, Changes the value to the next light, and turns that one on. Each time that method is called it changes the current light to the next one. But what happens if all of the lights have been changed and the timer is still going? I’d need a way for the last light to be the last light. Above the if statement to that checks if the Time.time – lightTimer >= lightRefreshTimer is another if statement. It checks if the current light isn’t greater than or equal to the amount of lights in the light array. If it isn’t it executes the code underneath, otherwise it doesn’t.

Something that tripped me up was not having the levelLights.length – 1.

Index out of array

The currentLight variable starts at 0 and only ever reaches 5. So when it comes around again to the levelLights.length (which is 6) it would try to activate something that wasn’t there. Hence having the -1 to the levelLights.length to make that also = 5.

Elevator Level Lights.gif

Until next time –

FeenikxFire

Nic

 
Leave a comment

Posted by on July 31, 2016 in C#, Game Dev

 

Tags: , , ,

Scripting Time! Transmutation: Elevator

Elevator.JPG

Transmutation takes place 5 levels underground in a nuclear plant canteen. Three overnight staff are having their lunch break when something goes wrong. They need to leave the plant and the only way out – is up.

The way to win transmutation is to survive for a total of 4 minutes and enter the elevator to escape. When the game has been running for a 4 minutes the elevator doors will open allowing the remaining playable characters to enter and activate a game over screen.

What the elevator will require:

  • A 4 minute timer.
  • A current timer.
  • A way to tell the doors they can open.
  • A way to trigger the game over screen.

What the elevator doors will require:

  • A way to know they can open.
  • Positions to open to.

The current timer can increase with game time: In Update()   timer += Time.DeltaTime. Then if the timer is greater than the set time for the game duration, tell the doors they can open.

Each of the elevator doors have their own script. The sole purpose of that script is to know when to open, and move itself to the open position. When the elevator has arrived to 5th floor it will change its hasArrived bool to true. Each of the elevator doors are waiting for the elevator to arrive and when it does move to the open position.

Elevator Doors.JPG

Each elevator door has its own openPosition Vector3 variable. They’re in world position co-ordinates because I had great difficulty working with transform.localPosition (as they are a child of the elevator).

Elevator Doors.gif


Now that the elevator doors open it was time for a way to trigger a game over menu. The elevator would need access to the UIController to activate the game over menu and a way to activate the game over menu. For now, a simple OnTriggerEnter with a playable character would suffice.

Until next time –

FeenikxFire

Nic

 
1 Comment

Posted by on July 31, 2016 in C#, Game Dev

 

Tags: , , , ,

Transmutation Simple Background Music

Transmutation felt so empty without any audio feedback. So I decided to put my Mulab skills to the test and create a simple background music loop.

I used the exact same process as I did when learning the tools of Mulab. I found a sound that I thought would be fitting for the 5 levels underground nuclear facility canteen setting. Created a sequence that would get me started, changed the beats per bar to 1/12th and started dabbling with different notes to see what type of pitch sound made the most sense. Dabbled with some different note compositions until I eventually finished with a simple background loop.

This slideshow requires JavaScript.

I decided on the Wavework sound because it wasn’t just a single note, it had different variations within the note itself that looped for the length that the note was played. It also just seemed so fitting for a game set in a canteen 5 levels underground in a nuclear facility.

Transmutation Fadeout.JPG

 

After the sequence had ended it felt like the loop started to soon. It needed a fade out period to calm down before looping again. At the end of the sequence I created a new empty sequence just for the sake of letting the background loop sequence fade away.

 

 

 

This slideshow requires JavaScript.

It’s not the worlds best track, and that’s fine, but something is better than nothing until we can start to polish up the game.

 

Until next time –

FeenikxFire

Nic

 
1 Comment

Posted by on July 30, 2016 in Audio, Game Dev

 

Tags:

Scripting Time! Transmutation: Character Switching

Character Switching 0

The latest game prototype ‘Transmutation’ requires the player to be able to control 3 playable characters – but not simultaneously. As it is, the player starts playing the character on the right, we’ll call him Mr. Broom. The other two playable characters Pots and Meat are currently sitting idle. There needs to be a way to switch playable characters – this blog will cover how I made it happen.

An appropriate place to handle the switching would be the GameController. It will end up having multiple scripts, one of which I will set up to only handle the character switching. This script is called ‘CharacterSwitcher’. In order for the character switcher to be able to switch characters it’s going to need to know:

  • What three playable characters we have in the game.
  • What camera or how many camera’s we are using.
  • The position of the camera’s or the positions of where an individual camera will move to.

There are only ever going to be three playable characters, but how many camera’s are we going to use and why? Three cameras and always have them be in the positions they need to be and just activate or deactivate them when needed? Or have a single camera and move it to desired locations?

I chose for the game to only operate on a single camera and move to the position it needs to. Purely because of wanting to always have a consistent view on the game world. Plus it would enable us to do something like an ‘XCOM’ game. Lerp the camera between the player’s its switching between except our camera is a fixed 3rd person perspective from behind the playable character.

So now that I’ve decided on a single camera I’ll set up the CharacterSwitcher script to know what it needs.

This slideshow requires JavaScript.

Character Switcher Camera Spots.JPG

The camera spots are empty game objects that are a child of each of the playable characters. They each have the exact same local position behind each character. Now that the GameController know’s what it needs and has them – I need to devise a way to switch between them. Speaking of switching, why not use a switch statement? The GameController will need to know which character is currently selected and which one it needs to go to.

This slideshow requires JavaScript.

In Start(), tell the GameController we are controlling character one. Everything is set up, now it just needs a way to actually switch. I made switching right E and switching left Q for the time being until we learn how to set up the game with a controller. I called these methods straight in update even though they didn’t exist. On many occasions I’ve created complex methods that never work because I create the system and never call it. This time though, I’m going to completely avoid that.

Character Switching Update

This slideshow requires JavaScript.

The switch statement checks which character is currently selected – and as of start, it’s playable character #1. When ‘E’ is pressed it switches to playable character #2. The <CharacterController> script is the script attached to the playable character that allows the player to control it (if the name wasn’t obvious enough). Each time a switch happens, it gets the current playable character – deactivates its control script so it can’t run around, moves the cameras position to the next playable characters camera position and changes the switch statement to the current character.

*video of Switching*

It’s not Lerping as of yet, but that’s a task for another day, it currently serves it’s soul purpose of switching.

Until next time –

FeenikxFire

Nic

 
Leave a comment

Posted by on July 29, 2016 in C#, Game Dev, Games

 

Tags:

Adobe Illustrator – 2D Nuclear Reactor

Adobe Illustrator – 2D Nuclear Reactor

The next game prototype that I’ll/we (part of a team) be making is a short overnight melee survival game. The game is based in an nuclear power plant facility canteen 5 levels underground. I wanted to create an image that was relevant to the game for some of the pitch slides that were prepared. I set out to learn some basic skills of Adobe Illustrator that would help me achieve creating a simple 2d nuclear cooling tower.

Here is the result: (The Trefoil and smoke aren’t mine)

Logo

I’ve gone back and created it again for the sake of cementing the skills I’d learnt and to demonstrate the process of how it was created. The result isn’t identical to the original one that I spent much more time on. But uses the exact same process in a more speedy process. I planned to have audio over the top of the video but I can’t seem to find a way around it as of yet. Instead I’ll throw down a quick little process guide to follow the video.

  • Create a new file, choose size, portrait or landscape.
  • Select the pen tool, create desired line, deselect the line created, select pen tool again.
  • Select second starting position, left click (and hold), drag to desired point, release, move to second desired point, left click.

The left click and hold then drag to desired point will create a line from the first anchor point to the released point mouse position, then left clicking will create the finish point for the line. Selecting the mouse tool again will enable you to adjust the curve from the initial release point.

  • Select the current image, Ctrl + C, Ctrl + V to copy and paste.
  • Flip (mirror) the image.
  • Create a new line that joins the top via the pen tool.
  • Add the extra images to make it a nuclear reactor.
  • Position, and use the scale tool to re-scale (hold shift while re-scaling to preserve the ratio).
  • Send them to the back.
  • Save (if you wish).
  • Export (I did as a PNG), then on a transparent background.

Tadaaaa! Adobe Illustrator skill increased to 5.

Until next time –

FeenikxFire

Nic

 
Leave a comment

Posted by on July 26, 2016 in Adobe Illustrator

 

Tags: , , , ,

Sea Of Mutiny Post Mortem

Its time to wrap up Sea Of Mutiny:

What Went Right:

MDA – Mechanics Dynamics Aesthetics

The way that the rules of Sea Of Mutiny created very interesting game play and player experiences.

As the book ‘The Kobold Guide To Board Game Design’ says in its early pages, games/board games don’t need to have overly complicated rules or systems in place to create interesting dynamics. Sea Of Mutiny’s simple rules and how they interact together are what caused the desired dynamic and aesthetics. The dynamic being that the players have to deal with anonymity and causing conflict based on choices of whom to benefit or impair. The major aesthetic was to create conflict between players. Leaving them feeling joyful for causing chaos to any or specific players, saddened when they know hurtful things are coming their way or determined to win or just cause more conflict between players.

Cause: Focusing on not creating overly complicated mechanics but assuring they interact in ways that are always aiming towards a player experience.

Recommendation: Keep the desired player experience in mind when designing systems.

Working With Collaborators

Working with collaborators went swimmingly well.

This was the first time that I had been working on any form of game that required collaborators to reach a result that I alone could not achieve. The two graphic designers that we were paired with catered to our every request. To be fair, our requests weren’t anything that couldn’t be achieved. There was a constant communication between the Sea Of Mutiny team and the Graphic designers. Conversations took place over Facebook messenger almost daily. With updates on what work had been done and the new thoughts and feelings towards the new work. Almost every time the work presented was an accurate depiction of what we wanted the cards to look like, and even the board in its work in progress phase. The only problems that we ever had with the cards or board were minor details – such as image positioning & size, text size, colour and minor layout changes. The end of discussions often resulted in a task list for changes to be made to the cards and board. Those task’s would be completed by the graphic designers and start the loop of – present progress – thoughts – discuss – make decision – iterate – present progress.

Working with the animators had the same conclusion. Set them a ‘desired’ finished product – perform weekly checkups – thoughts – discuss – make decisions – iterate – present progress. Both animators made the deadline well before we stopped working Sea Of Mutiny.

Cause: Constant communication through an online media platform and weekly face to face meetings. Clear Deadlines in the schedule that had been shared with collaborators. Collaborators being willing and wanting to work on Sea Of Mutiny and achieve the desired result. The collaborators skill set were able to meet the needs of the visual aesthetic of Sea Of Mutiny.

Recommendation: Continue to use a communication medium that works for everyone. Even if this means having multiple different communication platforms for individual groups or people. Continue to appreciate the collaborators work and let them know that what they do is valuable. Set multiple specific times each week to reach out to everyone working on the project for progress updates. Continue to not be afraid to voice concerns or ideas. Everyone has an opinion, and not that any opinion is more valid that others but people may take a stance or form an opinion for a reason. Listen to every suggestion, reason and look at all the possibilities from every angle.

Team Communication

Team Communication was constant.

Having technology at our fingertips that allowed us to communicate with ease. We wanted to make Sea Of Mutiny the best it could be, which pushed us to wanting to talk on a frequent basis and collaborate as a team. We also always set particular times that worked within everyone’s schedules for us to talk as a group outside of Uni. This wasn’t documented in a professional form, but more of a side note and a metal note. From start to finish – each discussion was to always progress or make changes based on feedback or play testing results. Like in the early stages of creating a board game, brainstorming exactly what the game will be and all of the components that combine to make it what we wanted. Or in the later stages of the project that starts to refine the nitty-gritty of mechanics or visual aesthetics. The results of the conversations were tasks that needed to be implemented into our board game. Whether it be to now go and refresh the collaborators on the new changes, fix up some of the mechanics and implement them and document them, etc. When we weren’t together as a group we would use Discord or Facebook messenger. Discord worked well because it was a completely separate application that had voice chat and typing chat without the added distraction of being a click away from watching a funny cat video like Facebook. Facebook also worked well because it’s such a common platform.

Cause: Technology has allowed each of us to leave messages and communicate on multiple platforms (with GREAT ease) for each other to see. Thank you technology. The motivation behind wanting to come together and communicate so often was through team collaboration of creating a game that we were all particularly interested in and wanted to see the best possible result.

Recommendation: Continue to take advantage of the technology available to us that easily enables us to communicate on a want to / need to / instantaneous basis. Set scheduled times that are a must attend sessions (that works for everyone). Continue to make the teams’ members that we work in feel that their opinions and contributions matter that should boost self-esteem and raise team morale levels.


What Went Wrong:

Wrong Card Printing

For two play test sessions – Having accidentally printed 15 of the yellow cards onto blue cards making a total of 30 yellow cards, 15 red and 0 blue. The cards were still blue, but the actions were yellow.

Cause: So this is a tricky one. But to be REALLY blunt – We didn’t take action. I remember this particular situation, now more so than those particular days because I’ve had many days to reflect upon this. It was a Monday morning and it was the one of the first play testing sessions for the second round of play testing. Before this particular day it had been discussed within the SOM (Sea Of Mutiny) team that a particular team member would be in charge of getting the cards ready for this round. They went to the effort to go out and buy some proper card paper in the colours that we needed for our board game. They printed off all of the actions onto cards and cut them out etc. But on this particular day – whether they realized before we arrived together or afterwards, they spoke up when we were setting up the board. “I think I accidentally printed some of the cards onto the wrong colour”. All three of us heard it – but our brains almost didn’t comprehend it? It was just kind of like an ‘eh’ moment. Even throughout the next few hours of play testing and then the next day after, it didn’t specifically click in our brains ‘THIS IS WRONG’ and this will drastically change the game.

Recommendation: I can’t just blatantly say ‘Just do better’, but what I will suggest is that when a problem occurs – no matter the size, pay it attention and resolve it. Because in this instance, it seemed that the colour of the card was overwriting what our brains were comprehending. Colour over Text. It would have taken about 3 sheets of A4 paper, and a pen to fix this mistake and not lose two sessions worth of play testing.

This was the first board game I’d ever made and it was a lot different that creating a video game. Instead of having a computer tell me there’s something wrong it was completely human operated.

26811-unity+ok+error

Sticking To My Guns

Ultimately this boils down to not trying out many different options.

I’m at university in a safe learning environment where making something that isn’t cool, isn’t a bad thing, because there no major repercussions to it. Because this was a physical board game, if a change needed to be made there wasn’t any major loopholes to jump unlike digital games. In order to make the change, it’s as simple as doing it, not rewriting or re-arranging a system of code. The amount of iterations that could have possibly been made in such a short amount of time could have been taken advantage of, but it wasn’t. There were multiple occasions when suggestions were made to explore the options of original board game we were designing. Many were great suggestions, and many – in my opinion, weren’t so great. Instead of making a 2v1 anonymity based card playing race game we could have explored other areas like Guess Who or Cluedo.

Not that they’re bad games and they definitely have interesting elements, but they weren’t games I was trying to take elements from or replicate. But in a safe risk free environment what’s the worst that could have happened? We implemented some changes that we didn’t originally intend on and they have a good or bad result? Something we could take away from trying something different?

Cause: I was holding on too tightly to an idea and was afraid to let it go or let it change to a degree that was out of my comfort zone.

Recommendation: While in a safe environment don’t be so afraid to take a risk or make a change.

Change Log

Not keeping a change log of when thing’s were changed and why.

So when it comes to remembering when certain changes were made and why, especially when coming to write a blog about it, it was extremely difficult to recall the entire change process that SOM went through. In this particular instance there was no drastic repercussion to knowing when changes were made, but in order to find out, I had to sift through a lot of older versions of our documentation. This was a pain in the

Donkey

Cause: I didn’t think remembering changes would have been important for a board game.

Recommendation: Keep a documented changed log with dates – what was changed – and why.

I can almost guarantee that this will be helpful in the future for something game creating related. Whether its knowing what was changed in a certain part of creating a game that caused something to go wrong and completely break the system. Or eventually when I work on a team bigger than 3 people and on a game that takes longer than 5 weeks to prototype, it would be important to document when the game had undergone certain changes.

 


Prevention Is Better Than Cure

Scheduling

It didn’t end catastrophically in this case but this is for future lessons. Within the SOM team it was a ‘play it by ear’ type of scenario.

Play it by ear RED.png

The game went from:

  • Receive Brief
  • Generate Game Ideas
  • Pitch Idea
  • Iterate Idea
  • Pitch Idea
  • Iterate Idea
  • Start To Make The Thing
  • Play <——|
  • Iterate >—-|

And somewhere in between playing and iterating, give some instructions and deadlines to collaborators on what we want things to look like.

Recommendation: Create a task breakdown list for the team to contribute to that will create a guided plan rather than just a play it by ear scenario.

Communication Platform

Majority of the conversations throughout the creation of SOM was done over Facebook messenger, especially with the graphic design collaborators and their progress updates. This worked in this instance, but sometimes we were all getting distracted because of the ease of access to entertainment material rather than sticking strictly to work related material. Some of the progress updates and the communication surrounding the updates were lost in the flow of non work related discussion.

Recommendation: Find a platform that is accessible and preferable to everyone that isn’t Facebook or doesn’t have impending distractions. A platform that will also be specifically work related talk only.


Now if you’ll excuse me, my rum bottle seems to be empty.

Jack Sparrow Wave

Until next time –

FeenikxFire

Nic

 

 
Leave a comment

Posted by on July 25, 2016 in Uncategorized

 

Sea Of Mutiny – Final Play Testing Session

In a previous Sea Of Mutiny play testing blog I noted some things that went well and some things that didn’t go so well. To quickly recap – for the last time on Sea Of Mutiny:

Went Well: The pretty elements, having the correct cards printed, removing the blue switch card and the rule book & cutout cards.

Didn’t Go Well: The game is still too long, people just want to cause chaos, rule book could be condensed more, card text & board symbols could be improved slightly.


What we changed:

The Rule Book:

Here’s how the rule book was changed.


Card Layout & Brightness:

This slideshow requires JavaScript.

Why?

In the previous play testing session it had been the almost one of the first times they’d been printed and ready to use. On a computer screen designing them they seemed like they were bright enough, but when printed – printed darker than anticipated. They weren’t black like the first time, but still a little bit dark. So everything was made a little bit lighter.

The new inside card layout removed the title of the game – because it wasn’t necessary to have. The icon representing what type of card it is has been moved to the top left and bottom right of the card to help players identify what type of card it is they have when holding and fanning all the cards in their hand. The text can still be altered to make the card story a little smaller than the action. Make the action of the card multiple sizes bigger and make it bold to stand out so if players want to skip the story and go straight to the action – they can.

The outside of the cards have coloured corners – no real reason, it just looks prettier.

The Mutineer cards are a little more simple – Added a pirate pistol too because they’re awesome.

The boards ‘Walk The Plank’ tiles have changed to be black with a yellow skull to make it stand out more and be directly more colour coded to suit the card it relates to.


Board Length – Amount Of Tiles:

Last Board Layout.jpg

Removed the last 7 tiles. Moved back the finish tile, and placed a walk the plank tile just before it. Removed the shortcut and the dangerous loop of walk the plank tiles. Moved the reveal to self tile to be the 10th tile into the game, moved the reveal to all tile to be 19th tile.

Why?

To try drastically reduce the play time. It was the easiest solution to shorten play time without changing anything mechanical that was in place.


Giving Each Player Cards To Start With:

This was only in place for a single play test. When the game starts – and before any player has rolled to move, each player is given 1 card of each colour.

Why?

To see if players would choose to play any cards in their first turn. In this play test. They didn’t. Part of this is because when the game starts, the first roll of each player has a 100% chance of them landing on a chest tile. Part of this was because the reveal to self point was so much closer, they were stock piling cards for after then. Before the first reveal point each player had at least 6 cards in their hand. – Will not be a core mechanic – Removed.


Added An Extra Mutineer Card:

Added an extra Mutineer allegiance card to the cards that are dealt to players on game start. There is now 2 Pirate & 2 Mutineer Allegiance cards.

Why?

To utilise the on the fact that some players just want to cause chaos.


How Did These Changes Impact The Game?

The rule book responses in the questionnaire.

Rule Book Questionnaire Responses

The rule book went really well. It’s still not perfect, but at least players are willing to read them without wanting to gouge their own eyes out. Besides, we learnt some valuable lessons about how to present information to players in a more meaningful, precise, fast way.

Having all of the printed assets brighter was great because it made everything easier to interpret. The new layout for the inside of the cards relieved them of being too cluttered but still provided the critical information. Having the icon in the left top hand corner and the brighter boarders made it easier to interpret what cards were in the player’s hand when fanning the cards. But that only benefits players who fan their cards from right to left and not left to right.

The graphic designers and I toyed with the inside of the card layout and tried to test what it would look like having icons in both corners.

Red Inside Big Bottom Little Tops.png

We stuck with one in each corner but know there’s an alternative way that benefits players no matter how they hold their cards.

The new board layout also worked really well. It shortened the games play time by a decent amount and was just over the 20-30 minute first play time window. Removing the shortcut full of walk the plank tiles also drastically reduced the games play time. It removed loop of  entering and exiting and back and forth of the shortcut. The reveal points aren’t too far away or too close.

The extra mutineer card allowed a 50/50 chance for the game to have a team of pirates or a pure free for all between mutineers and pirates. When the game was 2 mutineers and a single pirate – everyone tried to cause as much chaos as possible while only solely trying to benefit themselves. The games that had a team of pirate and a single mutineer were the same as the previous sessions – except this time around the pirates actually worked as a team and didn’t try to break the game. Ultimately, having an extra mutineer card can change the re-playability of Sea Of Mutiny by never guaranteeing a particular set of teams. Each game will have a different dynamic.


What Went Right:

Every change in this play test worked out for the better.

What Went Wrong:

Nothing went wrong this play test. But improvements could still be made – Sea Of Mutiny Isn’t perfect.


Suggested Fixes:

Work on the text size of the inside of the cards to better separate the card story from the card action. Possibly find a way to make the inside card design benefit every fan of cards.

Update the board layout with the new changes of amount of tiles and changed zones.

Iterate over the rule book to make it pretty and more polished.

Start trying to plan the box art for Sea Of Mutiny.

Find a way to get the 3D models from the animators printed and ready for use in Sea Of Mutiny.


Until next time –

FeenikxFire

Nic

 
Leave a comment

Posted by on July 18, 2016 in Uncategorized