#codeaday

Today’s theme was ‘Just Me and Wilson’. The objective: Make a small island to walk around with little areas where things like animations and sounds will trigger.

I’m incredibly new to code, so I did AN area, if you walk into the tree, a coconut will fall but for the first day that was it for my coding abilities.

Misreading the title of the task as ‘Just me and WINSTON’ lead to the obvious need for a Gorilla to be stuck on the island with you. But having only 24 hours and about all of those dedicated to trying to get my head around writing the script...I was going to let the ‘Winston’ thing go...BUT!

Credit to @mickey-seamark for throwing together this animation of ‘The Elusive Beach Gorilla’ to really help the island come together.

This week has been super fun for me.  This post may end up being mostly gifs.  Don’t worry though, it should still be entertaining as they will likely all have stories of all of the things that went wrong in their creation.  Fun!

This week started with us being told the we would need to pitch the game we would be making for the rest of the code unit.  As in, we would need to pitch it then and there.  I guess I could have seen that coming if I had thought about it, but I hadn’t, so this meant I had to come up with a game idea pretty much on the spot.  It didn’t have to be super complicated or epic in scale, in fact the opposite was pretty much true, but those were most of the constraints.  The other big one was that it had to be single player.

In coming up with an idea I looked to something I did last week, just as an exercise for myself.  I made a set of modular level pieces that can be snapped together for really quick building of levels.  When we did this initially I got focused too much on the look of the bits and thus only got one and a half done.  This time was different. I went in with the intention of making something as simple as possible, which meant that  I was finished really quickly and had exactly what I wanted.

I threw some of the textures of Wolfenstein 3D on there and voila! A level!

There are 4 pieces used to build this whole thing, and a torch I made quickly in unity to give it more of the dungeon feel the walls suggest.

Click here to see a little of what it looks like from the inside

With this fresh in my mind combined with my enjoyment of puzzle games, I decided to make something along the lines of Hitman Go or Lara Croft Go.  Both of those games are so slick but have ‘reasonably’ simple mechanics, so that’s what I decided to emulate.  Whether those mechanics are actually that simple remains to be seen, but either way I’m sure I’ll learn a lot along the way.

The rest of the mornings this week were spent developing this idea and writing out a game design document for it.  I have semi decided on the name “Escape from Robot Prison” and the basic pitch is as follows:

“Escape from Robot Prison is a puzzle game in which you must hit a switch to activate to activate the exit, then make your way out, all the while not being caught by the patrolling enemies by either avoiding them or adjusting their routes by putting things in their way”

Simple, right?  One thing I haven’t decided on at this stage is if the game will be in real time or if it will be ‘turn based’ like the games I mentioned above, having all movement be assigned to a grid and enemies only moving when you do.  That’s a choice that will be decided by how I want to design the level/s (only need one for the project) but also by my coding prowess.  It’s probably something that isn’t too hard to implement, but again, at this stage I’m way early in my coding knowledge so I’m not sure.

Onto what I’ve made this week!

As I may or may not have said last week, my coding knowledge, while small, is not zero.  I have dabbled here and there over my life so there are concepts that I came into this knowing about.  The flip side of that is that I have very little practical knowledge.  While I may be able to look at a piece of simple code and take a guess at what it all does, if I try to sit down and make something myself I am lacking in the vocabulary of what needs to be written to make things happen.

For example, last week’s pseudocode makes sense to me.  If the player presses a button, make something on the screen start to move forward.  Simple concept, yes, but there are things in there that knowing the logic alone won’t make happen.  The computer needs to be checking for input, it then needs to start something moving by giving it momentum.  How does that happen?  

The first few exercises had us printing numbers to the console, then checking for inputs that would adjust those numbers.  Player health would increase when one of three buttons was pressed.  This quickly became an object’s position in space that would be shifted.  We then learned about making things appear and disappear by way of instantiating and destroying.  Combine this with randomizing values and you’ve got something that’s starting to look alright!

What’s this good for?  I’m glad you asked!

We then moved onto triggers

Not the most useful things on their own, but it’s all in the interest of building the tools to make something bigger!

That was it for stuff at school.  Outside of that I have started doing #codeADay, or #codeEveryDay, or whatever the hashtag might be.

The way it works is everyday a concept for a simple piece of code is given, and it’s your job to do your best to make that code a reality.  Example day one was simple make a robot move around a space by using WASD.  They have gotten more complicated as the days have gone on.

Day 2:

Move a bucket left and right at the bottom of the screen. Spheres spawn at random positions at the top of the screen and fall. If you catch a sphere in your bucket, it disappears and you get 10 points.

This was straightforward enough, though I had a little trouble getting the points to tick up until I was reminded of one small step I had skipped (without realizing it).

Day 3:  

Part 1 - In a room, spawn a new sphere every second that has a random size, direction and speed. When 2 spheres collide, destroy the smaller one and increase the volume of the larger one by the volume of the smaller one.

.

Part 2 - Each sphere also has a random colour. When a sphere is absorbed, the new, larger sphere changes colour to be a weighted average of the 2 colours of the colliding spheres, proportional to their original relative sizes. A particle system with the new colour is also spawned at the point of contact.

<GIF TOO BIG FOR TUBLR. CLICK HERE INSTEAD>

This one took me a while, as there were a few new concepts involved that I had to learn how to deal with, such as how to set rotation.

The part I found the hardest was making the colours merge while being weighted depending on their relative sizes.  This was mostly because the solution to this wasn’t code so much as it was finding the correct equation that would take the appropriate values and give the answer I wanted.

I got there eventually and it was SO satisfying.  I understand how programmers may end up with god complexes now.  Making a thing from nothing and having it work is pretty great.

I’ve also just realized I forgot this bit

“A particle system with the new colour is also spawned at the point of contact.”

...oops.

MOVING ON

Day 4:

Part 1 - Make a little robot sitting on a big sphere. Use W,A,S,D to rotate the sphere under the robot as if it is driving around on a little planet. Put some other objects on the sphere so you can actually see it rotate.

.

Part 2 - Make a 'teleporter' that you can move into somewhere on the planet that takes you to the surface of another planet that you can see in the sky.

Here is what I ended up with:

THIS DIDN’T LOAD SO HERE IS A LINK!

I didn’t quite get to part two of the challenge.  The two reasons were 1) as soon as I got part one working, I decided to go into maya and make some planets of my own, with their own topology that wasn’t perfectly spherical. This lead to a whole bunch of issues to do with collision meshes and the ‘car’ dropping through the ground VERY easily.  2) I started these challenges a day late, so I did this one the same day as the previous absorbed ball challenge, so was feeling brain fatigue.  I was happy that I got as far as I did as I still ran into trouble while getting this to work.

In the right spot the other planet even made a shadow on the surface of the first one

<THIS ALSO DIDN’T LOAD SO CLICK HERE TO SEE IT!>

Day 5:

Part 1 - Drive a little robot around with W,A,S,D, that shoots a small sphere projectile out in front of it when you hit space. The projectile is affected by gravity and is destroyed when it hits something.

.

Part 2 - You can rotate the direction you are aiming (indicated by some 'gun' object) independently of the direction you are facing, by moving the mouse left and right. Also, the spheres you shoot out bounce once before being destroyed on their second collision, at which time a particle system is spawned at the point of impact and an explosion sound is played.

This is today’s one.  While attempting it, I got stuck and decided to take a break and write this instead, so here is the WIP that is my shooty robot.

This one had a few struggles that I kept jumping between when I hit a wall on any of them, so there are lots of half finished ideas in the gif above.

The bullets were working at one point, but I haven’t gotten them to launch from the end of the ‘canon’ yet (the white thing sticking out of the robot).

I feel I should point out that the flaily arms were my addition and that the factor that determines how fast the robot moves is “amount of panic”

Also this happened when I first got the moving script written, but only attached it to a small part of our little friend.

And that’s about it for this week.  I’ve been LOVING learning to code.  This is the area that I have been wanting to learn about for a long time, to the point that I was considering applying to the coding course at AIE instead of the design one.  I think I make the right choice by way of design, as I want to learn about as many different disciplines as I can, but still, this is my favorite one so far

Thanks for reading!

See you next week,

This one was defiantly the most fun so far! The ball is given force based off how long the mouse is held down and I also added a bouncy physics layer to the ball to give it more realism (this also stops it from getting stuck in annoying places). The scoring system was simply added with an invisible collider in the ring and the reset is the same thing on the floor.

The Code

The whole game is made of 3 scripts, the longest of which is the score script so the game was incredible easy to put together. This is a copy of the force script (for those who want to know). My only issue with the whole game was that I was using ‘Input.GetButtownDown’ for the longest time and was wondering why my power was always capped.

The Hoop

The basketball hoop was something I couldn’t find a model of on the asset store so I had to chuck together one really quickly in Maya. The issue I had was the more realistic I made it the more annoying the collider in Unity became so I scrapped the net and made the ring a little easier.