"AAA"-quality 3D renderer announcement

After months of decisions and coding, I finally arrived at the 3D renderer for the game.

It's no longer a RogueLike as before. People didnt seem at all interested in ASCII graphics. So, its now a proper 3D landscape that the player can walk around in.

The image above is from inside the game.

More images expected soon as well as possible videos showing the game in action. Until then, post comments please for more information.

Devlog 2013-10-20

Here is list of the development activities for the last two weeks:

Networking

I rewrote the network code and ended up with a new UDP server. It's still based on async callbacks. The problem I had to solve, which is now solved by the way, was to be able to remotely identify the client which had logged in.

I also wrote a new UDP network client, that I integrated into the game engine. As my time continues to be limited on this game, I was only able to automatically get the game client to login to the server with the main game screen started (not the main menu, but the screen that is shown once the game starts for real).

ISO 7816 protocol

I wrote a message protocol based upon ISO 7816 in a few hours last week. To test it, I needed to further code a simple message broker application, similar to a message bus, in order to create a message and add it to the broker. I used custom attributes in C# to decorate messages for identification, similar to this:

[CLA="0xbb", INS="0x74"]
public class Message74 : IMessage
{
     public ICollection<NanoCommand> NanoCommands { get; set; }
     ...
}

There is much more code than this, but it shows what I was doing. Inside each message, is a collection of nanocommands. Nanocommands are widely used in ISO7816 packets, and I thought I would do the same here.

Code Rewrite

Even though SurviveRL is at v0.06a publicly, I think I want to rewrite the engine. A code metrics check shows it isnt too complex, but the line count is now at 6,000. Weird, when the only visible stuff for players is a bunch of "M"s and a "@" walking around on a simple ascii terminal. The reason is that the code is there for many things to simply be activated or scripted in, when I get the time.

Still, I think a rewrite of the engine could be better done now, before the code starts growing. I want to get the network code, protocol, and kohonen AI stuff in place properly. If i'm going to do something unique for RL or other genres, it needs to be done right from the start.

Feedback

Announcing SurviveRL almost from the first line of code, was a reality check for me too. I didnt want to sit a year in darkness, code this game, then release it for free. Only to find out that the game was boring, or this or that.

No, coding together with people to give ideas was what I wanted. What has happened though during four months, is the opposite. I blogged, wrote forum posts, Reddit, YouTube, RL community stuff, IRC chatting. Plus the game is free to download and try out. Nothing really happened. Desura declined the game too.

If I look at another project I coded, with some friends - TechCraft (techcraft.codeplex.com). A much simpler code base, but graphically something to look at. This went on to be the base for a few high profile indie games on PC and Xbox360.

Moral of all this: don't expect people to be interested in something becaue you are, even if you can code it for people. And if it doesnt have graphics, its probably going to get one player: you the coder!

So, I'll be keeping references to SurviveRL online, but will from now on code in silence on the various parts of the engine. A game that I want to play, but maybe not for others. Feel free though to contact me if you are interested in the game announcement, and want to get a copy of it from me. When I get to v1.0, I will release it publicly for free.

At the end of the day though, I've ended up with some resusable code in a game engine. Engineering it with numerous design patterns still remains great fun, and it's always a good feeling to start up the client and play.

Devlog 2013-10-02

Devlog 2013-10-02

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


Network & Multiplayer
A rewrite of the experimental code is in progress. I had managed to get the
client to login to the server, and the server issue its ticks to the client, wherein
the client would receive those.

Tests done showed that the implementation works as I had hoped, so all that is left
now, is to continue to code on this new implementation.


What's planned this week
I'm hoping to continue with the network coding. My freetime is very limited though at
the moment, where i'm averaging around 5 hours a week max on this. It's only short term
though, and I should be able to increase on this in 2 weeks.


Something to read
Blog posts shouldn't always be boring, so i'll write a few lines on the subject of
roguelikes, namely on the use tilesets and tile renderer clients for roguelikes. Berlin
states that a roguelike should represent its world as ASCII characters on a grid, which
is where I am with SurviveRL. But, some of the major RLs and Android RLs (plus those on
Steam) use a graphical frontend.

I sent a request to Desura about a month ago, to submit SurviveRL to the service, just based
on the ascii client. I was merely curious to see if the submission process would take
the game, based purely on its criteria for upcoming game features. Naturally, this game
was declined in submission. The reason? well, in summary that the game doesn't seem to be
something that people would want to buy.

How do we define a buy decision then? Roguelikes are a respectable game genre, with fantastic
replayablity, but decidely low graphic display content. If I were to move SurviveRL away
from a Berlin definition of a roguelike (ascii display) and make a tile based graphic client,
and submit, would it change the game? No. The game would be displayed in a different way.

I read a recent reddit post asking for a list of current roguelikes on Steam. Interestingly
enough, *ALL* of them were using graphical clients, not ASCII. How much should we RL devs
stick to the Berlin definition? Can we still class our games as roguelikes if we use tile clients?

I will battle along in the engine code for now, and get the roguelike to an enjoyable play state.
After that, it's a question of numbers: to reach a larger client base, it probably needs some
eye candy, and then, can I still call the game a roguelike?

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.