ar-alternativecontrollers

[ar-alternativecontrollers]

Outcome

I think this project went well, I achieved what I had set out to do and I'm proud of what I have made.

Throughout this project, I had looked into different designs for the hand and bugs; trying to see what would look the best when presented. I am also happy that I was consistent the designs in this project, as they all work well together.

Here's the final gameplay video for this project:

[ar-alternativecontrollers]

Game Anglia

Presenting my game at Game Anglia was quite nerve-racking, although chatting and getting positive feedback from the players certainly took a load off. While I was watching the players, I was surprised and glad that they knew how to play without any interjection from me.

I'm also glad the correct build was uploaded as there was a bit of trouble trying to get my game built. This was because I couldn't build it to the right file type and also I was having a hard time trying to ZIP the files with the assets and project.

Everything I needed was provided (mouse, keyboard, monitor, computer). There weren't any headphones, but the audio in my game was optional so that didn't affect anything.

From what I saw and from the feedback given, there wasn't any refinements needed that I didn't know of.

I also played some of other people's games. All the games I played were very well made, which only added to my pre-presentation nervousness. I got to speak all the developers of the games I played, and some from the ones I didn't. From these discussions, I learnt just how money and time consuming making games are. Overall I enjoyed the experience as I got to meet a bunch of different developers and got to play many games that hadn't been released yet.

One of the chats I had with one of the players, was about the low resolution I had purposely added to my game. I said about how I did this because a few games I had played had a similar effect. When I had mentioned that a big part of this choice was that it made it harder to see flaws in my models, I was criticized about how I "shouldn't talk about the negatives of my work..." and to "...focus on the positives". An example of the positives was how the low resolution "...made my game stand out against some of the others displayed".

[ar-alternativecontrollers]

Dev Day 8

Okay today is the final day, I will just be tweaking the gameplay and trying to build my game.

So first I changed the bug's timer to be a little less forgiving, by changing the base time they are on screen from 7 to 5 seconds. Then I added a nice outline on all the text so it stands out from the background more:

And I also removed the timers for bugs, which does look a little more cleaner:

I added a new bug (that is just a reskin of the flying bug), the lightning bug:

This bug has a 1/12 chance to spawn instead of the flying bug and has over double the speed of the flying bug, and will leave after 2 seconds. It also doesn't count towards the bugs that left the screen, as I feel that is a bit unfair.

[ar-alternativecontrollers]

More launch errors...

As to be expected, I got my monthly launch error. This one wasn't as easy to be rid of however as opening and closing the Package Manager hasn't fixed it.

So I tried restarting the computer, nothing. I tried opening another project and deleting some of their packages, won't open. Can't do anything with the antivirus because I am not an admin.

So I tried following a tutorial online on how to fix this, in which they say to open the Package Manager. So I followed, until I realized the path to the Package Manager was gone...

To note, these problems ONLY happen with the college computers. I still suspect that it's the sheer amount of packages downloaded, as the only times these errors occur, it mentions the package manager (using my last project as an example):

So I tried restarting the computer again (the first restart deleted the package manager, maybe the second will bring it back?) - still nothing.

Reading more into this on the Unity forums, and my theory might be correct.

I will also try Pedro's advice and clone my file so that it may reinstall the package manager.

I cannot open any project without the package manager.

So as there wasn't too much more I could do, I logged on to another computer, and look what I found:

I tried to open my project again and...

It works.

[ar-alternativecontrollers]

Devlog 7

Plans for the week:

I don't have many days left working on this project, so I need to get a few things finished before the end of today. Although there isn't too much too be done, just some visual effects and gameplay tweaking (like adding a score multiplier and making the game more challenging).

So I thought it would easier to start with the score multiplier as that is more straight forwards than making the game harder. So I made a system to have text float up above the score:

I used a string here so that I can enter what text I want to be displayed when I'm triggering it rather than in the function (plus it makes the code look neater).

So now it looks like this:

Just before this this I removed all things relating to the stamina system, as I don't think I'll get around to fixing it plus it's way too bothersome as a restriction. I think to compensate this, I will increase the attack cooldown and perhaps make it so that the hand goes red when in cooldown.

After stopping for lunch, I came back to my project not opening... (see post above).

I had lost a lot of time to this, although luckily I didn't have too much more to do.

For the rest of today, I added things to increase score (EG. killing bugs, having no bugs leave the screen in a round, not attacking for 5 seconds and killing a rare and super quick bug).

[ar-alternativecontrollers]

Have I achieved my goals this week?

To put it short, yes.

This week I got a bunch of the art done, to a point where it looks presentable, I made the game feel a whole lot more finished, I got learned some things about methods and have finished most of the code.

[ar-alternativecontrollers]

Sprite swapping problem

The sprite should be changing after each attack, and should be changing when I'm setting it during run time, not just when when paused.

[ar-alternativecontrollers]

Devlog 6

Today I want to finish things from yesterday and to get the stamina mechanic to work. If finish these, I will make the game over screen and add an extra bug type:

So to show my new corpses was just a case of swapping the blood out for the corpse sprites and destroying the bug shortly after.

Here's what that looks like:

So for the next thing I need to add, or more so fix, is the hands swapping sprites according to the stamina.

However, spriteRenderer.sprite isn't working and I can't even change the sprite within the inspector during runtime. This is the code I have so far:

This here uses the new method types I discovered yesterday. All this does is it calls the ChangeSprite() method and gives it the stamina float to use as the float s where the method will check what number stamina is at then return the appropriate sprite to be set. I have tested each IF statement; and they all work as intended, so the problem shouldn't be within this piece of code. It is also important to note that only one of the IF statements can run at a time, due to the return statements exiting out of the method.

I've changed the script so that the hand1 sprite is constantly being set, still nothing's changed. I've checked the other two scripts: the GameManager script doesn't reference the hand, its script or any sprite renderer and the bug script only references the hand through a tag comparison (not its script) and the sprite renderer it references is its own (the variable's names don't match).

I've checked the animations for the hand: the attack animation only swaps the sprite once before changing back to the default, and the idle animation only affects the rotation of the hand.

So I recorded a video to show exactly what the problem is, and I learnt something from it...

I can change the sprite during run time, just when it's paused.

I've posted the video showing the problem after this post as Tumblr only lets you have 1 video per post.

So what I have taken away is that something is constantly setting the sprite every frame, now I just need to locate it.

So there is only one thing setting the sprite in the hand script, the method that should be setting it - nothing else is setting the sprite.

As I couldn't figure this out, I decided to finally make the Game Over screen:

I made the hand give the player a thumbs down for losing, though there isn't really a way to beat the game.

[ar-alternativecontrollers]

Devlog 5

Today is mostly about getting the visuals done, so that's what I'm going to do:

I started work on making blood for the insects as I found that them dying wasn't all that clear or good looking. Like usually I grabbed a png from google:

Threw it into photo shop, removed the background and changed it's colour:

Forgot to make it pixelated and exported in Unity to be met with this monstrosity:

Turns out when exporting to unity, if the whole thing isn't combined by a colour it'll count them as separate sprites. With a rough estimate, there are about 400 sprites that came from this one image.

To fix this I just used the eraser to remove all the detached bits to reduce this from ±400 sprites to 2. This is what it will look like in game when I get the code ready:

As for the code, it was fairly simple to make, I just instantiated the blood under the bug when it died.

Something I've just learnt is what the return statement does, in the example below; IsEven is a method and a bool that becomes true when the number becomes 0 when using modulo division (no remainder). The return statement is used here to set the bool to either true or false and to exit the method.

After a bit of testing how this works, I made a small clock as an example:

The return value changes the value of the method NOT what comes afterwards. Also it is important to note that all methods that are not of 'void' type must contain a return statement to run.

Another plan I had for this is to make it so when being crushed, the bug has a 20% not to be fully crushed and be on its back like it is now, where the player can crush it again to fully kill it. This adds nothing gameplay-wise, but would make the game feel more developed.

For this, I need to make more sprites for when the bugs are fully killed:

I do this by just using the lasso tool in photoshop to remove segments of the bug and lay them in the blood from earlier.

I will make two versions of this for diversity and now:

And now I've made the ones for the flying bugs:

I'll swap out the regular blood and corpses with these... tomorrow!

[ar-alternativecontrollers]

Devlog 4

The goals for today are few as I really want to focus on the art:

The first thing I did today was to make a sprite for the ground, as I have grown tired of the gray solid colours. I grabbed two pngs from google, cropped them, made them darker and combined them in photoshop. Then I did the same process I used to make the hand pixelated and gave the combined sprite a mosaic filter. It turned out like this:

Which added to the game looks like this:

Now for the background, I know this is going to be a little harder. I first tried out something like this:

Then I tried this out this garden, which I think works really well:

Here's what it looks like in-game:

Although now seeing it in game, it is a bit distracting with all the benches and flowers in the background. Plus as a person with colour blindness, it can get a bit confusing to see what's happening (and I'm the one who made the game!).

My next background idea is based more on having less on the screen:

I think I might be onto something here... I took the sprite back into photoshop as I forgot to pixelate the bottom part.

Because the score would be a nightmare to display how I had it before with this background, I made an alternative:

So now that the art is done for the most part, I need to add those hands with the bones into the game. Although because I made the open and closed variants of the hands before the bone variants, they are all a different size...

This was a simple fix though, as I just had to reimport the open and closed hand and scale it to be the same size in photoshop.

[ar-alternativecontrollers]

Devlog 3

Something I have realized is that I have been trying to add more and more to my project when the whole point of making something so simple was to polish it up and make it feel really good to play. So here are the tasks for today based on this:

I added some sound effects for the hand smashing and the bugs being killed.

Here's what they sound like along with some gameplay:

Next I wanted to make some sprites to replace my pngs with, so I made these:

Although in I don't think these work as well as the pngs, although I may use these in the future. The reason why a few of them have skeletal fingers, is that I wanted to make the exhaustion system use these different sprites to show how many times the player can attack before a cooldown. Although I might try this but with the pngs.

Right, so I have just added human finger bones to the png hand and altogether they look like this:

[ar-alternativecontrollers]

Devlog 2

Today I'm planning on refining my game a little bit before adding anything too big to it. Here's the plans for today:

I have plans for the score counter, where I want to have multipliers appear around it when the player does a certain thing within the game (such as getting a double kill).

Next I started work on making a new bug type. This guy:

As you can tell, he is going to be flying... that's really it at the moment. Implementing this guy was a whole lot easier than I expected (hence why I was putting it off) as all it took was duplicating the bug prefab, changing the sprite, adding some IF statements to make sure he is lerping in the air and making an animation for him to fall.

[ar-alternativecontrollers]

Devlog 1

I'm using a new website called Milanote, I am going to be tracking and planning what I will be doing for this project.

So today I mainly want to get the bugs running off-screen mechanic to work, anything else is a bonus.

So I start off with giving the bugs a timer variable and a timer above their heads:

Now for the hard part, getting them to leave...

This wasn't too difficult to make, although the animation gave me a few headaches. Something I'd like to add is that these annotations are helping a lot more than I thought they would, I'm mostly using them to segregate my code into different pieces, though having a quick explanation of what these pieces should be doing helps as well.

While I was doing the animation for this, I decided to give the bugs an idle animation just like the hand; where it rotates slightly back and fourth. It's very subtle, but it makes the whole thing look less bland (also it looks like the corpses are writhing when they play the animation, which gives me an idea). I also changed the hand a fair bit so that it is open when it is idle and closed when attacking, again this doesn't change all that much but just makes it look a little more lively (I also made both models pixelated and blue in photoshop so that if I need additional models for the hands, I won't have to worry about the skin colour or quality of the hand - also it gives it more personality).

[ar-alternativecontrollers]

Idea Generation - Prototyping

Following my idea generation, I made a quick prototype for Bug Basher (formerly known as idea 3).

Here's what the prototype for Bug Basher looks like:

I did this to test how compatible my one button controller idea would be for a game like this, and sure enough it worked like a charm.

As said in my last blog, the hand and bugs lerp from either side of the screen. The hand smashes down when spacebar is pressed and the bugs die when bashed. You get score for each bug killed. This took me approximately 2 hours to do and really helped visualize what I could turn this into. The first thing that comes to mind is sort of a roguelike game where with each wave, new bugs that do different things (like constantly swap directions or switch speeds) that can be mixed together. The objective would still be to gain as much score as possible.

As for the art, I'm thinking either pixelized, low resolution sprites that could give the game a gritty feel or hastily drawn doodles. Both of these would be quick to make / implement and would make the my game stand out.

Something I would need to add is perhaps a stamina bar, because at the moment the player can just spam the spacebar and beat the bugs without much effort or lining it up.

Another idea would be making a new lane for flying bugs to move in:

Or even having multiple hands:

Here's the code:

[ar-alternativecontrollers]

Fiero

Fiero is an emotion of triumph and satisfaction. Think of beating a difficult boss or overcoming a hard challenge, you will most likely get that feeling where you raise your arms and shout in excitement - that's fiero taking place.

[ar-alternativecontrollers]

Idea Generation

Idea One:

For my first idea, I'm thinking of making a game where you have to launch the player from planet to planet. The game will have a bar showing what direction the player will get launched in that lerps from 1 point to another. Control-wise, the player will only have one button to hit to launch themselves when the bar lines up with the planet. Here's a little visualization:

An alternative idea is that the player will be circling the planet and has to launch when they are between the two:

I could always do a combination of both however. The game would obviously take place in space; this leaves my room to use gravity as a unique mechanic where the player may be drawn into blackholes or stars that kill the player. This idea is inspired by Angry Birds Space, as gravity is used in a similar way.

This game would be endless, with planets spawning above the player after they've landed on a new one, and the player would receive score for each planet landed on. The game ends when the player misses their launch or is sucked into a star/blackhole.

To add extra difficulty, the player might travel faster around the planets as their score increases - or they might only have a certain amount of time before the planet they are on blows up.

I like this idea as it is a very simple concept that has a lot of room for expansion. This would also be very accessible as sound wouldn't be a fundamental aspect and the player only has to hit one button. Because of the fact the controller is a single button, I will start with the prototype first and make the controller after.

I think the controller would fit this type of game as both controller and game are made to be as simple as possible.

Idea Two:

For my second idea, the player has to balance a ball on a seesaw that is controlled with the player's phone's gyroscope. Tilting the screen left to right puts weight on that side of the seesaw, making the ball roll down.

I like this idea as the controls are simple and can be used by most and it is more creative than just having buttons on either side of the screen.

By itself, this would be way too easy; so the player would have to dodge incoming shapes falling from the top of the screen. The player would have 3 lives and being hit would lose them a life.

Like my previous idea, the game would be endless; only finishing when the player has lost all 3 lives. The player would gain score periodically and when they dodge a shape.

This idea again, isn't that complicated (although learning about how to read the phone's gyroscope might be tricky) but gives me some good room to add new features. Unlike my previous idea, I will be designing the controller / gyroscope controls before anything else. This shouldn't be too difficult as I have dabbled in mobile game development before.

I came up with this idea by playing around with Unity's physics system in 2d, then wondered how it would be if I had to constantly control the ball on a seesaw or something else where weight is applied to one side.

The whole seesaw/weight mechanic would work well using the gyroscope as it would be like the player was actually using the seesaw in real time.

This Video here shows how the gyroscope is used in mobile games such as pubg:

This video is a little more related to my game, as it is about a ball and using the gyroscope to control it:

Idea Three:

I really want to make this project use at most 1 button, so for my next idea; the player controls a floating hand that they have to use to crush bugs. The hand would lerp from side to side and smash down when the player hits a button.

The bugs will walk onto the screen from the sides and hang around a bit before walking off. The game will be made of rounds where each round the player has to bash a minimum number of bugs to progress to the next round otherwise they lose.

The player will receive score based on bugs bashed and rounds progressed. There could be different bugs based on the round that could impose different challenges (like moving really quickly or taking multiple hits to kill).

Compared to both my other ideas, this one is a lot simpler as I want to make the core game play and have time to add more to it (which for almost ALL my other projects (other than my beloved Ten) didn't happen).

The controller I'm imagining could be a big red button the player has to smack as if they were smacking the bugs themselves, plus it would be accessible like the first idea. And again, since the controls would just need changing to the button, I would definitely start with the game player instead of the controller first.

Inspiration-wise, I wanted to make a simpler version of this game I had seen before, however I just can't remember what the game is called. It looks a like a mixture of this:

I am kind of using the base gameplay from this game where instead of the pick spinning around a lock, it just a hand at the top of the screen:

[ar-alternativecontrollers]

Research - Rumble