Hello all, I just wanted to post an update to my post here about my current game project, as I do now have a build ready to share! Obviously, this is a super early build, but it will hopefully provide some meaning to the code I posted last week. But once again please keep in mind this project has only been in motion for a week, we have only used free or self made art assets, and exemplified here is only a proof of mechanics and basic architecture for those mechanics.
A good designer really shouldn’t provide tips to players before a play test, but since I’m not there to observe people play, I want to make a few notes about how this game is meant to be played, as it’s likely different from most games you have been exposed to!
You will play as a sushi chef, and be able to engage in the interactions that will eventually make up the foundation of the mechanics of this game! So be prepared to treat your keyboard as your work station as you go into this experience.
With your right hand, navigate using arrow keys.
With your left hand, drag fingers along letter keys to engage “active interactions”.
Please don’t rush, treat your sushi gently.
Please report any bugs you find to me! aidantakami@gmail.com.
This is a VERY early build, there are bound to be lots of bugs and problems, but by play testing early, these bugs can be weeded out early, and save me the trouble later.
…. and with that… here’s a link to the Google Drive where you will find both PC and Mac Builds.
For my tech crowd, please take note that Input Manager at work there can be found in my last post, linked at the top of post. Additionally that post contains a link to my Engineering Manifest for the project, which contains summaries of all classes written for the project, as well ad general architecture overviews where necessary.
… and of course I would never leave you all without a script update. Today I’ll share with you guys a script which saved my life. After playing the build above, I’m sure you noticed the keys which animate alongside the player while they are close to an “active interaction”. Generally, one would either instantiate the specific key sprites when needed(both pressed and unpressed) or have each sprite referenced in code and pool them somewhere in the scene to use when needed, and be out of the view of player when not.
My KeySpriteManager sort of does both… but is useful for me as it can can take KeyCodes as args and return the corresponding “key sprite”. That’s right, public SpriteRenderer GetLetterSprite(KeyCode keyCode, bool keyPressed). Basically, my KeySpriteManager contains a List of SpriteRenderers of all the “key sprites” (which if you don’t get by now are the keys of a keyboard, individually cut out and used to emphasize the pressing of keys). Each letter contains both a pressed and unpressed sprite, so I allow access to the pressed sprites as well with the bool keyPressed.
Oh wow you made a list that takes KeyCodes and returns pictures who cares. I know. But this is incredibly useful for my game as InputGroupings (the class I shared in my last post (linked at top of post)) contain only keyCodes, and I can simply access these KeyCodes from any script and get the appropriate, matching key sprite from my KeySpriteManager. In addition to storing sprites, public SpriteRenderer FlipSprite(SpriteRenderer sr) will take a KeySprite, find it in the List, and based upon the spot it finds it in the List, return either the pressed or unpressed version of that key sprite, opposite of whatever was given to the function.
The code is quite repetitive, but I thought it would be good to share because of how greatly it works in conjunction with my InputGroupings class…. which I shared…. last week… link up top….. sorry. I’ll spare you guys the repetition of this code and trip it down, but you will certainly get the idea… Thanks for reading, here’s some code and a picture from the build I posted above!
using System.Collections.Generic;
using UnityEngine;
public class KeySpriteManager : MonoBehaviour
{
//keySprites must have letter sprites entered in alphabetical order to function
[SerializeField]
public List<SpriteRenderer> keySprites = new List<SpriteRenderer>();
//Will return corresponding SR for the KeyCode given
//List is in aplhabetical order, A to Z, then 1 - 10
//Array must have list[x] = un pressed key, list[x+1] = pressed key
public SpriteRenderer GetLetterSprite(KeyCode keyCode, bool keyPressed)
{
//This will be repetitive
//Return Corresponding KeyCode
if (keyCode == KeyCode.A)
{
//Returns unpressed key Sprite
if (!keyPressed)
{
return keySprites[0];
}
//Returns pressed Key Sprite, sets ket to pressed
return keySprites[1];
}
//Return Corresponding KeyCode
else if (keyCode == KeyCode.B)
{
//Returns unpressed key Sprite
if (!keyPressed)
{
return keySprites[2];
}
//Returns pressed Key Sprite, sets ket to pressed
return keySprites[3];
}
/*
*
*
* I told you I would spare you the repetition...
*
*
*/
//Catch
else return keySprites[0];
}
//Will returned the flipped sprite from the one provided
public SpriteRenderer FlipSprite(SpriteRenderer sr)
{
//Finds sprite in List
for(int rep = 0; rep < keySprites.Count; rep++)
{
//finds equivalent sprite
if (keySprites[rep].sprite.Equals(sr.sprite))
{
if(rep % 2 == 0)
{
return keySprites[rep + 1];
}
else
{
return keySprites[rep - 1];
}
}
}
Debug.Log("Couldn't find sprite to flip.. probably the .Equals()");
return keySprites[0];
}
}

2 thoughts on “Imponderabilia V 0.3”