Who wants to make a MMOG for CPC?

[zhulien]

I have made a proof of concept for the client server communications to allow for online CPC games.



https://www.youtube.com/watch?v=hiyiLPZb9kg


FPS = Frames Per Second at the client side (artificial cap at 60 currently)
IPS = Game Loops Iterations per second (artificial cap at 25 currently)
CPS = Server Calls Per Second (artificial cap at 10 currently)

http://8bitology.net/poc/vdu/mmogdemo.htm <-- POC (using JavaScript clients)






Here are 4 clients, can be up to 26 (not really a limit, just there are only 26 lowercase letters a-z in english.  This should be achievable on real CPC too being a client but I'd like one of you to create a POC of the client.  i will give you the protocol this weekend sometime.


Basically we have areas, they can be as big or small as we like.  In this POC I have made them 40 x 20 which makes 1 screen of text to show it off. 800 bytes in a payload.


These clients are in javascript, but using a method that I already proved to work on CPC.  The JS I have limited to 10 calls per second to the server - can a CPC achieve that if coded in assembler?


The POC here doesn't stop many people controlling the same player at the same time, that is because I am prompting for the player and there is no checking for now.


Types of games could be:


- a dungeon crawler? 
- a multiplayer druid clone?
- a multiplayer (less frantic) wizards lair clone?
- bomberman clone?
- a laser squad clone?
- A multiplayer lords of midnight type game? 
- Any RPG? 
- multiplayer mutant monty clone?
- multiplayer roland on the ropes clone?


The game could be single screen areas but they could also be large areas with scrollable regions - if coded in a fast language.  BASIC should be fast enough for some games for sure, but I am uncertain about how many calls per second to the server you can make.  The calls per second limits how fast you can move around - if there is too much discrepancy between internet connections, I can put a pulse in there so everyone goes the slowest speed.


The server currently is holding the map so that people can't walk through walls so easily.  The server can also decide on whether someone goes through one area to another and it tracks which players are in which areas.  There should be no real limit to this, just how fast can a CPC render lots of players on the screen at once depending on how you choose to render it.  If anyone likes the idea to make a full-blown POC or a conversion of an existing game to multi player we will likely have some interesting output - and some challenges, but I am sure most can be overcome.


Also, the server code I will make available to anyone who wants to host their own game - or I can host it (but still give the source to the game author).


--------------------------------------------------
Some technical info for someone to write a client for this POC to see how many calls per second they can make:


Request:


endpoint is:    http://8bitology.net/poc/vdu/ws.php?function=getarea&areaid=1&player=b
function: must be getarea
areaid: for now must be 1
player: can be any small letter from a-z


Response:


The response is designed to cater for CPC or similar computers.  eg,


Success: 1:<sometimes a message>:+++++++... (1:: plus 800 more bytes)
failure: 0:<sometimes a message>:


Using the M4 you can do a memory transfer, to cater for messages, perhaps allow for 1kb for this POC.
Do it as many times as you can per second, if you get a 1 (success) then render the output.  The output is a continuous stream of characters, in this example, a mode 1 screen you should render 40 characters before going to the next row. 


Note: you do not need to render everything as 1 character in size.  You can choose to render them any size you like and scroll around the area if you prefer.


Questions:


Where is my character after I render?


The response contains everyone in it other than yourself.  It is intended that your position is known always on the client so no need to have it indicated in the rendering.  Consider the returned information as a 'mask' for a map, not the map itself.  Being a mask, you have your local map data and can render the + however you like - that is purely to prevent a player character from going on that location - which is maintained at the server end.  Your player characters can all be animated and whatever sprites you like on the client end.  Animate everyone, it will look good.


There is another API call that will let you set the position of your character that is.  In a normal gameloop, you will sense a keypress then update your position.  There is a very slight variation of this - we aren't including advanced ideas yet such as movement prediction - but, you get your player position (x & y) and put the updated versions based on keypresses into a temporary variable - you then make a call to setplayerpos which will return a success or failure.  If a success, then your location has moved on the server and you can change your local position to reflect.  If you want shrouding, do it on the client for now, but it could be possible that we implement shrouding as well as windows to huge landscapes at the backend so the payloads can stay small for CPC.


Request:


endpoint is:    http://8bitology.net/poc/vdu/ws.php?function=setplayerpos&areaid=1&player=z&playerx=5&playery=5
function: must be getarea
areaid: for now must be 1
player: can be any small letter from a-z
playerx: your intended player x position
playery: your intended player y position


Response:


The response is designed to cater for CPC or similar computers.  eg,


Success: 1::
failure: 0::


Note: as these are http/https requests, store your base url (8bitology.net/poc/vdu/ws.php) in a config file so it is not hardcoded in your game. 


--------------------------------------------------


If this eventually turns into something that supports a real game we can extend the the API to cater for a bit more security as per the 8bitology API.


What do you think?

[SkulleateR]

Love the idea (although I cannot help coding) ....


Would this be possible through M4 WLan ? Maybe some kind of rougelike multiplayer dungeon crawler ?

[zhulien]

Love the idea (although I cannot help coding) ....


Would this be possible through M4 WLan ? Maybe some kind of rougelike multiplayer dungeon crawler ?

Through M4 LAN or Internet would be possible - LAN (without internet) only if the server is hosted internally on a LAMP/MAMP/WAMP/AAMP stack.

[sigh]

Gimme a top down Dark Souls or Dragons Dogma please
In terms of graphics and sound effects - what can we expect?

[zhulien]

What this allows is coordination of multiple players within the same game 'walking around' for the time being - non-player characters, objects and perhaps projectiles should all be possible.  The graphics are what the CPC does, the M4 and Symbiface both have mass storage so how that is used is up to the game author, and if you go to the games threads there are some really talented graphics and music artists on CPC - and if they have interest to make a game to have a multiplayer/internet mode, I will gladly help them out and work with them to see what we can achieve.  Even on a CPC 464 with M4 card, the possibilities are endless.  As a side note, this simple POC allows 26 players to move around - granted it isn't perfect, but I only spent 5 hours on it so far, and that is 26 players in a single room and hosted on a very slow server - performance-wise, there is no reason we cannot have 200+ players in a single game but spread across rooms - or even perhaps we could prove they work in a single room too, i know it will work acutally - but will it work nicely

[sigh]

Do you need to use the M4/Symbiface to work in order for this to run, or could you just use the stock CPC?

[zhulien]

There could be other options like the serial port with wifi but someone will need to write a driver set for each option.  M4 is very common and inexpensive and I recommend anyone who hasn't gone one already to get one.  It offers so much at a very reasonable price. 

[zhulien]

no Volunteers to make a POC like the JS one for CPC to see how fast they can make it update on a CPC?

[sigh]

no Volunteers to make a POC like the JS one for CPC to see how fast they can make it update on a CPC?

I hope someone takes this on.

[sigh]

Out of interest, how well would this work for online sports games? Would it be fast enough?

[zhulien]

It depends on how fast/frequent can the CPC read data from the server.  Although the current payload is 803 bytes, this is not optimised.  Even if using RLE, it could come down to under 50 bytes for the payload.  If for example you had a soccer game with 22 real players, each CPC needs to fetch the data as fast as possible - slower means slower games, eg: American Football seems slow but I don't know the rules.

[sigh]

It depends on how fast/frequent can the CPC read data from the server.  Although the current payload is 803 bytes, this is not optimised.  Even if using RLE, it could come down to under 50 bytes for the payload.  If for example you had a soccer game with 22 real players, each CPC needs to fetch the data as fast as possible - slower means slower games, eg: American Football seems slow but I don't know the rules.

I was thinking exactly of the football game.
I was also wondering how well scrolling would function or even flick screen or push scrolling over the server.

[zhulien]

The way it would work, the client would actually handle the full game in this kind of game with the server purely coordinating the players positions and ball position.  All rendering is on the cpc.  It isnt to be considered as a streaming game service


There are many types of multiplayer games and even in a game which could allow 100s or 1000s of users, all of the positioning is coordinated by the server. I say coordinated because every client can know where every player is within a specific sized area.  The size of this area could be as bigger than the 40 x 20 like the JS demo.  The game could be many more locations than this but the server needs to cap the payload size for the cpc.  It could be capped based on a line of sight or a shroud to force a cpc to only render a bit of the level at a time.

[luckpro]

Out of interest, how well would this work for online sports games? Would it be fast enough?

If you want to make an online soccer game for 2 players I recommend that you do not send all the information of all the players to the server. Only the 2 or 4 players closest to the ball, the rest should be calculated by the game based on the position of the ball. You should send packets 3-5 times per second. Send position, direction, animation and ball info. 32 bytes approx. per packet, 160-200 bytes per second. If you can maintain this speed you can made stable the game.


Try not to use http or similar protocols, use the lighter protocol that you can (UDP or similar). Remember, it is a CPC.


If you want to make a dungeon game try the server to do all the hard work possible and the cpc just renders the game and submits input to server.

If you intend to make a massive game, separate the players into rooms to limit the information you have to send to each one.

It is a good project, do not stop giving support to play from the browser, so you will have more players.

[Sykobee (Briggsy)]

I believe most of the CPC internet adapters offload TCP/IP to the MCU on the add-on board, and the CPC pretty much communicates at the register level with the MCU. But yes, UDP is a suitable transport although there is a risk of packet loss.


It will certainly be most of use in a slower game (e.g., RPG) than an action game. Also you can offload various amounts to the server, from treating the CPC as a dumb client to merely coordinating player locations with the client doing most of the work. The more work you offload to the server, the larger the data transmissions from the server to the CPC will likely be.


Could be a nice thing to have at a CPC meet-up (so those in Spain and France could be interested in this) - host a game server on a RPi, and connect up a bunch of CPCs.

[sigh]

If you want to make an online soccer game for 2 players I recommend that you do not send all the information of all the players to the server. Only the 2 or 4 players closest to the ball, the rest should be calculated by the game based on the position of the ball. You should send packets 3-5 times per second. Send position, direction, animation and ball info. 32 bytes approx. per packet, 160-200 bytes per second. If you can maintain this speed you can made stable the game.


Try not to use http or similar protocols, use the lighter protocol that you can (UDP or similar). Remember, it is a CPC.


If you want to make a dungeon game try the server to do all the hard work possible and the cpc just renders the game and submits input to server.

If you intend to make a massive game, separate the players into rooms to limit the information you have to send to each one.

It is a good project, do not stop giving support to play from the browser, so you will have more players.

I was thinking about the graphics and animations for the football game I am doing, but it's probably better to test a game that is less complex. Having to only update 2 - 4 players nearest the ball, which would include the ball and also a goal keeper for a corner kick, which is always crowded with players, would be very problematic.
I guess the easiest approach to test would be some form of table top game for starters. I had created some graphics for a dominoes game in mode 1 a very long time ago. Again as usual - it does have character animation on it, but as it's not a reactive game and everything happens on a single screen.

. It will certainly be most of use in a slower game (e.g., RPG) than an action game.

With regards to RPG's - I take it that action RPG's would be out of the question(?). World of Warcraft type games - still have some sort of reaction time. I'm also wondering how sound effects and music would work in regards to keeping it in synch?

[andycadley]

Most online games cheat. The music/sounds don't need to be in sync on different machines they just need to sound right for the person sat at any given machine. The real trick is to run the game logic independently and then sync up the position of key objects (f.e. players likely to interfere with the path of the ball) between remote machines rather than trying to sync the entire game state.


It's not an easy thing to do though and I suspect for all but the slowest pace games out there an 8-bit machine wouldn't have the grunt necessary, which leads to very choppy/jittery gameplay as the machines desperately try to correct for larger and larger errors.

[sigh]

The real trick is to run the game logic independently and then sync up the position of key objects (f.e. players likely to interfere with the path of the ball) between remote machines rather than trying to sync the entire game state.

Yes - this is what I was thinking. You still have interference from the other players actions and because of the limitations of CPC audio channels, you would get a lot sound not being able to all be played at once. This is one of the reasons that a turn based game like cards/dominoes etc could be a good way to start in regards to finding out the limitations. Turn based game would only entail the music and sound effect for that player only, with the rest of the players not needing theirs to be played.

[Sykobee (Briggsy)]

It depends on the latency between the server and the CPC and the payload size.


The server would trigger the enemy attack (as it could host the AI, offloading it from the CPC), and send the message to the CPC regarding the attack. The CPC scans the network system in its game loop which may be multiple frames. It parses the message, calls the appropriate handler for an attack, and then triggers the client-side actions (animation, sounds, messages - these would be in sync for the player at least). The player then would have some reaction time depending on the weapon used, to defend/flee. That defence would then be sent to the network, then onto the server, and the server should add some leeway to cater for latency.


The server wouldn't send each frame's movements though. You only need to say "timestamp1: mob7 casts fireball from x,y in direction dx,dy" for example, and the clients should animate mob7, add the fireball entity, play fireball sound, and then continue to move it independently. The server will check for collisions, and send "timestamp2: fireball hit player3 at x,y" if the server determined it hit the player, or if that player did react in time "timestamp2: player3 raises shield / casts protect / etc" + "timestamp3: fireball fails at x,y".


The client is pretty much only merely maintaining state for each entity (player/creature/door/item/projectile/etc) in the game (that it needs to be aware of), and rendering it appropriately, depending on the state. The server updates the states.


The latency on a 50fps football game however might overwhelm the system. But let's say it didn't - it has to be under 20ms. The game logic runs on the server (which may be a CPC!). The message needs to update player states and ball states and major events (foul, red card, etc), and maybe actions like when the players form a preset formation with an animation to get into that formation. 22 players, 1 ball. Player state is x,y,direction,action - a few bytes. You could probably stream 100 bytes every frame to the CPC and it could handle it (no AI overhead, so some CPU to process and update the states). That's still 5KB/s of data transfer.

[sigh]

- a dungeon crawler? 
- a multiplayer druid clone?
- a multiplayer (less frantic) wizards lair clone?
- bomberman clone?
- a laser squad clone?
- A multiplayer lords of midnight type game? 
- Any RPG? 
- multiplayer mutant monty clone?
- multiplayer roland on the ropes clone?


Which would be the most helpful of these games to do, in regards to covering most of the bases and technical challenges in creating an MMOG and showcasing what is and isn't possible from the get go? I think that the bomberman clone maybe a bit too simple and not cover all these bases? I wonder if it may be best to look at an existing game that cover a lot in terms of AI and direct control, detailed huds that have menus and item changes (armour, weapons, spell, pick ups etc), save states, chat window, looking at how players quit or enter the game - mid game, scrolling, building settlements etc.

Recreating or cloning an existing game, would mean that there would be more time spent on getting the online experience working comfortably without having to worry about game design?

[luckpro]

I think you better start with some turn-based game or at least not have a very fast action. I guess the latency in a CPC is going to be higher than normal. Better to try something slow game first.
Good luck.

[sigh]

I initially thought this too with a table top game and still do.

However, there are a lot of advantages into create something that really pushes the limits, then scale back when needed. That way, you will find out a lot more quickly of what is achievable and this will give other developers, a heads up so that they either:

1) Find a new way of achieving the unachievable, by having a reference of what was already attempted before, in which they can build upon.
2) If they had a similar idea, they now have the opportunity to see that it didn't work. This would save them time.
3) Not wasting their time attempting it all.

[zhulien]

With regards to RPG's - I take it that action RPG's would be out of the question(?). World of Warcraft type games - still have some sort of reaction time. I'm also wondering how sound effects and music would work in regards to keeping it in synch?

Although it is not a streaming server, the clients in JS are fetching all data 10 times per second with an artificial cap at the moment.  I don't know if a CPC can get that fast, but some CPC games actually run at a few frames per second.  Depending on how fast a CPC can repeatedly fetch data from the server, that will really define the starting point of optimisations - such as shrouding, RLE, memcached etc.  The entire game is intended to be 'on the CPC' with masks of maps and player positions (likely object locations) tracked on the server.  The maps are on the CPC too, but the server only needs the mask to prevent players from going where they shouldn't. Tracking on the server is so that CPCs cannot cheat and of course they stay in sync with the positions of everything.  I chose the 800 byte payload as a good maximum payload size, but of course we can get it down to 50 bytes and under if we introduce shrouding to the server.  The CPC still will render the game fully, animate it fully.  Think of it as a CPC game with a server to help out - yes it can be a local server.

[zhulien]

It depends on the latency between the server and the CPC and the payload size.


The server would trigger the enemy attack (as it could host the AI, offloading it from the CPC), and send the message to the CPC regarding the attack. The CPC scans the network system in its game loop which may be multiple frames. It parses the message, calls the appropriate handler for an attack, and then triggers the client-side actions (animation, sounds, messages - these would be in sync for the player at least). The player then would have some reaction time depending on the weapon used, to defend/flee. That defence would then be sent to the network, then onto the server, and the server should add some leeway to cater for latency.


The server wouldn't send each frame's movements though. You only need to say "timestamp1: mob7 casts fireball from x,y in direction dx,dy" for example, and the clients should animate mob7, add the fireball entity, play fireball sound, and then continue to move it independently. The server will check for collisions, and send "timestamp2: fireball hit player3 at x,y" if the server determined it hit the player, or if that player did react in time "timestamp2: player3 raises shield / casts protect / etc" + "timestamp3: fireball fails at x,y".


The client is pretty much only merely maintaining state for each entity (player/creature/door/item/projectile/etc) in the game (that it needs to be aware of), and rendering it appropriately, depending on the state. The server updates the states.


The latency on a 50fps football game however might overwhelm the system. But let's say it didn't - it has to be under 20ms. The game logic runs on the server (which may be a CPC!). The message needs to update player states and ball states and major events (foul, red card, etc), and maybe actions like when the players form a preset formation with an animation to get into that formation. 22 players, 1 ball. Player state is x,y,direction,action - a few bytes. You could probably stream 100 bytes every frame to the CPC and it could handle it (no AI overhead, so some CPU to process and update the states). That's still 5KB/s of data transfer.

All good points, but I am starting from the opposite.  If you took for example a soccer game on the CPC with 22 individual players.  They can freely move around the soccer field, they request the server upon moving, can i move to x,y and the server responds yes or no.  If the CPC gets a yes, it can really move the local player (the server already did just before the CPC got the response).  All CPCs will get the updated player position actually as they are forever requesting info from the server.  This info in my POC is actually a full map mask and player positions but partly why it can be heavily improved upon is we don't need to transmit the mask to the CPC, it already has it - in the case of a soccer field, the mask is basically the rectangle - we only need a bunch of positions.  The CPC knows it's screen display, not many soccer games show a full screen with the entire soccer field in view, so the CPC doesn't need to fetch every player's position always (maybe if we have a defender type scanner we might).  Think of the zoomed in CPC view of a part of a soccer field as the shroud.  So the server should be able to reduce the returned data based on this shroud.


What I have written about the soccer game is identical for a dungeon crawler.  And yep, as you guessed, 1000s of players can be in it, as long as they are not within the unshrouded area a CPC is displaying - which could be a circle of sight, it could be a maximum room size.


For projectiles, they would be treated much like an NPC character but controlled from the server or another device - I am considering the idea of NPC characters being their own clients to the server too so that people can easily develop them for a 'generic' game server.  Projectile accuracy I suspect will be a challenge - if they are slow.  If they are bullet speed, bascially immediately hit something within range and in line of sight, then we don't need to watch a bullet move... we just see the injury on the player perhaps.

[sigh]

Well - I have a rather heavily animated football game if anyone's interested
@zhulien - in your view, what would be the best type of game to test first?