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.

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.