Me, a Programmer

Here I am again, at the end of a trimester, and I'm about to wrap up everything I need to do. It feels strange, I don't feel like I've done much, but when I look back I can see just how much I've progressed.

There's been a few things that I, as a programmer have learned in the past few weeks. I'd love to share these things with you. But first we have to start with what I've created, my role in them and what I came out of them with. 

The freshest project in my mind is Shared House the only major project that I've worked on in the past tri. This project, as described in one of my previous blogs, was rather challenging as both a Project Manager and Programmer. While I didn't do much in the way of programming, what I did do was oversee the introduction of 3rd party plugins and assets into the game. This included the use of VRTK and FMOD, which also required that I become quite intimate with these tools. It was awesome to see that even my basic understanding of these tools could be used to create the game that we wanted out of Shared House. 

Looking a little further back, I looked into the creation of Application Programming Interfaces. Which, while my node module is utter dog's breakfast, and I don't want anyone to use it, it was fun to look into and observe the process of creating. With the creation of this API, I was required to learn about NPM commands, Node.js and Python (both with JSON serialisation). Which was really fun to do. There's something about pulling information successfully that just feels good, I might even look into making the module actually viable in the future.

Continuing on from that sort of notion. I branched out from the C++ and C# norm and learned some Node.js with my Discord bot, Loud Pipes. While Loud Pipes is a simple bot, I wanted to use it as the initial learning platform for Node.js, and see what I could do with it. I ended up having a database of Magic: The Gathering cards that you could random, search or make a booster pack from, which worked relatively well, and looked cool too!

Moving further down the timeline, I learned some things about Spatial Partitioning in games, or just in general. It was incredibly useful to learn about quadtrees and all of that jazz, and I might just give it a more detailed shot once this tri is over. Talking about rendering stuff, I also played around a bit with basic shaders, which was fun. Though I didn't make anything too detailed, having that basic understanding of Unity's derivation of HLSL will really help in future projects. Speaking of useful information I also learned about A* pathfinding on a 2-Dimensional plane for C++. it was a hassle, but I got it working, and it worked 'well'. 

That's a really long list when I see it.

Though when I think about how I did in relation to all of these things, I don't feel like I did great, I can see that the amount of things that I've learned about in the past 10 or so weeks has been extensive, and it's really useful information in terms of being a programmer. I feel that of all of the tasks that I've set myself thus far in the project, I've come out with something that satisfies what I was trying to do. Perhaps it took somewhat longer for me to do it, but I still did it. Regardless, I still feel proud of myself for doing so. 

I believe that this tri I was able to grow, and that feels awesome. Though I still have no real idea of what I want to do in the industry. I think after completing all of these tasks, a generic game play programmer, while a basic and widespread area, that's where I feel most comfortable and that's where I have the most experience at this point in time. It might be interesting to look further into artificial intelligence, particularly looking back to the flocking project I completed some time age, looking into stuff like A-Life and seeing the cogs behind that. But I don't know, I hope that within the next couple of weeks I'll be creating small projects and pumping out games on my itch page.

But until then.

 

Tylah Kapa

...What is an API?

So one of my tasks for the past few weeks has been to create an API of some description. So being me, I decided that I wanted to learn something new and make the API at the same time. Which is why I created a python script that has the ability to gather data for Magic: The Gathering cards from a website and parsed that data out to a JSON file. Now that's all well and good, it worked!

But I have no clue how to publish this information anywhere for anyone to use. Which is okay, I guess. Regardless I still looked into what an API is, along this line of research I found that an API is a sort of accessible database that programmers can use in order to ease access to information about an application, game, website etc.

Which is why I came up with the idea of compiling a database of Magic: The Gathering cards. Of course, this has been done before but, like I said, it was a learning opportunity.  Collecting data from a website and parsing that data out to a .json file. All of the card objects contain the data of name, mana cost, rarity, type, description, flavour text and artist, of course this is kind of basic information, but it's enough to make a somewhat cohesive structure of data.

Which is where we come to actually having this data published somewhere in the world wide interwebz for someone to look at and take if they wanted to. So there's two methods that I found that would be relatively appropriate for this. The first would be to make a Node.js module that people can require in their projects, the module would simply give them access to the local database of cards that they got when they downloaded that module OR I can fiddle around with websites and hosting and try to get a ReST API up and out there. 

So naturally I set up a node module, it's easier to do and well, it's easier to do. I've never set up a node module before and so using a couple of resources from the NPM documentation, I was able to spit out the files! that API can be found here and installed with node in the command line. However, this is only a small test project, and I don't really recommend it.

 

Tylah Kapa

Shared House and Me

Hey there, if you haven't seen me lately, or you just got here. I recently wrapped up a four week long project with my peers, Noah Seymour, Thomas Lynn and Joshua Irish-Donges on my very first Virtual Reality game, Shared House. Shared House is a short game, primarily developed for the HTC Vive. The closest our team got to a brief was the concept of Home. However it was my job as a programmer, and assigned 

Shared House was a very interesting project for me. In the it was the first major project I'd undertaken for a few months, it was the first project where one person or one designated group of people were the creative lead,  I was simply there to provide them with tools and working scripts for the game, it was also the first project in a while that I'd been project manager for. So for all of these reasons, including that it was VR, the project excited me, and overall, I'm very happy with the outcome. Aside from the obvious "I didn't spend my time on this project very well." or the "I know I definitely could have handled managing the project better." the most major things that went wrong with the project were scope and understanding of the 3rd party tools we used to make the game. 

The reason scope was a problem is most definitely not for the reason you're probably thinking of right now, our scope was too small, if anything. While it made sense, and in the end, my group still ended up working down to the bone right up until Brass Razoo, the exhibition our game 'premiered' at (which is still an awesome thing I'm trying to wrap my head around). But in terms of assigning tasks, well there wasn't much to assign to the three programmers in the group. The majority of the work that the programmers needed  to have done was completed by the third week in, and the rest was basically Noah, our designer figuring out how to keep the player intrigued by this person the player has never met (which was likely the greatest design challenge in VR). So once we reached this point, I struggled to give tasks out to the other programmers in our group, and I felt bad for it, like I was a bad project manager (I'm definitely not the greatest, but I'm trying) when in reality I had no clue what could be done. So scope was definitely a problem, and it most likely would have been much more of a problem if we already knew how to use the third-party tools we used.

VRTK by stonefox is a very coherent and in-depth tool for VR that our group had the ability to use throughout this project. Unfortunately, because the majority of the team had not worked with Virtual Reality before, a large portion of the project was dedicated to learning how the Virtual Reality Toolkit fit together, and how we could adopt it into our game. This meant spending a lot of time learning how interactions with menus could be made and how to pick stuff up, how to get input from the controllers and ultimately how we put it together and make it work. Of course some of it was also spent overcoming one of the more challenging aspects of Virtual Reality, does it feel good? how do we transport people around without making them sick? Do they need a nose? all of these questions went into trying to make our game more comfortable for the player, and I think it worked. Generally I don't get motion sickness or anything like that, and so I relied on Noah's past experiences with Virtual Reality and how he approached these challenges. 

The same thing can be said for FMOD, if you don't know already, FMOD is a very good tool that can be used to implement dynamic audio into games. That is things like 3-Dimensional audio, randomising pitch, ensuring that one sound cannot overpower others. At least that' what I know it can do for know. It's an awesome tool and I wish that I had learned of FMOD and how to operate it within Unity before this project, then I would have felt much better about the amount of audio actually implemented into the game.

These, I believe are the primary reasons why the product wasn't polished as well as it could be. While that sucks, it was an amazing learning process, and now that I have a basic level of understanding of both FMOD and VRTK, I cannot wait to develop for Virtual Reality again.

 

In terms of how our team worked, upon observation of we worked alongside with in our cohort. I can safely say that we were one of the safer teams. While it took a minuscule amount of time, I gained an understanding of the skill level and experiences of my team. By then I had been assigned as Project Manager, and had already set up modes of communication, a GitHub repository and task assigning within HackNPlan. Basically just kind of going through the motions of being a Project Manager. However, it was very inspiring to both my team and I that these things had already been set up and easy to access, it allowed us to all get down and dirty in documentation and setting up a baseline for our project. It felt great, both to have a team eager to have VR experience under their belt and an appropriate amount of experience.

Of course there are instances I can point out where the project took a turn for the worse, things like one of the programmers dedicating time to hooking up his own server to Unity in order to overcome the rate limiting and information restrictions of the default Unity analytics. Waiting for assets like audio and models to come in, and be ready to use. Having tasks be incomplete, or unsatisfactory, yet still put into the game anyway (I.E. the way that the combination lock is opened feels unintuitive and sub-par). Though like I said, overall I believe that the project was a success and the team worked well together. 

The TL;DR of it is, I liked my team, we worked well, we worked relatively efficiently. A lot of the hiccups in development came from hesitation in design, and perhaps allocating time in the wrong areas. However, in the end, I loved working on this project, and I can't wait to do it again.

 

Tylah Kapa

Persistence and Serialisation

There's a lot of use to learning about serialisation and persistence in games. After all, most, if not all contemporary games have a need for persistence, be it saving the game's progress, saving the player's setting preferences or carrying weapons or choices from level to level, you know, having data that will persist in and outside of the game.

Here is a small Unity project I made which demos saving and loading in Unity. The only things being saved and loaded are integers and they're going out into a binary file. Of course saving only integers is relatively simple. However, now that I know how to save out simple data, I can slowly move on to more complex data. This system also only saves out to a binary file, though I feel that knowing how to save out into a .json, or .xml will be just as useful, as each file type can be used for various things.

For example, Json and XML are much more human readable and easily editable, while they might allow for weaknesses in the program that can be exploited, they can also allow easy editing of data without ever touching the Unity editor. One use we were able to come up with, for example, was for the project that I'm working on right now, which contained a lot of written dialogue. An idea that my group and I had was to have a json database that programmers could load and assign elements of to objects via scripts, allowing the person editing the dialogue to easily change it without touching the code. This worked somewhat, though this element was quickly dropped to save time. The downside to these files is that they're rather slow to read and write, which is why they should be used for storing data that is used for initialisation.

Binary files are less human readable and are harder to edit, and so is much better for holding data that shouldn't be touched by the casual player. Reading and writing binary is much faster than reading and writing json or xml, and so it's more useful for doing things like autosaving, quicksaving or quickloading. They're also much smaller, though now that games are almost in the hundreds of gigabytes per game, I doubt it really matters, though every little bit counts. In the end, I'm sure I'll end up knowing how to do both in the various languages I'm sure to know... eventually.

 

Tylah Kapa

 

 

Spatial Partitioning

If you don't already know what spatial partitioning is, like many other techniques, it's a very literal term. Spatial partitioning, in the context that I've learned it, is the process of identifying areas of an in-game world to be rendered using a specific process, thereby increasing the performance of the task. In a 2-dimensional world, one of the most common ways of partitioning is via  a quadtree (See example below).

A quadtree begins with a grid of large nodes. If these nodes are empty, they shouldn't need to be rendered and can be left out, if there are objects inside of the node, the node will split into four smaller nodes, if there are objects inside of any of those nodes, the node with the objects in it will split again, so on and so forth down to a specified level. And so now, your computer can now focus on rendering the nodes with the objects within them, rather than updating al of the nodes at once. This saves the computer a lot of time, and is very commonly used.

In 3-dimensional space, the quadtree equivalent of this is an octree, which is the exact same concept as a quadtree on 3-dimensional sacle, so all nodes are cubes, etc.

Spatial partitioning is a good way to save performance in games, and I plan on using it if I can within my own project, given I have time do learn how to do it in the language I want to do it in.

 

Tylah Kapa

Loud Pipes, the Learning Platform

I''ve been kind of criticizing myself as a programmer. Looking at other programmers and seeing that they know what they know, how easily they can problem solve and the amount of languages they are proficient in, I can see that I'm pretty far behind. 

So recently I set out with the intention of learning some aspects of a new language just to say that I had that ability. I also wanted to make a discord bot, so why not? With help from peers I found Discordie, a node.js module that I could use to make a discord bot, and learn Javascript, all at the same time. Having only learned C++, and C#, both object-oriented languages, the concept of Node.js being event driven was relatively new. 

So struggling to come up with a name for the bot I rummaged around the internet swearing that I'll just use the name of the first song I see, and so thus Loud_Pipes was born. Before I knew it, I had pipes up and running and I was playing ping the robot with him. But that was just pre written code, I wanted to do something better with him, something that taught me somewhat the ins and outs of using JS while still being somewhat functional. 

Loud Pipes Example

So before I knew it I was embedding messages in discord in response to a command, learned about file I/O in JS, I learned about JSON and how that can be used to help me. Arrays and variables. While I was somewhat familiar with everything I was doing I hadn't done it in Javascript before. I was having a lot of fun with Loud_Pipes. With creating a discord bot in general, and I even got to learn something from it. Loud_Pipes can be found here.

 

Tylah Kapa

Stray Cat, Reborn

It's been a while, and so I'll start with "I'VE TOTALLY BEEN DOING WORK I SWEAR!". But really, that's just the surface excuse, the truth is I can't find much to blog about. However, today I come to thee with a topic of discussion. My implementation of A* in the bot from my last blog post, Stray Cat. Well, Stray Cat's spiritual successor, Aerosmith, Aerosmith's repository can be found on my Github here.

A* Path-finding Example (Gamelogic, 2014)

Aerosmith's primary purpose is to pathfind using the A* algorithm (example above) to navigate around a closed off maze in order to find and destroy another AI with similar actions. Put simply, A* will attempt to find the shortest path from the starting node (blue squares) to the finishing node, avoiding walls (black squares) along the way. The way this is done is by searching through the adjacent nodes available to the bot, calculating which one is most suitable for the path, and then tells the bot which node is most suitable from the node the bot is standing on. The algorithm will do all off this in advance, and so the only thing that the bot needs to do is look at the most suitable node and travel to it. Boy when it's watered down like that it almost seems simple to implement.

To be honest I kind of underestimated this task, all of my classmates did, and that kind of sucks because we couldn't fight our bots because we didn't have proper logic implemented. But now that I have an idea of what it's like to implement basic pathfinding on a 2-dimensional plane I'm pretty excited to see what I might be able to do with it. For future projects it'll come in handy, no doubt. However, because I can only really complete small projects, it's best to hold off on trying to do it in a 3-dimensional grid for now.

 

Tylah Kapa

Stray Cat, Act 1.

So rather than doing game-development projects, I've been assigned the creation of an aggressive AI that is intended to fight in an arena with other AI made by my peers in class. The bot will be written in C++ and I can do next to whatever I want with this bot so long as it is within the limitations of the program that we're using. 

There will be two separate tournaments on two separate map layouts. The first is on a barren field, wherein the bot can do whatever it pleases without much worry of path-finding. The next is a maze-like map wherein the bot will need to be more refined, and able to path-find in order to be effective against the enemy bot.

 I've made a repository for the bot that I've created (Stray Cat) here this repository contains the assets needed to make the program run, including the VS projects that you can manipulate. 

In the very first bot tournament, Stray Cat came in fourth place, and while I'm happy with that result. I'm unhappy with the amount of code that was needed in order to do this. I feel like it was too little code (original at the very least for how well it actually did).

The written form of Stray Cat was to 'randomly' move to a tile throughout the barren arena, whilst scanning for the enemy in a clockwise fashion. If an enemy was seen, calculate the enemy's potential future position, and fire four bullets at it, before returning the scanning again. Repeat ad nauseam until a result is reached.

Moving into the maze layout, the pick a tile and run strategy isn't going to work. The bot knows where the walls are in the maze, and so a more sophisticated path-finding algorithm/technique and looking technique will be required. So looking into that will be required for the near future. Once I do something cool with it, Stray Cat Act 2 will be born.

 

Tylah Kapa

 

 

Vektor Maf

Vector math is one of the first and probably most important topic that I covered in the first week, as vector math will lay down the groundwork for a lot of the other mathematics I'll perform throughout my career. Using these planes to describe direction and magnitude, or a vector, particularly within a three dimensional space, is something that I feel particularly comfortable with.

Describing coordinates according to world space, space relative to an object or relative to the camera view is an easy concept to understand, though finding out when I should use which space is likely something that will simply take getting used to.

I'd like to use the information I currently have in order to create a small 3d Vector mathematics library that I can use in the future if it's good enough. It should be relatively simple, though just implementing hard coded formulas that perform in the same way is definitely very easy, perhaps I'd be able to find a way to make the functions within the class calculate using the different spaces?

It's something that I'll probably have to explore a little bit more while creating the library, and then report on what I've done in the future.

 

Tylah Kapa

The First Week Back

Well it's Monday again, and the living's easy.

It's been one action packed first week back, that's for sure. Laying down a framework, expectations, learning new things and going camping. I finally have a small chance to gather my head and organise myself.

So for studio this trimester. I, as a programmer, will be separated from the designers in my cohort, as we begin our specialised learning. Up until this point, designers and programmers had about the same amount of knowledge, but now that we are separated we now have a chance to study techniques and problems unique to programmers.

One umbrella term for one of these techniques is Artificial Intelligence programming, AI as it's commonly known. AI is a very common thing I'll have to program throughout my career as a programmer, be it for enemies or allies in a game, or perhaps even something completely unrelated to games, though I doubt I'll ever stray too far from the path I'm on right now.

I've already made very simple AI before that just takes points in the world that the enemy should move to and moves to it. But I never felt like I actually ever learned how to properly program AI, and now is my opportunity to do it.

With this comes some new mathematics and programming techniques I'll learn, these include Vector math, particularly 3D vector math, Matrices, and creating a mathematics library for ease of use and deeper understanding. Using things like pathfinding and finite state machines effectively will come when they do.

Though for now, that's about as much as has happened in the past week. A more in-depth blog about matrices and vector mathematics and their applications will be coming up soon.

 

Tylah Kapa.