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.

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.

Video: 3D terrain exploration

Here is a video demonstrating the 3D terrain as presented in v0.06a:

It is by no means complete.

What I am still investigating, is a method to display the various heights so that black areas (heights higher or lower than 3 levels from the player) of the various regions are accounted for too.

Also, I will introduce roads, rivers, structures and flora properly in the next week or two.

Once the terrain is generating nicely, I will move onto the AI in the game, and that brings with it things such as emergent combat behaviour for monsters and enemies, AIML for the NPCs and complex FOV and LOS strategies.

As it is now, the game looks boring and doesnt do much. But if you take the time to follow the dev progress over the next month or two, you will see it become something worth your time playing, and hopefully enjoy it too.

3D ascii terrain generation implemented

Progress for v0.06a

Up to and including release v0.05a, the terrain generator placed tiles randomly within each map region. Of course, this can make every screen look boring, as there wouldn't be any mountains, just a series of tiles that randomly change as you the player walk from region to region.

What I've done for the v0.06a release, is to use a terrain generator routine which isn't random. It's still pseudo-infinite e.g. it gets created during gameplay and has no predefined end. But the difference now is that a mathematical algorithm is used together with some other tricks to make the landscape more designed.

The end result is a great improvement. What you the player will see, is a landscape that appears as a contour geographical map. Areas of the world that are higher than where you are standing, are coloured lighter. Those areas lower are darker:

Water and Trees

If you click the image above, you will see an example of this. The blue area is water. The game shows terrain one level above your current level, and one below. Walking to a level lower than you, makes you drop automatically to it, and the game recalculates what new levels of the region you can now see. The same goes for levels higher than you: you automatically go up the landscape, and can see new areas from your new height.

So, v0.06a will add in an improved 3D landscape to explore. It wont be finished, but still, a better terrain generator than that used until now.

More status updates as usual throughout the week as progress is made.

v0.05a speak peek #2

Some more work done:

If I manage to add in a few more windows before Friday, great. Otherwise, expect this release in a few days.

Upcoming v0.05a UI sneak peek

Here's a look at the UI that should be released on Friday this week:

It needs a few more hours work, but has most of what was in v0.04a converted over to the new UI framework.

The game display window is now 64 x 32, so lots more to look at on each map position.

User Interface development

This week im busy adding in a proper user interface to the terminal.

It will allow me to create screens and windows within the terminal itself, so that the game can work similar to how Dwarf Fortress does with overlapping views that can be shown or hidden with keypresses.

Expect a new update (v0.05a) on Friday 9th with the UI in place

v0.04a (terminal emulator) available for download

New version:

- Added terminal emulator. Game runs in its own terminal, not the console

Check the wiki for download links at:  http://surviverl.shoutwiki.com/wiki/Main_Page

Stats and Keys added

Stats and Keys areas added to screen:

Starting to look more like a bit of a roguelike :)

v0.04a available to download and play within a few hours. New blogpost coming soon to announce

Game in terminal screenshot

So here's the game running in its own terminal emulator:

Keys are still the same. Selecting different fonts from the font menu resize the terminal properly. I like the idea of using a proper terminal emulator :)

Next step: Creating proper stats areas and combat messages area

Terminal emulator added :)

I managed to implement a terminal emulator into the engine. Here is a screenshot of the basic part of it:

What it means:

• The game will run in its own terminal, no longer the console window
• I can create proper areas in the game screen for stats, inventory, game area
• Fonts and tilesets can be modded
• New font sizes

Expect a new free version 0.04a to download in 1 or 2 days using this terminal emulator

v0.03a available for download

New version:

- Added combat

Check the wiki for download links at:  http://surviverl.shoutwiki.com/wiki/Main_Page

v0.02A available for download

New version:

- Added A* algo to monsters
- Updated keys: WASD, Cursor, numpad and Vi Key layouts all possible for movement

It still doesnt do much. Just walk around, and watch the monsters follow if you get too close

Check the wiki for download links at:  http://surviverl.shoutwiki.com/wiki/Main_Page

Note: The build runs on both Windows and OSX:

Windows: just double click the .exe
OSX: Use terminal, and cd to the unarchived folder. Then use "mono SurviveRL.Console.exe" to run the game.

New Keys

I've changed the keys, in preparation for tonights new release with monsters chasing the player.

Check the following link for many of the new keys:
http://roguebasin.roguelikedevelopment.org/index.php?title=User_interface_features

A* implemented

I've spent a few hours implementing the first parts of monster AI.

Monsters on the same screen as the player, will look for the shortest path available towards the player.

The red path is the pathfinding from the monster to the player.

From another point.

Technically, I implemented the A* algorithm on a 1D list of tiles. I used the Manhattan Distance to calculate the heuristics for remaining distance to player from monsters along the path. I only check the surrounding tiles, which greatly reduces the time it takes to calculate the path. It's still quite basic compared to many A* possible additions, but works for now.

OSX version available for download

Link:

Check the wiki for download links at:  http://surviverl.shoutwiki.com/wiki/Main_Page

Windows build available for download

Check the wiki for download links at:  http://surviverl.shoutwiki.com/wiki/Main_Page

It doesnt do much at the moment. You can move around, dig holes, and move up and down between layers.

It has turn based polling, but I have set this on a timer for now once a second, so that it mimics some sort or realtime play, but that can be switched off again.

I welcome any comments on this crappy game so far

New screenshot

Its now 32 wide, by 16 high

Keys

Current Keys:

8-way movement:

R T Y
F    H
V B N

D = Down
U = Up

C = Collect
E = Exit/Quit
M = Place a Tree
X = Dig

Current Status

The following is implemented so far:

Game/World:

• Player movement in 8 directions
• Player can move up and down between deeper levels
• Infinite terrain (no map boundary)
• Procedural generation of world
• 64 deeper levels under ground level
• Cities, Forests, Fields, Dungeons
• Player cannot move through trees
• Monster spawning on multiple levels
• Random monster movement
• World can be saved and loaded
• Player can remove tiles from world
• If tile is empty at a position, player drops through hole to lower level automatically

Game Engine:

• Plugin framework in place
• C# scripting framework in place

Modding Support - Check!

That's right! The game is running already with modding support for plugins and scripting.

Here's technically what I did:

Modding/Plugins
As the game is written in C#, I used MEF to allow the game to load plugins. This is done now. So, I need to create an API for people to be able to interact with the game. More on that later...

Scripting
I used CodeDom to allow me to compile C# scripts into dlls, and load the compiled dlls and run them. So, it's already done where scripts written in C# can be used in the game

Introduction to the game

SurviveRL is a game, where you gather resources, build a place to live, craft items and combat with monsters and animals.

There are cities, dungeons, forests, caves, fields (with farms). You as a player, can visit any of them as you want, and return/enter/exit as many times as you wish. You can dig the landscape, and fill it in.

There isn't permadeath, and you can save your game and load it again later. Also, your character isnt connected with the world, and you can move him or her between your saved games.

Think of the game like this:

A mix of Ultima Online and Minecraft in an ASCII RogueLike landscape.

From Ultima Online, I took:

• Crafting
• Housing
• Vendors
• Skill Tables

From Minecraft, I took:

• Landscaping
• Infinite Terrain
• Biomes

I'll make a wiki soon, to start to copy/paste in my game design notes

Screenshots

Here is the top level. T is a tree. M is a monster. The @ is me

 

Here is underground. C is coal

It's a game.

It's a roguelike.

It means you have to collect stuff or make it to help you survive.

The whole World in the game is dynamically created in realtime. The World map, is infinite in east and west, and North and South directions.

It's randomly generated every time you as a player start a new game.

The World exists without you. You are part of a living World, and can just Watch it if you want.