Current status of the project

It's time to summarize what we have at the current state.

It's important to say, currently I don't have anything flashy nor interesting. The project is still in its very very early state, and I'm focusing mostly on the background services and boring things under the hood.

Backend server

I've moved the whole backend stuff to a real server out there. Until last week the serverside things laid here in my living room, on a shitty old laptop. Now we have a valid domain name, and a totally empty wordpress site to provide some fancy stuff later. (Forum, news, downloads, etc)

And an SQL server to store the

World data

Surprisingly, I have the whole world data for about 2-3 years. Back then, when I started thinking seriously about this project, I wrote a python script to generate a 10 000 x 10 000 tile world with rocks and water. 

Just for reference the below map piece is 1000x1000 pixel, and it represents only 1% of the current V8id world map size. Yes, it's huge. Monumental. It consists of 100 million tiles. 

Because big dreams need big maps 😉

So now I have 100 million rows in an SQL database, sitting there, and waiting to serve players. To be precise, just 9 299 740 rows, because I do not store the plain dirt tile, just the rocks/mountains and the water. Optimizations, baby! 😂

Networking basics

I've never used Golang before, but it seemed to be one of the best languages to do the magic that happens on server side. It's easy and straightforward, but lots of people hate it. It doesn't matter to me as long as it gets the job done perfectly. Personally I find the whole language and the learning process interesting. It goes against today's trends, where every language wants to look like C. 

Go seems a very unique, fresh experience to me, and it made the development much easier in some ways. It can handle thousands of parallel connections, has easy DB interface, and it's really, really fast.

The whole backend now is only about 400 lines of code. And I have a working custom byte based communication protocol. Which is totally minimal, but does the job fine.

Communication protocol

The main concept is, to send/receive packets with a maximum size of 255 bytes, but as compact as it's possible.

To ensure a more reliable and a bit of verifiable data stream, every packet has 3 main parts:

• First byte: the length of the packet's data (the payload), excluding this byte and the final closing byte -> max length: 253 bytes
• The packet payload, it can be max 253 bytes long
• Final byte, a closing 0xFF

The payload's first byte is always a "command" byte which determines the syntax and the order of the following bytes. In the response, the payload must start with a response status code, followed by the previously sent "command" byte. (see it below)

Currently I'm using only 3 commands to communicate:

• "L" byte, as LOGIN: syntax:  "L123456username" where 123456 is the One Time Password for login the user: "username". This command should be the first command after a handshake (see below)
• "C" byte, as CLIENT: the client can send it's capabilities to the server, like if it wants ASCII or PETSCII text translation, it is capable or not of upper/lowercase letters, or colors, etc. The client must tell it's speed in baud, because on the serverside data will be sent as timed output. It seems to be more safe to respond at the speed what the client asks for. Also the client can ask for 0x00 byte escaping, as I mentioned it in my last post. The final form and syntax of the command is still under development, as it's evolving continuously.
• "W" byte, as WORLD: get the world's tile data. To prevent any abuse, and unlimited map parsing, the client can only query a small  part of the map around the player.
  Syntax is exactly 4 bytes: W [X offset] [Y offset] [width+height], where the offsets are meant relatively to the players position, for eg. X=-15 and Y=-15 means we need map data from the direction top left from the player with distance 15. Width & height defines the "window" size what we get back. W+H can be max 15+15 so they can be fitted into one byte as 2x4 bits. (Called nibbles, or nybbles, this is where the protocol's name came from, as Nibble-based Packet Protocol for Lightweight Exchange -> NiPPLE)

Response status

The server is only sendig data, when the client has requested something. It always responds with a response code. To keep things simple, it uses the standard HTTP response codes. The only problem is, these HTTP codes range from 100 to 511. In 1 byte we can store only values 0-255. So we need some tricks to spare a few bytes.

The first digit of response codes can be 1-5. The remaining 2 digits can between 0-31. So we can encode our codes as 3+5 bits as below:

HTTP 200 - OK:  

Binary 010 -> 2 and binary 00000 -> 00

Put them tohether: 010 00000 -> 64 (or 0x40)

HTTP 404:

Binary 100 -> 4 and binary 00100 -> 04

Finally: 100 00100 -> 132 (0x84)

At first it could seen as unnecessary and overcomplicated, but I'm sure it will be very useful in the long run to use the well known HTTP response codes instead of custom ones.

Initial handshake

Because we don't know who is connecting from what hardware, and their network is reliable or not... We need an initial handshake between the participants to make sure the connection is well estabilished and usable.

At first, the client must send a packet with a 4 bytes payload: "8BIT". The server will respond also with 4 bytes: "RULZ". Now both sides know the communication is ok.

Users and their data

Currently I'm not planning to overengineer anything what is UI or "frontend" related. In my opinion, everything is "frontend" what is not directly connected to the game client. This contains webpages, email sending, user registration, and everything what is "modern".

I think a simple Wordpress should be enough to handle user registration, emails, and all the related stuff. The plan is to provide the One Time Password on the webpage for the users' login. 

Because of ->

Unencrypted communication

It's not feasible to use HTTPS or any secure TLS/SSL connection from 8 bit machines. This means we can not send passwords through the network to login the users to the game. But we can generate a new OTP (one time password) every time when a user connects, and we can display it on the webpage to the specific user. On their profile page, or anywhere else. Or I can send them in email if it's needed.

I have an idea or we can call it as a workaround 🤔

It's possible to provide a simple proxy app for the game too. The user can install the proxy on its PC. The 8bit client is connecting to the user's PC instead of the server, and the PC communicates with the gameserver via an encrypted protocol, and provides the data stream to the 8bit client on the local network with an unencrypted connection.

But first... At least we need a working prototype game 😉

Graphics

As I mentioned earlier, I'm absolutely not an artist or a graphician. And 8x8 pixels are not so enough for self-expression. So the current graphics is... shit 😂

It's absolutely not as awful as I expected. And btw everything is quite recognizable 🤣 When the client will be ready to display something, it will look so cool. (Or somewhat cool, based on the current extremely high fidelity graphics 😄)

Speed

The main concept is to make a game what is playable from any platform, and is possible to make a client in any language for any machine. But at this moment...

C64 BASIC is the de facto standard and the baseline here for me. If it can’t run on that, it’s probably too complicated.

So now I'm locked at 300-600 baud speed. At 1200 baud, BASIC communication goes totally unreliable.

The C64 client

The client is developed in TRSE with some ASM. Sadly, at the moment it's totally incapable of any gameplay or to display anything from the world.

Currently I'm using it only for debugging, and checking if the communication is working properly. I would call it more of a debugging tool than a real client. From a networking perspective, yes. It's definitely a client. It can connect to the server, request and receive data, but nothing more.

BUT... I think I've made the first baby steps successfully. (After years) It's a big milestone.

There is a world on a server, populated with map data. There is a client app that can connect to it and login. It can query world data, and it's just one step away to interact with these data and alter the game world.

And all of this was made from a C64 emulator. This means, it's possible to make it work on a real C64. So it's possible to make it on any other 8bit system too.

Welcome to V8id 😉