Trends in 2017 Web Design

The world wide web is home to many great (and not so great) websites, and most everyone is racing to find the best way to providde a fresh user experience, while remaining clear and clever. So what are some of the better ways designers are doing this in these contemporary times?

Upon doing some research on the great Google.com I found Awwwards a website that seems dedicated to ranking designs for usability, creativity and content. Whilst browsing for references, an article posted earlier this year talked about the uprising trend of asymmetry stating "2016 also broke the rule of symmetry, which dominated the industry for quite a long time." (Merixstudio, 2017) Flipping through some of the freatured designs on the site. Many of the examples, such as Meskie Granie, Melanie-F and NUBIKK use these full-browser canvases as the first thing you see. Normally combined with nice typography or imagery in the case of multiple sections, then seemingly smooth transitions would be used whilst scrolling between them. All whilst upholding a uniform colour palette and typography.

One website that used this kind of style really well is Kenichiro Arai's personal website. It might be intentionally mediocre, but The Worst Portfolio Ever, were it a rreal person's portfolio might be able to benefit from a design like Kenichiro's. Even my own website might benefit from it as well (provided I get better screenshots of my games).

 

RefereNCE ARTICLE

Merixstudio. (2017). Web Design Trends for 2017. Retrieved from https://www.awwwards.com/web-design-trends-for-2017.html

 

Tylah Kapa

Prototype Post-Mortem: GC:SO

Introduction

Gunmetal Crusader: Star Overdrive is one of the first long-form projects that I’m spending my time on. As one of the first Virtual Reality projects for both myself and my team, there is a certain dread and excitement we can’t help but feel as the game progresses. We’ve proven that we can we have the ability to make this vision come to life, though if we want to, reflecting on what’s happened over the past six weeks or so is a must.


The Bad

Of course nothing is always rainbows and sunshine, there’s a lot of ups and downs when it comes to working with a team of human beings, especially when you have to wrangle them up like I do in my role as Project Manager. Some of the most major things I noticed going wrong with the project were partially my fault.

In the early stages of the project, there was a period of time wherein a lot of people did a lot of work, and unfortunately, not all of it got logged. There were some aspects of Project Management that some members of the team had misconceptions about, and therefore expected me to personally log all hours of work they had completed, even if I assigned those hours to be working on something else. Productivity is great, but I’m a busy person, I can’t be doing that on top of my own work. Everything was sorted quickly, and the members of the team were forced to learn how to use HackNPlan to log their extra hours. Though this could have been avoided, in the future I, as Project Manager, should let all members of the team know that they are able to log their own hours should they find something that needs attention. Conversely I could ensure that everyone has access to log tasks individually with my Project Manager.

There was also a point in time where tensions rose within the team, where I, as Project Manager, decided to test the team to ensure they were regularly checking the HackNPlan. This was done by going through and assigning tasks according to importance as normal, but not telling the team that it had been done. Needless to say this fell flat on it’s face, with the team rising in anger come Saturday when nothing had been done, and I had hinted that tasks were assigned the entire time. I’m obviously not entirely at fault here, of the four other people in my team, none of them decided to nonchalantly check the HackNPlan for that week. This was something that was addressed quickly, I would let people know that tasks had been updated, and give a quick rundown rather than the paragraphs I was writing beforehand. While checking tasks should be a regular thing for everyone on the team, a little reminder never hurts, and in the future, I’ll be sure to send them.

Workflow within the team could have been much better. Upon surveying the logged hours spreadsheet, it was immediately obvious that workflow was not consistent for everyone in the team. There isn’t a ton that I can do to force people to do more work, particularly if they’re going through personal issues as members of the team experienced. I also hate pushing people to do work if they aren’t in the right head space, I know that I would hate it if someone did that to me.  Therefore I find it difficult to assert myself, and tell people to do work. Hell, even I experienced some demotivation at points within the past few months, though it never stopped me from tending to my duties. As a long-form goal, I’d like to be more assertive as a project manager. I don’t feel like I’m doing a good job of being a Project Manager right now. I’ve come to believe this is because of the lack of work I saw at point throughout the pre-production phase. Though if in the future I can assert myself, or raise morale in the team somehow, I think that it would just make me that much better.  


The Good

But nothing is always so dark and dreary either. There is green grass on the other side, I promise. It never ceases to amaze me how far I’ve come, both as a Programmer and a person. After completing their first VR project, I hope that rings true for the rest of the team as well. We can ride the wave of completing the prototype rather far into the true project, I feel, and we can make it even better.

Like I said previously, there were some ups and downs in work flow for the prototype, and that might come down to clarity or understanding of tools. However, things can run so much more smoothly when people follow a set of guidelines. Things like Git Flow, coding standards and accurate documentation really helped out a lot, particularly when there were members of the team who hadn’t worked with VRTK previously. As a Project Manager, having an established set of guidelines to refer back to can only be a good thing as long as they’re actively being used and enforced. The most obvious of these is simple code standards, as a lot of issues could be solved if that one line were commented, or that function didn’t look like a variable.

I feel that I’ve progressed a lot as a programmer in the past year, I’ve said before that it never ceases to amaze me, but it really never ceases to amaze me. In the past I’ve taken steps towards learning new languages, but recently I’ve switched over to learning better game development practices, particularly in Programming. Commenting my code, summarising classes, looking for a better solution to code I’ve already written is something I’ve been actively pushing myself to do, and it feels really good to do. Even better when someone else can easily understand what to do with it. Taking tools like Git commits, comments and documentation seriously and written concisely can help everyone in the group understand what is going on. I’d like to challenge myself to uphold these practices actively, and challenge my team to do the same.


Conclusion

Overall, the prototype was a success, given its ups and downs like every other project. I thoroughly enjoy working on Virtual Reality games, and I might even be tempted to work in the industry as a VR developer in time. There’s a lot left to do on this project, and I’m confident that this team can get that work done. We’re a lot more comfortable now, and I want to see a solid workflow coming from everyone in the coming weeks. We are exhibiting the prototype build, and I can’t wait to see how people react to it. This project is something I’d like to see on Steam one day, and I think we can do that.

 

Tylah Kapa

A Tri in Reflection

Looking back, it never fails to amaze me that only a year and a half ago I knew nothing about Game Development, nothing about programming and game engines or design. It feels great to see how far I've come in such a short amount of time. Making consistent progress towards becoming a professional Game Developer has made time fly, and I can't wait to see what's coming.

Over the past tri, I've only worked on two project consistently, with sporadic training mixed in throughout. I focused a lot more on improving my code's structure, clarity and efficiency rather than branching out and learning more languages. This method, while specialised, is allowing me to learn techniques that I may be able to apply to other languages, and most likely accelerate my learning of those languages as a result.

The project I've been mainly trying to improve myself on is called Flow.  Like I outlined in Flow: A Reflection, the project management on the project wasn't the most amazing, and so I simply took it as an opportunity to provide for the team while actively attempting to improve my processes. This included writing a quick summary, actively commenting, following code standards and making the script concise and accessible. There are likely some improvements that could have been made, but sitting down, considering options and programming things that work first attempt feels really good. Seeing people look at and understand your code is also a huge plus, and helps out the team a lot. When fixing bugs in other's code, I would comment what I changed and on the handover tell them why. While I didn't get many opportunities to work with the others as a team, I feel that I played a substantial part in getting the project to it's current state, satisfactory or not.

One aspect of Game Development that I've taken a very large interest in is Virtual Reality. I'm acting on that interest in making a Virtual Reality game as my first long form project, Gunmetal Crusader: Star Overdrive. I feel that Virtual Reality is a very interesting platform as it is yet to really bloom as a platform. It's challenging me to take on new techniques as both a programmer and project manager and think about games more as the player. I think that as a project manager, I still have a long way to go. There's some aspects of my managing skills that I'd like to improve, things such as time management and communication, of course there are aspects of the team that I'd like to change, such as motivation and/or diligence and productivity. I've noticed that my team relies on me heavily to tell them what to do, and log their work for them, and I simply cannot do that for everyone. As a programmer, Virtual Reality challenges me to think differently, I've found that VRTK is an awesome platform to dive into VR from.

Aside from that I've become intrigued by shaders and game art, textures, modelling etc. After seeing some amazing examples of shaders from Joyce[MinionsArt] I've been inspired to learn more about shaders and what I can do with them. They're awesome, and I can't wait to start testing out shaders more thoroughly in the future.

But it's been a long, and difficult time with a lot of ups and downs. I lvoe to improve myself, but I also want to get something done that I can be proud of, a product to see people play that I don't feel is underwhelming. But I don't have to rush, I guess I'll get there in time.

 

Tylah Kapa

Flow: A Reflection

Introduction

It's been a while, and for a lot of the time I've been away, I've been steadily working on a project assigned to me from a contractor as a part of my course. The project, Flow, as it's called, is intended to be a learning tool for Audio students to be a gateway into Signal Flow sessions, as it's a crucial part of live and recorded sound... stuff.

I cannot confidently say whether or not this project was a success, because I never saw the client I was working for directly. Our team was separated into Game Designers and Game Programmers, and the Designers had the only interactions with the client, and would liason with the Programmers to tell them what to do. However, from what I've seen of the project, and what I know of the state of the project, I'd like to think that this was a project very close to becoming something successful, but sadly fell short.


The Bad

So why do I think it fell short? Well I'd like to say it's a long story, but it really isn't. There are a few reasons, however, in the interest of time I'll cut them down to the key. The primary reason was a lack of communication, both between the Designers and Programmers, and the team of Programmers I was with, and a lack of productive work coming from the Programmers.

From the very start of the project, we were told that only one member, the assigned liaison, of each team was allowed to communicate with each other, and act as the only point of contact between the Designers and Programmers. So as to keep confusion down to a minimum. Trying to create a plan of attack for a game about Signal Flow, informed by Designers whom had learned about Signal Flow only two weeks prior, with only one person communicating to the other was a terrible start. Documentation and clarification was lost in a mix of terminology, and the Programmers never did have a solid idea of what Signal Flow actually is in terms of Audio. It would have been so much easier were the Programmers to attend the sessions wherein the Designers learned about Signal Flow, that way we could have learned about it together, and started with a mutual understanding of what Signal Flow actually was.

There was a very clear lack of motivation from the Programmer team as development on the game started. Avenues of communications weren't opened up by any member of the (Programmer) team, and a form of project management was never truly put into place. In fact, I don't believe that I was ever actually assigned a task by our project manager. Instead, I worked on what I knew, and the guilt that the designers had to show something to their clients the next week to create a beginning back end for the primary mechanics of the game. Overall there wasn't any real direction for me as a team member, and instead I had to shoot in the dark. Were I not already a project manager for a different, long-form project, the I would have stepped up to take control. However, my working on the back-end was enough of a wake-up call to the rest of the team.

Another clue pointing to the lack of motivation was the lack of quality code coming from the team. As the creator of the back end, I intended for my classes to be inherited from, however, the team altered the code and created their own stuff. Of which, whenever there were bugs I was assigned to fix. This would never usually be a problem, provided that the code is succinct and clearly commented. There was a case wherein a function I had made had been extended fifty lines without commenting. This was mildly infuriating, and I was to waste time fixing uncommented code I didn't write rather than working on something that needed doing. A lack of coding standard is what I've noticed, as I strive to better my own programming (keeping to a standard, actively commenting, designing to be modular), I've noticed more and more how lazy some programmers can be, and just how much it can affect progress on development. Unfortunately I can only tell people to follow a structure and comment actively, unless you're actively trying to better yourself and your code, then you'll fall back into a routine.


The Good

But it's not all uphill, because what you lose in team communication you can make up for with personal progression. While I admit that I didn't do as much as I could have to help the team out, I made sure that no matter the outcome of the project I, at the very least, progressed myself and my skills as a programmer. 

Like I said, there was nothing assigned to me at any point in time for the duration of this project, and a very damaging lack of communication between the team(s), therefore I took it upon myself to get the team started and make  a back end the could serve as a base for the core mechanics of the game. Quite frankly, it saved the project, there was only one person working on something else, and what they were working on required the core mechanics to be made. It didn't make a ton of sense. I don't want to ever feel like I'm being forced to take a step forward because of my team, and I also never want to let anyone relying on my work down. But the team cut it too close, and I had to say enough is enough.

Bouncing off of that point, there came a time where the basic scripts that I made weren't enough to keep the project progressing, and at the same time, the team had already altered the scripts and created a bunch of dependencies from them. It was all incredibly inefficient, and trying to fix it would take far too much time. Therefore, I instead iterated on the previous scripts in order to create something that satisfied the basic needs of the project, make it more modular and a lot tidier. While I didn't enjoy it, it did feel good to visibly see the improvements on my own practices, and provide thhe team with something they could use even easier than before. It's always good to go back and rewrite things, because you might have a much better understanding of the language you're using or you might find a way to make a function more succinct, there’s a challenge in it, and it makes you feel a lot better when people aren't using something you hacked together.


The Takeaway

Aside from the basics of Signal Flow, there isn't much that I can say I particularly learned from this project. Because of the poor communication and lack of tasks, I primarily spent the time progressing myself and my practices, while accepting any bugfix work given to me personally, and working on bettering some of the scripts in the project. There isn't much you can learn from others if they aren't willing to take the steps to communicate to you what their code does, or improve it's structure. While it was frustrating that this project didn't turn out as great as I'd hoped, I do sincerely believe that if I hadn't taken the steps that I did, it could be much worse. 

Tylah Kapa

Shader Talk

It's been a while since I've had an opportunity to post a blog. But don't fret. I've been having some fun looking more into aesthetics rather than generic gameplay programming. So shaders, modelling and texturing. I must say that taking a step back from the text, and getting into more artsy stuff is awesome, it's refreshing. 

I've been interested in shader for a while, but the game dev Joyce[MinionsArt] had some really cool stuff the put my interest over the edge. Therefore I tried to replicate some of the stuff She did using my own vertex shader.

 Grass Wind Sway

Grass Wind Sway

It really opened my eyes, even the most simple aethetic effects might take more than one might think to recreate. I decided to try to make a kind of 'nature' shader. One that can replicate grass physics. Though for a first try, I don't think it's that bad. 

The way I started out was by shimmying the gass sideways using a simple sine wave, using Cone Wars' dev blog as a reference. So now I had a bunch of synchronised grass dancers.

The next step was to desynchronise the grass and dampen the effect. The way I ended up doing this was by sampling a perlin noise texture using the objects world position, and used it's colour value to increase or decrease the rate at which the grass swayed. I also then created a grayscaled gradient which I sampled with the uv coordinates of the current vertex and used it to dampen how much the grass would sway the further from the base it was. This easily created a somewhat realistic looking wind effect on the grass. 

Needless to say I felt pretty good after some optimisations and tweaks, but just to satisfy myself,  added 1 to the sine function, which would make the windflow more uniform / look like the wind is coming from one single direction. This can probably be set as a parameter for customisation.  

 Grass Trample Effect

Grass Trample Effect

One of the bigger things that I wanted, and made this shader for was to trample down grass, or part grass as an object walked over it. To be honest, it's an effect which I find really cool if simple. While it's relatively janky, I think that the end result looks  pretty good, and it wasn't too hard either.

The first thing I had to do was grab the world space coordinates of the object(s) I wanted to track. So I made a separate C# script with a reference to the player character and fed it's Vector3 position into the Shader parameters. From there I grabbed the difference between the grass' worldspace position and the player's world space coordinates, giving the direction that the grass would bend in and normalised that value. I then multiplied the direction by the maximum of 0 and the bend radius - the normalised direction. This results in a small band around the player that will be manipulated, as seen in the Gif above. 

That's all. That's literally the extent of it. It's something that looks relatively decent and only manipulates the vertexes of the meshes, leaving a fragemnt shader free to do it's thing. This entire vertex function was about 10-12 additional line of code. I feels awesome, and it's all maths from here. 

I had fun doing this, and I really want to get more into technical art stuff. So I might be a bit more active as I learn Blender and all of the jazz.

 

Tylah Kapa.

Where ya been? Whatcha doin?

Dead.

I've been REALLY dead over the past few weeks, and it hasn't been fun. 

Well actually I've been working on that somewhat secret project, I just needed time to work on it, and get it approved. Which it did hooray, so now I can be more open about it and start posting dev blogs here and have a website up for the team to use.

So this project is called Gunmetal Crusader: Star Overdrive, and the short rundown of the game is you are a pilot in a mechanised suit (a mech, kind of like from Avatar or Gundam), fighhting off a horde of hostile 'Androids'. The team strongly believes that if you're familiar with, and like titles such as Killing Floor, Call of Duty Zombies, Titanfall or HAWKEN, then you might have something to look forward to in our game.  

GCSO is currently in development for the HTC Vive, and we plan on releasing to Itch.io within the coming months. So what I've been doing alongside my team for the past few weeks is designing, prototyping and expanding on this idea, getting awesome soundstracks as examples. In fact, I can give you a sample of the soundtrack we'll have now.

The team thinks that what our audio guy is doing is amazing, and we have high hopes for our soundtrack to come. 

We want GCSO to be a high-octane Vive game, where the player feels empowered, invigorated. We hope to accurately convey that feeling, and hope we do it well.

 

Tylah Kapa

Ground Control to Major Tom

For the past few days, I've been trying to get my head around exactly how networking works, and a lot of it is done using Windows Sockets or Winsock. Initially it was really difficult to wrap my head around. You have client and you have the server and they have to communicate with each other somehow. 

So this repository is the fruit of that time spent working it out. I must say it's pretty satisfying, even something as simple as typing ping and receiving pong back can fell pretty good when you do it yourself.

So I'll go through my version of how it works. The server will start, and bind a socket to a port. and begin to listen for packets from clients. The client will start and ping the server, the server will respond with an information request and the client can act on the request by inputting their name and password. That was an extremely simplistic description. 

So the way that data like a string or character information can get passed over the net is via packets. In a game like say, League of Legends, when you play that game, or you're even sitting in the League client, you will consistently be passing packets to the server and vise versa. Games these days use UDP, which is a protocol taken when sending these packets. UDP essentially means that you, the client does is not required to send and receive every single packet you potentially can, because that will slow down the game dramatically (and is what TCP does). So when these packets are received by the server or client, how can they transform them into meaningful data?


void ReadInType() {
    char buffer[10000];
    int readLength = sizeof(sendAddress);
    int result = recvfrom(sendSocket,
        buffer,
        10000,
        0,
        (SOCKADDR*)&sendAddress,
        &readLength);
    if (result == SOCKET_ERROR) {
        cout << "Result Error " << WSAGetLastError() << endl;
    }
    //Recast buffer as a packet
    Packet *p = (Packet *)buffer;

    //Decide which packet has been sent
    switch (p->type) {
        case 1: {
            PacketPlayerInformation *pp = (PacketPlayerInformation *)p;
            cout << "Server Received Player Information" << endl;
            break;
        }
    }
}

^^ Is how.

This is just how I learned how to receive and interpret packets. But it seems to work relatively well (apart from how monstrous this code can quickly become).

I'm not sure exactly what something like this could be used for in the near future. Obvously I'll use it in my career, but I don't know enough about it to make something like a game client or anything.  I was tossing the idea of making a MUD around. I'll try to have a look into it somewhere in the near future.

 

Tylah Kapa

Vita-lity

There's been a lot of great games on the PlayStation Vita, though I haven't played many of them. Just Atlus' awesome Shin Megami Tensei games, but it's really got me thinking about what the PS Vita might be capable of.


Sony has generously laid out a list of specifications just for me, and so I'm going to be using this list as a reference in this blog post. I'm not actually sure about exactly what restrictions might be placed on a programmer depending on specific hardware, though I do have a notion of the effects that different CPU and RAM can have on the way you approach different tasks. Which is why I'm going to start with that.

The PS Vita has the ability to support a plethora of game engines, including personal game engines. Use of different game engines would also, of course, mean that you are able to use different languages to develop for the PS Vita. When it comes to RAM, the PS Vita has 512MB and 128 MB of VRAM. This can be a lot or not much, depending on the project you're working on. Personally, upon seeing this, I would likely immediately decide to work with an engine that uses, or create my own engine in C++. C++, of course, gives me greater control over where data is stored and passed to and from. From a technical standpoint, this amount of RAM would also decrease the size of assets like texture resolutions and the amount of polygons on models etc. Of course, that's in games, and programming software like a store or something I would be less stressed about data management, though it should still be an aspect programmers should be worried about when it comes to Vita development.

Given the fact that the PS Vita only has a total of 2 GB of internal storage, putting aside that which is reserved for OS and native software, that isn't much. Though the user does have the ability to purchase an official PS Vita memory Card, which still range from around 4 - 64 GB. Though you can't rely on storage being the same all around. So unless you're using a game cartridge, minimising executable size should always be top priority.  Which again, would urge me to use C++ rather than C# or something of the like. And alongside the decision of language also come the restrictions of that language.

If I move onto the CPU I see that the Vita is running an ARM Cortex-A9 core which is a 32-bit processor primarily made for mobile phones, with 4 cores. From the looks, this CPU has 16-64 kb available for cache storage. Which if used efficiently can increase performance quite a bit. But if I talk about something I know something about... Multithreading1!!11!! this CPU doesn't have hyperthreading, and so will not be able to work more than 4 threads at once, which isn't exactly a bad thing. With proper use, multithreading can milk performance out of the CPU like no one's business, and because the specs of the PS Vita is constant, programmers can code with absolute certainty that hardware setups (with the exception of storage) will always be the same. And so I can see hardware specific programming techniques being paricularly useful even for general use.

So that's about as much as I know how to analyse, if you can even call this analysis. I don't think there's actually much here but there are definitely some things to consider if you're going to develo a game for the PS Vita. While the PS Vita has the advantage of being a stable platform to develop for, it's a platform that one would have to be much more vigilant with in regards to memory allocation and over-using resources. 

 

 

Tylah Kapa

Imperfect Optimisation

So I've played around with optimisation methods before. But none of them quite like multi-threading.

So multithreading, if you don't know is a method of achieving concurrency when executing code. Since I started programming in C++ I've only ever executed code in a single thread, which makes life easier, and my executions slower. When multi-threading comes into the picture, it allows multiple functions to be run at the same time, concurrently, which can result in much faster results. It's definitely a useful tool to learn of, and so I decided that I should try to look into it.


#include "stdafx.h"
#include <iostream>
#include <thread>
//Print Foo and the result of the calculation below
void Foo() {
    float z = sqrt(55 * 2);
    std::cout << "Foo\n" << z << "\n";
}
//Print Bar and the parameter given
void Bar(int x) {
    std::cout << "Bar\n" << x << "\n";
}
int main()
{
    //Assign these functions to different threads
    std::thread one(Foo);
    std::thread two(Bar, 22);    
    one.join();
    two.join();
    std::cout << "Complete";
    return 0;
}

So above is a little test excerpt I found and wrote out just test and see what it did. Yes! It worked, rather well. It's extremely simple, and now that I have this representation of how to do it, I find it infinitely more simple to understand. Watching the results this code could produce, I noticed that the results were not consistent. Th order in which the strings and numbers provided were printed were not consistent. Which is interesting and informative at the same time. It tells me that I should be careful with multithreading and where I used it. Becauuse results can come out at various times, I can't count on different rigs to produce the same results all of the time, and should not have any functions that rely on the multithreaded functions being performed before it is executed.

So here's my dilemma, I have a project that uses lights and raytracing in a scene to procude an image. Right now, on my own personal rig, I can render this one image in around 95 seconds. Obviously this is horribly inefficient, and so my job is to attempt to cut down that rendering time with a little bit of threading magic.

So attempting to do this by halving the screen's width and then having two threads run down either side, and this reduced the rendering time from 95 seconds down to 60 seconds! This is a massive improvement. Though, still intending to reduce this time. I attempted the same thing, this time splitting the screen into quadrants rather than halves. Then having four individual threads working on each half.

Click to view image

This worked surprisingly well, I must tsay that i definitely didn't expect it to be so much better. Now obviously the result of 30 seconds is still huge, and I'm sure that it can be reduced even further with things like quadtrees and slight optimisations in ccode and whatnot. Though I didn't expect to cut 2/3 of the fat off in one fell swoop.

Clearly there's still more I can do, though I think I'll wait until I attend my lecture tomorrow and see just what is up with multithreading.

 

Tylah Kapa

Quest for Dead

I'm back, and I come bearing great news, PROJECTS!!!!!!! yay. I'm working on a new project, and I'm in it for the long haul. So it might be a while, and nothing is set absolutely in stone yet. However, I'm going to be posting (supposedly) frequent blogs hinting at the research undertaken to work on this project. 

Without further ado, here we go.


In this GDC 2015 talk, Radial Games' Kimberly Voll shows how to build AI that aren't necessarily brilliant, but are certainly believable, in order to convince players that the world they're playing in is inhabited by compelling characters. GDC talks cover a range of developmental topics including game design, programming, audio, visual arts, business management, production, online games, and much more.

Less is more. Less is more. As someone who has only worked with relatively basic AI in the past, it's fascinating to hear that perhaps trying to implement these seemingly complex behaviours is something that might ruin a player experience. When I previously worked on my killbot used in the killbot tournament amongst my peers, I anticipated that my bot would place badly because all it did was run around on a whim, look for the enemy and if hee saw the enemy, he would fire exactly 5 shots at the enemy. Lo and behold that bot came 1st in a free for all, and 3rd in the overall tournament (I think). But now that I think about it, all of the top bots has amazingly simple design.


But what if you're not designing your artificial intelligence to destroy another ai? Or what if your AI is severely disadvantaged by not having access to the same gameplay mechanics as the player? What if they were per se 'zombies'?

If we look at Left for Dead, the generiic artificial intelligence for the basic zombie is to simply locate and travel towards the player and overcome vertical obstacles, if any. To this cycle of life, there are minute path detours that the zombie will take, or different climbing animations that the zombie will use to give the player the feeling that the zombie is an organic being, rather than a capsule in a video game. 

Less is More.

Left for Dead is famous for it's AI 'Director' which evaluates how the player(s) is progressing through the episode, and changes spawn rates of both enemies and items accordingly. The Director only decides when zombies should be despawned, and when zombies or items should be spawned and in what frequency, and is even turned off at certain points in the game, however the Director still receives praise for releasing or increasing tension on the player at certain points in the game.

So for me, the challenge still remains of actually implementing things like A* pathfinding in a 3-dimensional situation, and applying this artificial intelligence to it. This will take some time, and figuring out, though I'm fairly confident that with some practice, it should become fairly obvious what should be done in the coming months.

 

Tylah Kapa.

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.