Devlog 2013-09-19

Here is a run down of the activities acheived this week on SurviveRL:

Network Server

The large part of the week was spent developing the UDP server further. The server has the following added:

• Server Tick (http://www.counter-strike.com/faqs/tickrate/)
• Message Types
• Simple Protocol
• Broadcast

The tickrate is set primarily to 1000/60 milliseconds, to simulate a 60 FPS cycle for processing. This is enough I think to assume, even though SurviveRL is a turn based game. Message types were created to distinguish from client connectivity and standard game packet messages, so that basic login housekeeping can be maintained on connected players.

A simple protocol header was done to allow for the various message types. I will rework this for ISO 7816 T=0 protocol later on. Aim still for v0.07a is simply to have 2 "@"s walking around the same screen from two separate clients.

Aim for next week is to make some sort of sequence diagram over the login procedure and implement it between the client and the server. If time is available, also to send player position messages when the player moves on the screen.


Ogg Support
I also spent a short amount of time on Ogg support for audio. I will be adding in background music in v0.07a also, but not sfx, which I expect to add in during a later release.

Devlog 2013-sep-13

This weeks activities

Dynamic types into Content Editor

I spent the first part of the week adding in the reflection code for dynamic types into the content editor. This still needs work in order to populate the treeview dynamically, but the plumbing in the background as it were, has been done. More work on this expected in the following weeks.


UDP and Networking

A few months ago, I built a network stack in Unity3D, and used it in a game demo. It was great to control multiple players and watch them on each client. I learnt a fair bit about server game programming, server ticks and all of that.

The idea of making SurviveRL multiplayer has been like an itch on my back that needs itching. I have always been against in before, but as I kept relooking at Ultima Online these past few weeks, the idea of making this game multiplayer grew stronger.

Part of the fun with Ultima Online was the multiplayer aspect. With the amount of skills and items in the game, together with the crafting and vendor support, I dont think SurviveRL would be the same without multiplayer.

So, I spent a few days making the groundwork for a UDP stack. This is done. Expect multiplayer support in v0.07a instead of other stuff.

ISO 7816-3 as a Network Protocol

7816 is the standard assumed in smartcards. Part 3, has a great description of the transmission, especially the T=0 protocol (part 3.5). The Answer To Reset (ATR) is a prime example of identification without overcomplicating matters. Link: http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816-3.aspx

7816 can be applied to other areas of transmission, in particular data tranmission across networks. T=0 has a 5 byte hex header, a 255 byte data payload, an ACK, and a 2 byte response. It also has a single (0x60) procedure byte as a keepalive from the client.No compression is needed, as the protocol itself is efficient. Encryption of the payload is possible also, as it can be announced in the header. I spent years working with 7816, and couldnt find anything negative about it.

I will provide an example of how it all works in another post.

There might be other protocols better suited for network packets, but I like 7816, and using it as a network protocol was always something I wanted to do.

v0.07a

The next version then, will include 2 "@"s running around, each from separate clients interacting with a server. 2 is just a ballpark number. 100+ could be there, assuming there is space on the screen for each of them, and that your PC can start 100+ clients.

Devlog 2013-sep-06

It is time again for me to let you all know what i've been working on this week.

Content So Far
I have spent a large part of the week implementing dynamic data driven content. WTF is that?
Well, it means that I didn't want to make all these monsters and items inside the code, with all their attributes hard coded. I mean, I don't know at the moment, what and how those abilities or whatever will be in a year or so in the game.

Also, I didn't want to make some custom data format either. The data is all in nice XML still.

The content editor that I mentioned in my previous post, creates new content really fast. Much faster than having an xml editor, and figuring out the layout manually. It was a nice first step, but not what I had in mind for a release version. I went back to the design table. This is what I came up with:

Dynamic Data Driven Content
I managed to implement a way to use CodeDom to instance a dynamic type as a static type. I used the ExpandoObject. WTF is that?
Well, ExpandoObject is this neat thing in .NET 4.0+, that allows a coder to add properties to it on the fly. Like a propertybag (WTF: google that for more info). WTF is all that stuff about CodeDom and whatever? Well, it's a way to look into a program, after it's compiled and running, to see under the hood.

Once I move onto Expression Trees (which don't work with dynamic types) I can use my new technique to bypass this Microsoft issue. Then, rules (behaviours) can be dynamic too. Hopefully emergent behaviour in the game will allow the cloud AI to evolve smarter and faster.

Long story short, I can add any properties or attributes to monsters inside the content xml, and the game will use those properties WITHOUT being recompiled. So, if I have a game version 1.10, and i want to say add a new attack attribute to a monster, I can do that without needing to restart the game, the new attack attribute just appears.

What next?
Now that I have solved how to create new content without coding for all eventual properties, I can start to adapt popular game items and monsters (eg. Ultima Online stuff) into xml files. I don't need to worry if I miss out something now, I can add it in later, and it will not cause issues with the game code.

Another neat thing about this: I can procedurally evolve attributes onto monsters, morph them from one type to another, or even let the game itself create totally new monsters during gameplay.

Hopefully the neural network code I have for monster brains will allow special breeding more than genetic algos "survival of the fittest".

I will spend most of next week recoding the content editor to allow for self evolving monsters and content, and that I can use dynamic data read in from the content xml files.

Dev log week 35

This week has seen the following development:

Item pickup and drop
I added in proper item pickup and drop to the terrain. This allows the player to drop items to a stack of items on each tile. Also, any items in a stack on the ground can be picked up and placed into the players inventory.

Tile dig and fill
I added in the ability to dig up a tile (dirt, grass, sand, coal, rock) and have a resource of that type placed into the players inventory. I also added in the ability to fill a hole in the terrain with a resource from the players inventory.

Dig and fill now allows the player to reform the terrain. Once I add in more resource types, smelting, crafting etc, it will be possible to build castles, houses, structures, as well as flatten out land.

Content Editor
Possibly the best development activity this week. I created a standalone editor for content:

Content is stored in XML format. The editor allows me to read in the XML file, and easily add and remove new content.

As you can see in the screenshot, content is listed in the left pane, and its properties are editable in the right pane. The save button simply updates the treeview with the content model changes. The file menu is for opening and saving content XML files.

So, content creation will be extremely quick.

Comments now possible - please comment!

Heaven knows why Blogger defaults to registered users!

I wondered why noone was posting comments. Anyway, I found what appears to be a setting to allow anonymous comments.

Please, post a comment here to let me know that anon comments are now possible. Thanks!

SurviveRL v0.06a released

v0.06a includes:

• 3D ASCII terrain generator
• "Test Item" spawning throughout the landscape randomly

The terrain generator seems fine now. I'll keep it like this for a few versions, to get a feel for any tweaking or not.

The "test item" is the base for the reagent spawning, think Ultima Online. In v0.07a, I'll add in the code to display them.

It runs in Windows, OSX and should run in Linux if Mono is installed.

Download links on IndieDB or the Wiki

Kohonen SOM AI monsters

I put a forum post in the development section on Temple Of The Roguelike about this, which got a few replies. After which I decided to just take the plunge and add it in.

Kohonens Self Organising Map

Basically, it's a 2D array of anything which has been created and tweaked from an n-dimensional input source. Whatever that input is, or where it came from is irrelevant to the 2D array. What this does really, is just to organise the 2D array based on the relationships the inputs have to one another.

What makes it interesting, is that it does this fine tuning unsupervised. 

What I did so far

It's a neural network. So, I made a 2D array of 1000 x 1000 "neurons", which gives me about 100,000. That's about the same amount as all the neurons in a tiny ant. But, how those neurons in an ant are interconnected, I dont know. In my network, adjacent neurons are connected only.

I then gave this network a long list of 3D data to "investigate", or train. It took a while. But the relationships were always the same when finished. Sometimes, the start points might be different (the network doesnt know which is the start really).

So, once I could see the neural network code was working fine, I plugged it into my monster code.

What Next

I now have hundreds of monsters in the game wandering around with brains that can learn stuff. The monsters for now use A* pathfinding to chase the player, but once I switch on the neural network code and start using it, well, they will be smarter, and very difficult to kill.

Cloud Based

I use MEF (http://msdn.microsoft.com/en-us/library/dd460648.aspx) for plugins in the game. This AI stuff i'm doing will be moved over to separate plugins in a few weeks. After that, I will place it on some type of cloud service. I'll then link the training process of the AI from the game, back to the cloud.

As more and more people play the game, the cloud AI will learn. Players will be able to switch out the AI plugin anyway, so if it gets too hard to play, they can just activate a local AI plugin and ignore the cloud AI.

Finally, I will have a game that has an unsupervised cloud AI, where the monsters adapt and get better, as players get better. Who will win? I don't know really :)

One Last Thing...

There are hundreds of RLs out there, with all the wonderful things a RL is. Sure, I could spend 7 days to just whack in all that stuff too and make SurviveRL another one on the list. I don't see the point though. We can all keep playing those RLs for now, and keep monitoring SurviveRL as it develops into something of a hybrid RL. So, if enough people ever ask, I'll take 7 days and just hack in RL stuff. For now though, i'll keep on developing on a tangent.