Ludum Dare #32

Over the weekend I participated in the Ludum Dare competition. This was the first time I have entered LD. The end result was a bit… Iffy, but I learnt a lot along the way.

The theme was “an unconventional weapon”. I took some time and wrote down ideas such as “cheese”, “socks” and even “mice” to scare off elephants. In the end I settled on a snake that is used as a whip. Unfortunately that never actually became the weapon.

I opened up Unity, started up mono develop and then started questioning myself. How much would I learn if I made yet another game in Unity? Before I knew it, I had closed unity and opened visual studio. This one was to be made in c++.

The only other game I have made in c++ was Shark! Shark! Back last year. So this was going to be a huge learning experience. Fortune rely I have made many games in Java before, so I wasn’t going in completely blind. I knew it would be so much more work than unity, but I was ready.

I decided on using SDL for the window and input. Since I have never used SDL before, I had to spend a whole reading the documentation and working out how to link libraries into the project. This was quite frustrating at first because I was getting linking errors, but with some perseverance, I worked it out.

Eventually I got to this point though:

 

Admittedly, it took me a little longer than expected to get to that point, but I was happy when I finally got there. From this point, I started writing a lot of the things needed for the game to work. I wrote out a texture class, input, file loader, entity class, level system and a character. That took me to the night of the first day and a few hours into the next morning. I decided sleep would be best (I was right on that call) and got a good amount of sleep. When I started on Sunday, this is what the game looked like:

Next problem: scrolling levels. This was a problem because of a silly mistake I made. To get this done, I was rendering all the level with an offset based on how far the character had moved. That was working well, but the collision was off. I spent a whole playing and making tweaks, trying to work out why. Eventually I realised I forgot to stop moving the player… Now the level moved instead!

I was tired at this point, so I worked on the title screen for a little while. Nothing mind blowing,  but it was at this point I wished I wrote a gamestate base class and had a good swapping system because it was tedious making menus.

I was running out of time and my drawing skills were not up I the task of making a snake whip. So I changed the idea slightly so you release snakes into traps to stop you getting harmed.

Finally I made the traps before submitting the game. The traps caused me some issues as for some reason it didn’t like changing textures. I fixed them by breaking in a for loop involving collision. So….apparently they are related?

Overall, I am not so happy with the game I created, but I am still happy I made it in c++. I knew I was dooming myself to a not so great game, but to me the learning I did over the weekend was much more valuable than making another game in Unity. I also believe I am a lot more confident with c++ as a language now. I found I was getting less and less silly errors the further along I went (except they texture swapping problem!).

 

Dyadic Alpha Build Play Test

I was extremely happy with the playtest that happened today. There is one aspect of the game that we have been debating weather is being portrayed in the game over the whole development and today we found out we were successful!

As the brief required the game to be based around trust, we were trying to create this false sense of trust with the players. By having both players hold the same controller, it made them close to each other. The puzzles also requires the players to pass the Jade Statue between themselves (which is the item you want to get to the end of each puzzle). However, we were not sure that there would really be that competition for the statue…but there was.

When I saw people playing the game and screwing each other over, I was overjoyed. This is exactly what we were going for. The last room is quite simple. There is a door that needs to be opened by one player on either side, a ledge that is too high to jump up with the statue and finally a hatch. This room is supposed to be where they find out if the forced trust together is a false one or a real on. While one player holds down the switch, the other needs to go up there. Then, they pass the statue through. From there, it is up to the player weather they just leave the other one behind and take the statue, help them across and leave together with the statue or help them across and leave together without the statue.

We got varying results, but what was best is everyone was reluctant. They we all like “No…you hold the button and I will go across”. This was fantastic to watch. In the end, Only 2 people left without their partner, but that reluctance is what we were hoping to achieve.

Apart from that massive success, we also got to watch them tackle the puzzles from a fresh perspective. This has helped us see that there is a little bit too much backtracking for our likings and for the players liking. We also got to see where there were some minor bugs that need to be fixed.

I am really excited for the next two weeks because we have a playable game at the moment, so that means we can spend most of the time polishing it and fixing bugs as they are found. We plan on having more playtest session before we display our game at the Gallery on April 28th.

Troublesome Mirrors

  I finally got the mirrors work mostly how I wanted them to. Over the last week and a half, there have been too many iterations of these mirrors. Everytime I fixed one thing, two others would break. But I guess that is programming for you. The mirrors function through the use of two scripts working together. Once for the lightsource so the light direction can be set and one script for the mirrors to handle all the light traveling and bouncing. The mirrors really don’t use too many variables. I was quite surprised by how few were essential. I have a look direction for the mirror, an input light direction, and output light direction, a partner mirror and finally a bool if it should be drawing light or not. What happens is when the light is hit by another light (weather that comes form a light source or another mirror doesn’t matter) it starts to raycast in the direction the light will travel, to determine if there is another mirror within range that the light can bounce off. If so, the first mirror will send it’s output light direction to the second mirror which sets it as it’s input light direction. It then runs a function to determine which way the light should bounce out and sets it as the output light direction. This continues until all mirrors in the path are accounted for. Each mirror also keeps a link to the next one so when the light turns off, they can send the message down the line that the light is no more and that they should turn off the light. A big issue I ran into while making the mirrors was light changing distance per frame. One frame it would be the full length forwards, the next it would be the full length backwards. This is because the distance would be multiplied by a negative number each from when facing towards the right, causing it to keep switching from negative to positive. To counter that, I just got the absolute value of the light distance and accounted for which way the mirror was facing as to which way the light should go. Another issue was if the mirrors got into a loop the last mirror would be setting it’s partner mirror to one that was further back in the line. This meant when the light was turned off, they would tell everyone in the line that it is off, but when you get to the end, the last one was telling one that already turned off and then that one would tell the next again. This obviously caused an infinite loop and we were getting stack overflow errors which would freeze the game for several seconds. To counter this, I just didn’t allow mirrors to add partners that already had partners. That way, when it came to the last mirror and it tried adding a partner, it would see that it had a partner already and would get no partner. Overall, I am quite happy with the outcome. There are a few things I still want to do like instead of instantly showing the light, I want it to move in over time and I want to make it so that the last light fades out at the end.

Game Engine Stuff

Over the past week I have finally started putting my stuff together to begin a long term project I want to work on. I want to create a 2d game engine in c++. Already since starting it, I feel like I have learnt a lot of new concepts and worked out how to apply old ones. Current in my engine I have window support, input manager, vector2s, vector3, vector4 and matricies. I have also set up opengl and will be using that to render.

I found some libraries that assisted with the creation so far. Firstly was a library called GLFW. This library helps to manage windows and input. Using it I was able to easily create a window manager and also poll for events. Using this library has given me more motivation to actually get started with this as in the past when trying to make my own windows from scratch, I would get bogged down will all that stuff that you need to do to even make a window. Therefore, I feel like using this was a massive step in the right way for writing my first engine.

Next I found a library called GLEW. This is a library with all the openGL function pointers and will allow you to check if the user’s graphics card will support certain function from newer versions. This will prove to be very beneficial when I start writing rendering.

With the maths section, I was brought over my vector and matrices classes that I made a few weeks ago for my maths library. I plan on continuing to write my maths library but as a separate project that is linked to the engine. That way I can use it by itself if I ever need to or I can use it within my engine.

Day/Night 2D Game Shader

During the last couple of weeks, I have jumped aboard a fan game based on the legend of zelda. It has been somewhat difficult as I have joined the project during development, so catching up with all the information has been hard. Luckily there is alot of documentation, so I have been able to follow that.

when reading stuff about the game, there were some mentions of meeting people at night. So that raised the question: is there a day night cycle? When asking around the team leader said there isn’t at the moment and asked if that was something I could do. I thought about it and said I would look into writing a shader for a day night cycle.

I wanted to try an make this shader without looking at examples, so I did. I played around with paint.net to try and work out how to make colours darker mathematically. I eventually came up with taking the same amount of colour from the red, blue and green. This worked well and gave me the desired effect.

So I wrote a time system that set a uniform variable I. The fragment shader to say how much colour could be taken. The I just took the amount from the red, blue and green and then finally clamped the numbers between 0 and 1.

The end result can be seen above. I want to work on two more things relating to the day night cycle. Firstly I don’t want to use the shader indoors. That would be strange. Secondly I want to make the light transition slightly smoother. Overall, I am quite happy with the shader in its current form.