Since Mazer Game Design and Network Security, I've been learning recently more about Network Security, now especially having to complete the assessments for some of the parts of the CCNA Security and CCNA CyberSecurity courses I've enrolled myself into. 

On the Cybersecurity side of things, we've done some pretty interesting learning around protocols as described in Mazer Game Design and Network Security. This has by far been the most interesting aspect.

I like protocols - I designed a simple named pipe IPC communications mechanism between a Windows Service and a .net application for Citrix's App-V implementation and while doing it, had to create a simple protocol. That started my interest in the broker pattern and I then designed a protocol for that project. I also used the Citrix Virtual Channels in The C# COM C/C++ divide which was basically a tunnelling protocol that you could send custom data to and from Citrix Receiver. I like protocols.

That said the aspects about Routers, Switches, Firewalls, IDS/IPS and some of the specialised security appliances out there is also interesting, and I guess if you really want to know about security, you need to know about the flaws and design of networks and their devices. I'm learning about network attacks at the various protocols and layers of the OSI model at the moment... TCP Syn floods, TCP reset attack, TCP session hijack, DHCP starvation, MIM attack, DNS shadowing, ARP Cache poisoning, DNS tunnelling and then the more common things like command-based attacks like SQL injection and XSS - that sorta thing.

On the CCNA Security side of things, this seems mostly down to configuring Cisco routers, which is interesting but there are a lot of commands to remember when setting things ups like SSH/SCP, users and role-based, ACLs and encryption. One of the things I've been interested in doing for a while is setting up a mesh of connected smart agents. To what end, I'm not too sure but they'd all work like collaborating routers, sharing path and route information between neighbours etc. One day...

Furthermore, I've learnt how to configure NTP, SNMP, Syslog, Routing protocols like OSPF(Open Shortest Path First), AAA and securing the data, control and management planes on a Cisco Router. It's fair to say that the CCNA Security course is mostly about practical application utilising Cisco equipment. One thing I do like particularly about Cisco is that they make great protocols.

In other news, I've already given the presentation of the game I designed called Mazer(see here), which was a creative exercise more than technical but still time-consuming all the same.

I've recently been working on the design document for Mazer. 

You can read my final game design document for Mazer here:

I've mostly finished it but it's taken a lot out of me, and I even stopped going to the gym and taken some time off. That said, I have managed to get out for my weekly runs. Not very long distances but just about the right distances to keep me sane. Here are my last few runs...

 This is one where I sort of got lost and ended up in Shoreditch park which was a lovely detour:

 This one is my 'left' route - basically, instead of turning right at the canal, I turn left.

Besides this, I'm Now working on a practical, technical prototype for Mazer...

I've got mixed emotions about this because while it's got a lot more programming involved, its a lot more rushed and I'm going to have to cut corners in order to get the prototype out in time. I think I'll have to realise that it's just a prototype - if I can't get the enemy AI done, then too bad, I can't develop an entire game in a week!

One thing I have really enjoyed about using Unity is the visual preview of some of the concepts I've learnt in the past around the z-axis, the local object space vs the world space and application of vectors(as forces) to rigid bodies.

I sort of poo-pooed Unity because it hides the complexity of game development, arguably it hides the tedious and time-consuming plumbing, and well game development, despite that is still quite complex. It has been quite enlightening.

It's also interesting because about 5 years ago when it first came out(Unity), I wasn't that interested in it, but the dev next to me at AppDNA had been playing with it and showed it to me...I looked at it briefly and said oooh-oooh and went straight back to writing my code (I was coding for a release). 

Though interestingly enough, some of that has actually got me thinking a little critically. For instance, as I've been working through my prototype (I've got a week to do it) and I've found that while it's easy to get some really advanced aspects of game development working for you like the physics, audio, mesh rendering and scene construction etc., I feel somehow that I'd like to be involved in how that actually comes to fruition. 

Obviously from a practical level, I've only got 1 week, so that's not feasible and that's probably why we've using a pre-built game engine instead of one from scratch and I'd probably learn that stuff later and its just good to be able to use the concepts and understand how to before delving into how to actually construct them from scratch. It's a bit like wanting to know how TCP/IP protocols and packets work as opposed to just sending something off to a Library like socket.Send() in python. Obviously, this is only because I'm interested(And I've done some learning around 3D), not because I absolutely need to know it - but I could argue that this is similar to using math theorems and not understanding the proofs.

I'll get over this when I'm given a game to complete and I need to engineer the rendering or physics components from scratch, in a week! 

Anyway with my prototype, I've managed to get the following concepts coded up:

1. Level Music and textured walls and assets including the fuel pickup
2. Fuel score counter and count down timer is rendered as GUI interface
3. Player animates with its own flashing siren on its head! It also moves. "It" is a robot.
4. Uses collision detection and triggers to resist player and detect dig/destroy wall action and collect fuel
5. The timer counts down and on destroying a wall, a time penalty is deducted from the time
6. Fail and Win music and ending of the game (stopping the timer, game loop and thus player movements etc)
7. Level is entirely autogenerated using a simple algorithm that randomly removes walls and each room is represented as a 4 sided square.
8. Random placements of fuel and player's starting position
9. As time ticks and fuel is collected, the score changes in-time as expected

It's not much, and it's moved on since this but it is my first ever game which is relatively complete, conceptually anyway.

I ported my 2D C++ for Mazer2D and so was able to re-use the concepts to create the game environment procedurally. I had to change the code a little because the coordinate system is different in Unity. It starts at the bottom right, while SDL starts at the top left. Not a biggie, just needed a bit of algorithm tweaking.

I won't be winning any design prizes for this, but you can't lose if you're not playing!

Since Game Dev, Forensics, Math and stuff, I've been thinking about what makes up a game's design... 

So, what is in game design?

There seems to be some established ideas that make up a game and these are the focus of most of the reading I’ve been doing around the subject and it essentially boils down to having fun - and anything and everything that influences it. I will try to formalise these set ideas later but for now I’d like to explore the concepts as they appear to me.

I think also, that anything that makes a player play longer is tapping into the right stuff. You might call this sensation an ‘addiction’ factor but when you think about it, you’re normally addicted to something because it pleases you or is necessary for you in some respect. A lot of this comes down to the player, the person who’s decided to buy your game and spend some of their time not making money or doing anything else but spending time for themselves. Its perhaps selfish but let’s make no mistake, its to entertain and for self-enjoyment. Nothing wrong with that, but let’s not forget this.

It's interesting to think how perhaps games might provide more than pure unadulterated enjoyment, like say teaching you about strategy and morals and perhaps leadership and commitments. These perhaps are things that games could be more than just about a casual, temporary and disposable enjoyment high called fun.

When I think about the games that I enjoyed the most, it was the sense of being in control and responsible for that control I think I enjoyed the most. In this way, I enjoyed real-time strategy games the most. The likes of Warcraft, Red Alert, Dune and StarCraft.

For instance, if you’re in control of an army and it's up to you to lead them to victory, you take it seriously. Why? Because I think you enjoy a newfound sense - of duty, but more than this, you want that duty, you’re engaged in this new idea that you’ve not practised sensing before. It pleases you.

Perhaps it is because you’ve not been a team captain before or been the alpha male or maybe it's just that you relish being in this now newfound position that you’ve not been in before and it's now so stimulating to be in it. That is a pleasing situation.

You might say that this is what fun is.

Shooting bad guys or zombies is not about being susceptible to gun violence or breeding the next pro-violence youth, its about providing a new experience, that which can inform the youth perhaps – leaving the gun-play in the virtual world because it becomes obvious that in the virtual world, you are a different person, which is why you are there in the first place and that outside the game, you’re not a rock ’n roll, gun touting madman(and there are police and jails on the outside to remind us that this is the case).

That’s an experience you can have in the game so you don’t need to try and have it outside the game. In CBT ie Cognitive behavioural techniques, you are put in a position to experience something so that you can learn more about it. I feel this is the same with gaming worlds and gaming situations.  Anyway, many will disagree with me but whatever.

In this way, providing new experiences to players is important. The other thing I think about when I play a game is the satisfaction I get while in-game.  This is one level up from the satisfaction of a new experience, this is the satisfaction of something happening in the game – interactivity and feedback i.e. the way it happens. I’ve read that they call these game mechanisms. I think having a cool weapon animation is cool, I like the way when the player runs, he’s weapon ways in front of him, or how a player can slip of a ledge but by default catch the ledge before plundering to his demise ideas – all satisfying, all game mechanism.

In Doom, the way the shotgun reloads with that pleasing ‘chuck-chuck’ while in time with the animation of the cartridges being reloaded by the player, it offers a pleasing experience perhaps because it’s almost real or because it’s been thought about by the developers and you appreciate that thinking. This might even touch on the subject of game-play, the way in which the developers have thought about how the characters move, how they do what they do and the smart ways in which you think they do it – all products of prior- thinking and you can appreciate that. Maybe that’s what gameplay is, the execution of thoughtfulness in the game.  

Same goes for storylines, in-depth well thought out storylines are much more interesting and appreciated than those so thinly smeared you can hardly taste them.

So, it helps to suspend this reality(now, outside the game) and allows you to be morphed and immersed into a new one. It's not about the violence, it's about the feedback and control that makes you want to see “what’s more, I like this let’s see what else there is?”. Some might even call that adventure.

Ultimately the game is there is please the player - its entertainment so anything from pleasing graphics to pleasing music all the way to how the character moves is a contributing factor to ‘pleasing’ the player. So, in this way, I think being pleased is fun and it is the key in may respects, in whichever way you can deliver it to the player within the game.

You can probably get more formal about this, and deconstruct the elements of fun and pleasing and for one, that might be a useful way to go about trying to ensure you’re representing as much as you can in a new game when thinking about designing one. 

Sure there is more to it than this, a game can be pleasing because of the rules, the limitations and the strategy. Probably a lot more too. There is a lot that makes up a game, including the graphics, physics and enemy behaviours and AI. All these things to me seem to be rooted as a derivative of pleasure or having fun.

Backgrounds, stories, artwork, gameplay and how games deliver their experience through their characters and in-play delivery such as rules, objectives all contribute to a pleasing experience.

Well-thought-out aspects of the game are pleasing.

So, in summary, I think I can best put it this way: Please the player and spend some time thinking about how to do that. Anything else will either annoy the player or have him reaching for the T.V remote.

Some texts I've read include these elements: 

• Having the player feel good about their own choices and being able to allow for multiple, non-trivial choices.

This one is quite interesting because there are so many aspects that you can please a player. You can appeal to their choices, their bravery, their ability and skill and even their emotions or strategies. But essentially these are all incarnations of making the player feel good about himself and the situation he puts himself into or you allow him to put himself into.

And the last bit is also key, allowing the player to represent himself as best as possible in the game, giving and allowing him to make the choices that he feels pleases him. If that means making it possible to colour in his boots, or grow his muscles or change his appearance, attitude or whatever in a way that more-closely puts himself or the person he wants to be in the game - be it real or pseudo, so be it.

In Morris and Rollings' Game Architecture and Design, this is represented as allowing the player to make and have interesting choices

Another interesting concept that touches on ways to please a player, is asking questions about what kinds of stuff pleases players in general. In the book x, it talks about human tendencies and instincts and that some instincts are inherently pleasing and thus should be capitalised on in games. These include the instinct to collect things and to complete things, protecting others, say those more vulnerable such as small children and woman (if you’re a man), the inherent fear that humans have of nature and I think inevitable the unknown, and our need for shelter. Another was inquisitiveness.

Manipulating these aspects and others could radically help you attract players by appealing to these types of things. There are no doubt countless others too.

• Interaction

I think this is about seeing your choices come to fruition, the feedback of it is how the game portrays it visually on-screen. So, Interaction and feedback is an important way of pleasing the player, or at least getting him/her involved or reacting to that feedback.

Another aspect it maintaining attention in a game is not distracting the player in the game from a pleasing experience, not annoying the player and maintaining a level of interest or fun. Perhaps this that what fun is, the maintenance of pleasure.

Here are some other keywords that come to mind from recent reading:

• Variety - keep things new ie make new experiences
• Encourage drive and exploration
• Involve the player, make him or her care about what’s happening in the game
• Drama and dramatics has many elements in composing an enrapturing experience
• Make it worth the players while to spend more time and more time
• Reward the player, provide progressively challenging levels and ideas
• Research what target market your game seeks to provide pleasure to incl. demographics
• You need to be different and have unique selling points to distinguish your game from everyone else’s.

There are some other things like how the game's interface is laid out and how if it contributes to the game in intuitive ways is more useful than just showing scores and health.

There seems to be a lot that can make or break a game and perhaps being cognizant of what they are is a useful approach, but doing too dogmatic might be limiting if you lose sight of the things peripheral that makes things fun and discount them altogether.

When I started writing this, I began thinking that you could be scientific about it, define all the elements of fun and be done with it. The more I think about it the more I realise that it is possible – you just need to focus on the things that support the player's pleasure sensors.

Coming up with that list of things is less scientific however and depends on how you determine what fun comprises of. And I think that like most things, anything you try to do, is possible if you put your heart and soul into it. Be that coming up with a scientific way to define happiness, game concepts etc.

Game design in general seems to me to be a constant narrative and reflection, an ever-growing discovery and thought process into what ways that might please the player.

I've spent most of the last couple of weeks tinkering with my forensics report that is due in September. I think I've managed to do enough to represent a decent level of ability to construct a forensic report and undertake a correct forensic investigation. Though I'm never surprised now when my expectations aren't always the same as reality when it comes to marking. I spend most of Saturday working on it. I'm somewhat relieved now that it's complete' however I'm feeling that familiar false sense of security now which inevitably follows with a surprise. 

I've gone to bed quite late recently in part to doing this report and in part to me wanting to do anything other than this report now that its finished (and hence doing whatever it is at the expense of sleeping!). 

I went to the library today and took with me my new-found gem, '3D Game programming Using DirectX10 and OpenGL'. This is exactly the book I've been looking for, it's technical, detailed and covers almost all the parts of DirectX 10. I've found that in my previous study, that resources tend to only explain the parts they are referring to and not enough about the context of the system in which are describing. I spend about an hour reading through various descriptions of the graphics pipeline. 

From this, I've been able to abstract from the detail (something I like doing a lot) the fundamentals of the pipeline. As a side note, I find it sometimes difficult to learn the other way around i.e from the fundamentals to the details(even though it sounds bizarre, there are times when having details is like options, the more you have the more you can choose what or what not to use in your mental processing of the subject matter). Anyway, the first interesting insight I gained was about the frame buffer. Essentially a location of memory that ultimately will contain the end results of the graphics pipeline and which will be shown onto a screen.

The resolution of the framebuffer is the number of rows x cols that represent the pixels. A framebuffer represents pixels and does so by describing them using bytes. The colour depth of the framebuffer is the number of bytes that is used to represent one pixel. Representing a pixel is more than its location, it includes its colour. So if 24bits are used to represent one pixel in the frame buffer, it is said that the colour depth of the frame buffer is 24bit. The resolution of the framebuffer is already mentioned but the number of bits thus of a 24bit frame buffer is cols x rows (of pixels) x 24 - which is a lot of bits and of course, a picture is comprised of a lot of bits then.

The other interesting insight I gained was a greater, more contextualised understanding of the DirectX grpahics pipeline, namely how and what the stages actually do. For example, the graphics pipeline looks like this, the output from one stage feeding into the input to the next:

1. Input-Assembler stage
2. Vertex Shader stage
3. Geometry shader stage
4. Rasterizer stage
5. Pixel shader stage
6. Output merger stage

The key aspect that I learned about the input assembler stage is that it 'assembles' vertices from the raw vertices as described by the vertex buffer's layout. Meaning that it takes your raw vertices, which includes the positions themselves and other additional information about each vertex like the colour and it sends each vertex it finds in the vertex buffer (along with the additional vertex info) and feeds it as parameters to the vertex shader, which now can act on that information in a programmable way through a shader program.

As part of this, the input-layout object is the description of the vertex buffer and binds the vertex buffer to the memory(input slots) in the input-assembler stage, so that vertex data can stream(actually referenced by pointers) from the vertex buffer to the input-assembler stage where it will be read/used as described previously. It sort of parameterises the vertex buffer data as input to a function, which is the shader program. Quite interesting really. 

Other interesting aspects of the input-assembler stage other than binding the vertex buffer to the input-assembler's memory is the creation of the input-layout object which describes and then is used by the input-assembler to tell it how to bind it to its memory. This, I think is why I enjoyed reading this book. It explains everything, the how and the why.

 Next, once the vertex shader has transformed the vertices is received (model transformations) from local coordinate space, word space, view space, screen space it sends off the vertices in defined groups of vertices such as 4 vertices to represent a quad, 3 to represent a triangle etc. And this was interesting because this is why the 'topology' is specified when setting up the pipeline - to indicate to the vertex shader to output a stream of consistent sets of vertices to represent say a triangle, line, quad. This is done by the vertex shader so that the next stage, the geometry shader can actually construct real, full primitives i.e actual triangles not dots that represent triangles(which is the input it gets initially) which are now what appears to be the metamorphosed result of dots(vertices) to shapes(primitives). 

The geometry shader thus deals with the primitive output which it sends to the rasteriser which turns that primitive into pixels. Reminds me of the phrase 'to build it up, to tear it down' because effectively we've used vertices to build up primitive shapes, only to tear it down into pixels that represent that shape. 

Now that the primitive, say a triangle is reduced to pixels, the pixel shader can colour those pixels in, hide some of them and then send them out as the end-result of the whole process, ultimately appearing on the framebuffer.

The other thing that I found quite revealing is how the DX API's prefixes gives clues into how you bind aspects of resources that you'll provide to the pipline to specific stages of the pipeline:

g_id3dDevice->OMSetRenderTargets(...) /* indicates that the output merger stage will output to your provided render target */

g_id3dDevice->RSSetViewport(...) /* which indicates that you'll bind the viewport object to the Rasterister Stage./*

/* The following are used to bind to the InputAssember stage:*/
g_id3dDevice->IASetVertexBuffers(..);
g_id3dDevice->IASetInputLayout(...);
g_id3dDevice->IASetPrimativeTopology(...) // which as i mentioned earlier, informs that a certain grouping of vertices will need to be outputted by the input-assembler stage.

 So all in all, a good session which I think will put me in good stead for my upcoming computer games technology classes.

I can't help but me mildly excited.