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.