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?