Creating Shapes using Vertices and Triangles (Research task)

I did some research over the weekend into voxel terrains (as I wanted to make a terrain gen tool) and I started getting into creating primitive shapes by specifying the vertices and triangles. When writing my tool, I didn’t want to have to the player specify a cube gameobject, instead, I decided it would be better to create the cube in code.

void CreateCube()
cube = new GameObject("Voxel");

Mesh mesh = new Mesh();

mesh.Clear(); = "Custom Cube";
mesh.vertices = new Vector3[] { new Vector3(0, 0, 0), new Vector3(0, 1, 0), new Vector3(1, 1, 0), new Vector3(1, 0, 0), //front
new Vector3(1, 0, 1), new Vector3(1, 1, 1), new Vector3(0, 1, 1), new Vector3(0, 0, 1), //back
new Vector3(0, 1, 0), new Vector3(0, 1, 1), new Vector3(1, 1, 1), new Vector3(1, 1, 0), //top
new Vector3(0, 0, 1), new Vector3(0, 0, 0), new Vector3(1, 0, 0), new Vector3(1, 0, 1), //bottom
new Vector3(0, 0, 1), new Vector3(0, 1, 1), new Vector3(0, 1, 0), new Vector3(0, 0, 0), //left
new Vector3(1, 0, 0), new Vector3(1, 1, 0), new Vector3(1, 1, 1), new Vector3(1, 0, 1)}; //right
mesh.triangles = new int[] { 0, 1, 2, 0, 2, 3, 4, 5, 6, 4, 6, 7, 8, 9, 10, 8, 10, 11, 12, 13, 14, 12, 14, 15, 16, 17, 18, 16, 18, 19, 20, 21, 22, 20, 22, 23};

cube.GetComponent().mesh = mesh;

//apply material
Shader shader = Shader.Find("Diffuse");
Material mat = new Material(shader);
cube.GetComponent().sharedMaterial = mat;


To explain the above code: I am using the bottom left as (0, 0, 0). From there, I am placing the vertices in relation to that point. So, there needs to be 8 vertices in total to make a cube (4 for the bottom, 4 for the top). Once I have created all the vertices, I need to move onto making triangles to render the faces. Each side of the cube requires two triangles, to make a square. Therefore, we need 8 triangles too. Triangles are made by specifying the order of vertices which join together. The first triangle is made for the bottom face and joins the points 0, 1, 2 (bottom left, top left, bottom right). Then to make the square, I made another triangle using the vertices 0, 2, 3 (bottom left, top right, bottom right). That will then create a square. Just repeat that for all the sides, and you now have a mesh. Just apply the mesh and ta-da! You got a cube!

When searching, I found it was fairly simple to create a cube by defining the vertices. I worked that out pretty simply, but then I ran into a problem with the triangles. I found that I was doing the vertices in different orders on each side, which would mean the triangles would need to be in different orders to make sure they are rendered from the correct side. After playing around for a while, I found that adding the triangles in a clockwise order will cause the triangle to render upwards, while adding them in a counter-clockwise order will render them downwards. This was interesting to learn as I was struggling with the faces rendering the wrong way.


I wanted to make sure that I actually did understand how all this worked, so I decided to create something more complicated: A Hexagonal Prism.

void CreateHexagonalPrism()
GameObject hexagonalPrism = new GameObject("HexagonalPrism");

Vector3[] verticies =
//Bottom vertices
new Vector3(0, 0, 0),
new Vector3(0.25f, 0, -0.5f),
new Vector3(0.5f, 0, 0),
new Vector3(0.75f, 0, -0.5f),
new Vector3(1, 0, 0),
new Vector3(0.75f, 0, 0.5f),
new Vector3(0.25f, 0, 0.5f),

//top vertices
new Vector3(0, 1, 0),
new Vector3(0.25f, 1, -0.5f),
new Vector3(0.5f, 1, 0),
new Vector3(0.75f, 1, -0.5f),
new Vector3(1, 1, 0),
new Vector3(0.75f, 1, 0.5f),
new Vector3(0.25f, 1, 0.5f)

int[] triangles =
1, 2, 0,
3, 2, 1,
4, 2, 3,
5, 2, 4,
6, 2, 5,
0, 2, 6,

7, 9, 8,
8, 9, 10,
10, 9, 11,
11, 9, 12,
12, 9, 13,
13, 9, 7,

0, 7, 1,
1, 7, 8,
1, 8, 3,
3, 8, 10,
3, 10, 4,
4, 10, 11,
4, 11, 5,
5, 11, 12,
5, 12, 6,
6, 12, 13,
6, 13, 0,
0, 13, 7

MeshFilter filter = hexagonalPrism.AddComponent<MeshFilter>();

filter.mesh.vertices = verticies;
filter.mesh.triangles = triangles;

hexagonalPrism.transform.position =;

In the code above, I did similar to the cube, but this required many more vertices and triangles. To begin with, I created all the vertices for the bottom of the hexagonal prism. Then I copied them all and shifted them up 1 unit. The order I created the vertices is:




I am unsure if this is how it would normally be done, but this made the most sense to me at the time, so I went with it. I made sure that when making the triangles for the bottom, I did it in reverse order to make sure they were facing down. Finally, I then joined the top and bottom up by using two triangles for each side of the shape. That required 12 triangles as there is 6 sides. Here is the finished product:



Overall, I feel like I understand how meshes are created a lot better. I plan to make more shapes that unity doesn’t naturally support in the coming days and then add them all to the GameObjects section so I can easily create them at will.


Self Reflection

Over the trimester, I have done things well, and have dropped the ball other times. My goal is to become a tools programmer, but I only wrote one tool this trimester. I would have liked to write more, however, I was finding it difficult to come up with tools that don’t already exist, or would make people’s lives easier. While working in unity, majority of the things you would even need is already there.

At the beginning of the trimester, I was really burnt out from a project over the holidays. I spent the majority of my holidays working on a project for a client (which I hated!) and by the time the trimester started, I was already burnt out. This was a terrible start to the trimester as I didn’t feel like doing anything for the first few weeks. This was worrying for me as I knew I was wasting time, however, there was absolutely no motivation there to do anything. After a few weeks of doing smaller loads of work, I finally found my motivation again and I got straight back into it.

The only way I can see I could have avoided this was by not doing the project. However, this was a good learning experience as these kinds of feelings arise often within the creative industry, and I just hard to learn to keep pushing until I found my motivation again. Next time this happens, I think I will handle it better as I know I will find my inspiration to make games again, I just need a little time away.

I feel like I really dropped the ball with the creation of my bot, as I implemented A* then sorta called it done. It worked well, it just wasn’t as good as I could have been. I spent a long time trying to get the A* working, and was super happy when it was working, but I never even thought of things such as tracking etc. However, I was not alone here. None of the bots really did anymore than path find and shoot. After that, I really was disappointing with my work and have since tried to put everything back into my work.

I worked on a game over the weekend as part of a 40-hour game jam. This was an really great learning experience as I decided to do it in c++ to improve my skill and knowledge. As I have never made a game by myself in c++, a lot of learning had to happen. I spent a lot of the first day setting up things in the project such as Linking libraries, setting up the window and rendering. I was using SDL for the rendering, which took a little while to actually learn how to use, but worked very well. At the end, I feel like I was much better with c++, learnt a lot about making games from scratch and I am much more comfortable with writing c++.

Throughout the whole 6 weeks of working on Dyadic, I put all my heart into it. I really enjoyed working on it the whole time and it really helped improve my skills as it is the most polished game I have ever worked on. I would always get my work done as quickly as possible, but also as high standard as possible.

My goal for the project was to make a 2d level editor. This was at the beginning when we were talking about doing tile based game. I am glad we chose a different style for the game, even though I didn’t get to make a tool. I feel like the way we took Dyadic was excellent and the art style really suited the game. It would have been really hard to create something similar to what we ended with if we used tiles.

Even though I wasn’t needed to create a 2d level editor, I managed to keep busy the whole time. I took on the role of creating the mirrors…which turned out to be a lot of a hassle. They got me down at times, but through working on these, it reminded me why I love programming. It’s that excitement, that “fuck yes, I did it” moment when you are trying to solve a problem for a long time and finally get to the solution. It’s also seeing what you created working on the screen, ready to be enjoyed by others. There is so many things I love about game development, and the project reminded me of them all.

Terrain Tool


This is the beginning of the terrain tool I am working on. Currently, it allows you to generate terrains in edit mode, but there is so much more I want to do with this. Here is a list of all the other things I want to add:

* Allow Materials instead of colours
* Allow users to supply own shader
* Make into 1 whole mesh
* Collision mesh
* Allow window to scroll as needed
* Different block size
* Presets

Everything here is done in code. I was looking at building meshes via specifying the vertices, triangles and uvs to be able to make a voxel world and it lead to this. Originally, I had it so the player would have to give a cube gameobject (hopefully!) and I would use that for the terrain. I took that unnecessary step out and just generated my own cube. It was really interesting. One problem I ran into was the order I was creating the triangles. Because I didn’t have the vertices being added in the same order on every side, the triangles were forcing it to be rendered the wrong way around. I found out the order is important after a while, and fixed it. I eventually got a beautiful cube I made which I used in the tool.

Another problem I had with the cube was the normals were all wrong. The lighting looked awful! I was really confused as I through the normals would have been worked out. After a bit of searching, I felt silly because I forgot to reset the normals. Once that was done, the cube looked just like the default unity cube. I was super happy with it. I will be using this knowledge to improve my terrain tool by making the whole terrain a single mesh rather than individual meshes. It would drastically improve the performance of it and would allow for much larger landscapes.

Dyadic Post-Mortem-ish

The development of Dyadic, a two player co-op puzzle game, is complete after 6 weeks of hard work. Dyadic is a game set in Chinese ruins where two adventures are there to collect the jade statue and bring it back to the surface. It features the two players having to rely on each other by passing equipment between one another to get to the end of the ruins. In the final room, there can be three outcomes. Both players can leave with the statue, one or the other can, or neither leave with it. Overall, I feel like the idea was a very solid one to work with.


This project was one of the most successful projects I have ever worked on. There were many contributing factors to this, but I believe the biggest was the communication. It was fan-bloody-tastic. Our team leader, Jack, set up a slack chat for us to use rather than facebook or other means. This was an excellent idea and we used it the whole project.

Slack is a chat system that allows your whole team to be involved through conversation. The main advantage is you can have many different chats called channels, where you can keep relevant information. For example, we had 10 different channels by the end, helping us keep all the information we needed sorted and easy to find. They were Art/Animation, Audio, Documentation, Game Design, General, Graphic Design, Poster Design, Programming, Random and Repository.

We were all pushed to have slack open whenever we were on the computer and it seriously helped. Being able to communicate with everyone so cleanly and efficiently anytime made getting ideas across so much easier. It also made Jack’s job of being leader so much easier by being able to get in contact with anyone within minutes, allowing him to focus more time on game design. Overall, with us spending so much time with slack open, we were able to work much more efficiently and to a higher standard as ideas were portrayed clearly and rarely needed to be completely re-done.



One of the biggest problems we had was code wise. It resided with the mirrors as every time they appeared to function as intended, someone would find something wrong with them and I would have to fix that bug, probably causing another one in the process that wasn’t obvious until another test. It was an interesting position I was in as the code was quite large and complex, so finding the errors served to be quite difficult sometimes. This had me going back tot the code every few days making small tweaks to make sure they worked in the scenario. In the end I ended up re-writing the whole system in the last week. This was because I felt it was getting to a stage where it would be better for me to re-write them rather than trying to fix them over and over. It turned out much better, with no recorded bugs by the gallery. I believe this was the best choice as I had spent a lot of time with mirrors and knew how I wanted them to work, so re-writing them was the best case. To avoid this problem in the future, I should consider the possibility of re-writing code rather than trying to fix it. Because in this case, that was definitely the best solution.

The other really large problem we had was a game design issue. We wanted the Jade Statue to be a huge focus in the game, however, we were unsure how to present that idea clearly to everyone. We did many things such as different sounds where you are holding it, you glow while holding, the other player’s lights dim when you have possession and even had really nice particles swirling around it. But still, people were leaving it behind. After going through many ideas over the weeks, I feel like we did an alright job as getting people to notice it. However, it still stumbled people as they would leave it behind. It would have been better to do a lot more play testing with different ideas to see how we could have portrayed that idea better.

Overall, the whole project was a massive success in my game. After many projects where the communication hasn’t always been the greatest, we finally found a solution that really helped and way effective. Every project isn’t perfect, and this is no exception. We had problems, but I have learnt from these once again and hopefully will benefit me in future projects.


Team Dyadic

Jack Kuskoff – Creative Director

Corey Underdown – Programming

Callan Syratt – Programming, UI

Jared Ford – Programming

Angelica Zurawski – Lead Artist

Samuel McLean – Lead Musician

Nicole Biddle – Graphic Design

Karl Mizzi -Graphic Design

Download Link (Note: You probably want a friend to play with…but it’s not necessary!):’Jade%20Dragon’


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

MirrorsWork   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. MirrorError 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.