Highscore table – NodeJS

After starting the task in class, I have gone on to complete a highscore table that can be used to store anyone’s highscore and retrieve a list of them back. I wrote the server in NodeJS and used a MongoDB to store the data.

Creating the server with Node wasn’t too difficult as we used a thing called Express. That gives you a set up for a server and then you extend on it by having different routes for different pages. The functionality of the highscore table is a little limited due to time restraints, but it works well for a top 10. It allows a creator to store a user’s score, username and date into the database to be retrieved at anytime. When the data is to be retrieved, two parameters are required to be passed. First, the starting point of the rankings. This is so if you want to see maybe rank 10-20, you can ask for them. Secondly, you need to pass the amount of results you want back. That way, if for example you want the top 100, you ask for results starting at 0, and you want 100 results back.

I struggled with the MongoDB stuff as a few things from their website didn’t appear to work. I am certain I must have been using them wrong, because things such as .forEach was not working. However, I found other ways of doing it and after many trial and errors scenarios, I finally managed to get it all working together. The next step was to actually use this data in a different application that wasn’t the server. I decided I would do it in Unity.

Unity has a nice class called WWW built in that allows you to send and receive data from a server. This made it super simple to send data to be stored and ask for it back. I set up a few input boxes and buttons and then hooked them up to be able to send and receive data. I then display it on the screen to demonstrate it works. There were not too many issues with getting it to work in Unity. The largest issue come in how to format the data to send. Before using Unity with the server, I was using Postman to send Post requests. There, the body looked like this:

{“username”:”corey”, “score”:100}

However, I didn’t realise I had to send them separately in unity. So I was sending it as a single object and it was inserting it as one object, which was not desirable. Once I got past that, the other issue I had was sending an integer. As I am using the Greater than and Less than operations to send data back, they need to be ints. But when I sent the data (even as an int), it kept getting converted to a string. To fix this I had to parse the text on the server side. It looks for the score object and parses it to an int.

Looking forward – Preparing for a Job

 

It is getting close to the end of the degree, and it’s time to start looking forward at where my goals lie. Until recently, I wanted to be a tools programmer. I would still take a tools programmer job, but my interest has shifted to Gameplay Programmer. I find this role to be much more enjoyable as you are writing the code for gameplay.

While researching, I found that the term Gameplay Programmer varies quite a bit between companies. For example, some companies a Gameplay Programmer is considered to be a entry-level job or a junior position where they can move up into engine programmer or other roles after proving themselves. Whereas, other companies consider Gameplay Programmers to be senior roles as they are writing the code that affects the player’s experience. In those cases, they are also expected to be fairly good at game design.

In general, the main skills a Gameplay Programmer requires is experience writing code (most of the jobs require c++ or c experience), knowledge of the technical pipeline for creating games, strong mathematical skills (main examples are trigonometry and linear algebra), excellent written and verbal communication skills, a good personality and finally a huge passion for making video games.

Good news! I have most of those skills. However, I can still identify areas I want to improve in by the end of the year. One of the areas I really want to improve is my knowledge of the audio side. I have worked closely with artists, designers and programmers, however when it comes to audio, I usually just trust their judgement because I have very little knowledge in that field. Recently I have been working on a game that relies on music for the gameplay. All enemies will be moving in time with it, and I have been learning a lot about the music process because I have been working so close to it. However, I still want to learn more about it, and I have decided that for my elective subject next trimester, I will choose an audio course to become more familiar with the field. I feel like understanding that section of game development would help me further connect with a whole team.

Other skills I want to improve my C++ programming skills and my math skills. The outlined skills required for the maths is not a concern, but there is no harm in furthering these skills. The ways I want to do this is just by completing small projects throughout the next trimester. Other ways is to try and apply maths to as many problems as I can within my games. One good time to improve both these skills is at the Make-A-Thing during the holidays.

Finally one last major thing I want to improve is the quality of documentation. At the moment, all my documentation is acceptable, but I want to improve upon it. There are still moments when I or someone else has to another what we decided because it wasn’t written in the documents. I want to start a habit of updating the design document to make it the living document it’s supposed to be. I have started doing this with Dyadic, however, it have yet to start doing it with final project. That is something I really want to focus on next year and will be something that is extremely helpful when I work in the industry.

Overall, my skills are coming along nicely for a Gameplay Programmer and my passion is there, but I still have areas (and always will) that I can improve in to help secure a position. By following through with these things I want to improve on over the next trimester before finishing, I feel like I will have the necessary skill set to be able to get a job as a Gameplay Programmer.

Here are some sources I found to enhance my skills:

Audio Terms: http://www.mediacollege.com/audio/terminology/

Here are some gameplay programmer positions I found to determine the skillsets required:

https://blizzard.taleo.net/careersection/2/jobdetail.ftl?job=80641&src=JB-1052

http://www.creativeheads.net/job/14566/gameplay-programmer-in-plano

http://www.gameloft.com/corporate/jobs/job-apply-details/223/?group=83&job=3476&loc=45&applyby=categ&mode=job&iis=Job+Board&iisn=Indeed.com

 

Dyadic got Greenlit!

Everytime I think about how we have earnt the right to release a game on steam, I get a little excited. Steam is THE place for PC gaming. It’s where my massive library of PC games is stores. It’s a place I check regularly to see what the most current specials are and to play my games. It’s pretty much the place you want to release your game on for PC.

I woke up on Friday the 14th of August to see this email in my inbox: “Congratulations, Dyadic has been Greenlit!”. At first I didn’t believe it. It was 6.30am, I was very tired, and I was very sceptical. I tried reading through the email, then just decided to open steam and check. And behold, it was actually true. I wasn’t half asleep anymore. I was messaging team members about it and we were celebrating. We were excited. We had achieved the Greenlit status.

This whole development cycle has been extremely interesting and different. I always knew there was a lot of work involved in creating a game. I have done so many times. However, I never really looked at it from different angles. Marketing is difficult and time consuming. Writing the devlogs takes time. And there are a load of questions we have to ask ourselves about marketing our game. It’s been hard, and none of us really knew if we were doing it right, but I guess we must have been doing something ok.

Not trying to sound too cliche but I am really thankful for all the support we have received. Being able to work on a games project that would be received by a large market is something I have dreamed of since I was about 12 and I decided I wanted to make games. I really want to put my all into this and hopefully something will come from it.

Green Banana

Green Banana is probably the best 2D game engine in existence if I do say so myself. How did it end up with such a silly name? Simple. I named the engine at 8.30am on a Monday morning before I had had any coffee that day.

The Green Banana Engine (GBE) was created as part of a 40 hour comp where you can make anything called “Make-A-Thing“. My team consisted of Chris Snitzerling (Programmer), Callan Syratt (Programmer), Angelica Zurawski (Artist) and Myself (Programmer). The crazy idea to make an engine in 40hours came from the fact that it doesn’t matter if we succeed or not, as long as we learn, and the fact that we really wanted to challenge ourselves.

The first day was a little chaotic. We had to come up with a game idea to show off the engine and we had to start UML for how the whole engine was going to work. The idea we settled on was a Marshmellow platformer. The Marshmellow would run through the level, collect coins, purchase upgrades, and avoid enemies. Generic, yes, but in the end we were lucky to even get that going.

We spent about half of the first day and half of the second doing UML and planning how everything out fit together. This process was a lot determining what was needed in the engine, and then how we would do it. We stood at a board talking it over for hours on end, and eventually, we can to something that looked like it was going to work (but it totally wasn’t!). I would insert a picture of the Nicely done UML, but I cannot locate it at the moment. Instead, you get scribbles from a board.

IMG_0116 IMG_0117IMG_0118 IMG_0109 IMG_0110 IMG_0111 IMG_0112 IMG_0113 IMG_0114

After all the planning was done, we assigned work and got started. This is our favourite part. We all started writing stuff, committing it to the repo and then we start to realise things are not going to work. So we go back to the board and work out a solution. This happened for 2 days. Eventually we started testing stuff and it was working…mostly. Just don’t run the game for too long ;). Now that we had the systems implemented, it was time to make the game.

We had approximately a day to make the game. Needless to say, during this whole project, we didn’t just work at uni. We continued it at home each night or we stayed back at uni until it closed at like 6.30-7…so we sorta had more than 40hours. But meh, that’s not important. Making the game was a little more teadious than we intended it to be as some of the systems we not developed in ways we would have liked. As we were sorta C++ rookies, we ran into a few issues with syntax, so some things were done in terrible ways.

As we needed to make a level, we ended up making a ingame level editor. If you paused the game, you could press 1 through to 0 or Q through to P to create objects and place them. You could then save the level so it would be the same next time. An issue we had with this were moving enemies. If they were mid movement and we saved their position, they would start in the wrong place next time. So it was back to the board and we fixed it. This wasn’t the most beautiful editor ever, but it functioned. We made final version of the level for the game in the last hour. We were stripped for time.

The art in this game was beautiful. It definitely allowed us to feel better about our work as we had nice artwork to show off in the game. We had a little laugh when we received a walk animation with 90 frames. It was extremely smooth.

Overall, we were very proud of our work. We created an engine and a game all within a week. From planning to coding to showing it off, it was all done. We won some award, we went home happy, and we rested for the next week, getting prepared to go back to uni.

 

https://github.com/Silcoish/GreenBananas

 

On a side note, here is some UML

uml

Flocking…sigh

This is one of those tasks that I really had to push myself to get done. I just wasn’t enjoying it much, and there were a few reasons for that. We will look at those throughout this blog.

The task was to take a flocking simulation supplied by Steve (one of our lecturers) and then optimise it, add features, make is usable by a designer and then display data. It was a task that spanned a couple of weeks.

The first stage of the project: Optimising. This is one of my least favourite things to do when it comes to programming. It’s even harder when it’s not your own code. The first thing I noticed when I opened this project was how confusing everything looked. The code seemed so much more advanced compared to mine. Fancy C++11 stuff, Macros etc. It was difficult to read, difficult to comprehend and difficult to work out how and where everything communicated. Most of the time I spent on this step was trying to work out what the actual hell was going on. I did some small optimisations such as adding multithreading to the update, cached some variables and tried a quad tree.

Once that stage was over, we got to do something a little more interesting to me. We had to make the simulation’s variable tweakable in some way so designers could use it and tweak variables until they get the desired effect. Origionally my plan was to make a GUI for the user’s to use, and I even did a mockup:

FlockingSimGUI

 

However, in the end I couldn’t get TGUI working due to having outdated versions of SFML from the framework and them not supplying older versions of TGUI. So I swapped to a spreadsheet. The spreadsheet had all the variable to be tweaked, I added rules to it so invalid data couldn’t be entered, and then added a Save button which saves it out to CSV to be read straight into the flocking sim. Then I wrote a CSV parser for it in the flocking sim and then that step was done. I am a little dissapointed I couldn’t get that GUI going, but I already wasted too much time on it so I had to make the decision to just go with a spreadsheet. At least my next step worked out how I wanted it to.

To display the data, I wanted to trying one of those graphing programs. I have heard of R before, but then I got told about processing. I wrote a whole blog on this process further down, so I won’t go into too much detail here. This was my favourite step as I got to test out two new languages and do something that I have never done before.

Overall, I am glad that the project is over and I put a lot of effort in, but I am a little unsatisfied with the task as a whole. I found it hard to get motivated to do the optimising as I really don’t enjoy it, but the rest of the project was ok. I’m glad I did it in the end though as I got to look at using R and Processing, which I really enjoyed.

You will not be able to build this project as it uses a framework supplied by Greg (Another Lecturer) and is not publically available.

https://github.com/Silcoish/studio3flocking

OpenData reflection

This task was a bit of a mess. The original intention was to make a tool as a class that would be able to read in csv, xml and json and then spit out KML for google earth. Then we would make correlations between the data. However, the task didn’t really end up like that. That’s for a few reasons which will be discussed.

What we ended up doing was taking our data, making a conversion for that set of data (as opposed to a generic converter) and then displayed our KML in a comprehensible way.

The main reason that this task got pushed back so much is due to tackling 3 things at once. We were working on the alternate input device project (Breathing detection with the connect for me) and the flocking task at the same time. This meant that unfortunately this task got left behind. Eventually, we decided to post-pone it but once we came back to it there was another issue…

Most of us had picked csv data. This was because it was the most commonly available format, and all the interesting data only really came in csv. So we ended up just writing the parsers for our specific set of data. This is where I decided to give C# .net a go for the first time…and I must say, I was impressed. Usually I would be tempted to just do it in c++, but I have reflected on that in the past and I know that’s not a great solution. The time it would have taken to do it in C++ would well exceed the C# time. That’s because I would have had to make some sort of way to choose a file, choose an output location then write the parser. However, .net has a lot of that stuff covered. Using the WinForms made my life so much easier. All I really needed to write was the parser and then spit out the KML.

I believe it was really wise to use C# as it has allowed me to see a problem in my pipeline. Prior I never took the language into consideration. However, continuing forward, I will now take the language that would be most beneficial to the project into account. Good lesson learnt.

Ma’at’s Recruit UML designing

Ma’at’s Recruit is the name of our final project (Name is subject to change thankfully!). This game is a roguelike game that is set in an ancient egyptian era and focuses on a hero chosen my Ma’at herself to settle the battle with Anubis. However, i’m not here to sell the game today, i’m here to discuss UML.

Now I would be lying if I enjoyed writing documentation. However, I understand the significance of it and how it will undoubtedly help us in the future. One of the important documentation stages is UML. This is where you document how your code is going to work together. You outline the classes, their members, functions and how they link to other classes. So we completed some UML for Ma’at’s Recruit.

The process has been extremely helpful processes. The way we tend to do it is to write out what systems we are going to need to a whiteboard, then start filling in how they work. My favourite part of UML is being able to know exactly how the code is going to work and have a reference to refer to anytime. A good example of UML working out for the best is when I was working on GBA stuff with Chris. We both wrote our parts and they just worked together without us having to fix anything.

MaatsUML

 

First podcast

Had a new experience this week. On Tuesday, 4th of August, myself, Jack and Callan all traveled to uni to be part of 8 and a half bit gaming podcast. This was the first time that we have ever been part of a podcast, and it was really fun.

Creating Dyadic has been a great experience as it has allowed me to get involved in things that I have never done before such as marketing, creating greenlight campaigns and even podcasts. We were all a little nervous to begin with as we didn’t know James or Paul very well. However, that all changed within a few minutes of talking to them. They had a way of making us feel a lot more comfortable.

We were asked questions about Dyadic, we answered them and then it would usually go off track in some way. It was really fun. I’m glad that we participated in this podcast as if I want to be serious about games development, I’m going to need to be able to talk to people about my games. And this experience gave me some more confidence.

I won’t ruin too much, but we talked about our greenlight plans, our futures and even a love story! I will make another blog post when it’s available to listen to.

Handsome Dragon Games website

I worked on yet another website this trimester. I’m starting to get a name for myself…

At the beginning of this trimester, after deciding what name we were going to use as a team (Handsome Dragon Games), we purchases the domain name and hosting. Then I was in charge of making the website. This task basically fell to me as I was the only one with web experience and we needed it done as soon as possible so we could start promoting ourselves.

At the beginning of each website I develop, I forget how much I hate the whole process. Websites was how I first got started with code and which spiked my interest in making games, but boy do I hate making them nowadays. There is just so much bullshit. I think I have identified why I hate web development, and found ways to make it better.

My main problem is I know PHP. So I made the website with PHP. I just don’t enjoy writing that at all, so it’s miserable. But recently I got involved with Node and I am enjoying that so much more. Next time I am on for making a website, I will use Node instead and see how that goes.

Another problem I have with web development is making a sytle. I planned out the style, created it from scratch with CSS (though I have discovered Less since then and will use that next time to make this a little less painful) and then found out that the colours didn’t work. So we spent about 4 hours as a team just changing the colours and seeing if they work. However, css doesn’t have variables (again, will use Less next time!), so it was super annoying having to change the colours. Sure, you can use Ctrl+F to find the colours, but then you got to edit them everywhere they are used. Eventually, we settled on colours even though no one is truly happy with them. I think the problem is the theme isn’t very good.  What I did was look at a few themes and tried taking the best things and putting them together. I don’t think that worked very well.

Now that I have some experience with Node and Less, i’m once again looking forward to making a website. I really want to see if this makes the process a lot better or there is something else that I am overlooking at the moment that makes me unhappy to make websites.

Dyadic’s Greenlight Debut

It’s finally time… time to put Dyadic on Greenlight. We have all been working extremely hard over the last two weeks to make sure everything is up to scratch to make sure our Greenlight campaign goes well. Admittedly, I have probably put a bit too much time into this over Studio, but this was really important to me and my team so I made that sacrifice.

We have been doing many things outside of making the game to make sure we are ready. Things such as making promotional material (Posters, Business cards and Website), creating the videos needed for the Greenlight page and lots of writing. It has been a really interesting experience as these are things I haven’t really been apart of when making a game. All other projects I have worked on have never come this far, and it’s exciting being in this position.

It’s a little scary thinking that we will be showing off our game and people will be able to leave all sorts of feedback. I’m looking forward to reading all that feedback (negative or positive) and hopefully being able to shape the game that we want to make and that people want to play.

Everything was ready in time and the game was placed on Greenlight successfully. We didn’t miss anything vital, so that’s a good start. Now we need to continue marketing the game and getting lots of people onto that page voting for us. Within the first day we had a massive hit due to all the followers we have acquired through social media and lots of people sharing our page and post about greenlight. It was really motivating scrolling down facebook and seeing how many people actually cared enough about us and our project to share us. Let’s hope this all works out for the best.