Coronium GS prototype Lua code dump.

Hi,

I’ve had a few requests for the code to the Coronium Game Server prototype game that I demoed here in the training series.

You’re welcome to rummage through the code in the repo, but you’re on your own for making sense of it. :slight_smile:

It’s important to point out that the server side Lua code is running on Luvit.

https://bitbucket.org/develephant/destinyclash/src/5b0354af4016?at=v2

If you do want to try and run this on your own instance, you’ll need to update the ‘host’ property in  Client/scene_signin.lua  at around line 35.  I have not tested this yet on the most recent GS version.

In any case it could be nice to look over just to understand some different Lua concepts, etc.  If you are unfamiliar with Coronium GS, head on over to http://coronium.gs to learn more.

Enjoy,

Chris

Hi, is Coronium still supported?

I’ve been trying to get more info on the community forum but it appears to be dead.

Hi rune7,

Sorry for the delay.  For some reason I am not getting emails from the Google group, I’m looking into it.

Coronium Cloud is still fully supported and will be receiving a new update at some point.

Coronium Game Server is no longer “officially” supported at this point.

Hope that helps.

Cheers.

Hi,

Thanks for replying. Any reason you decided to stop active support for GS? I was really hoping do develop the server in lua.

Anyhow, I tried installing the amazon instance but it seems to be mis-configured or something.

Since there are no instructions on how to set it up I followed the cloud version instructions which should be quite similar I guess.

I also ran the update script that existed on the instance and it did add quite a few things to the instance.

However, I tried to install the server admin panel (as explained here: http://coronium.gs/digitalocean.html, including opening the tcp port) and run it using sudo gs-admin command but it does not show the page when I try to access it from the browser.

Any ideas what might be causing this?

Next I was planning to upload one of the samples to see if they can interact with their client before I start testing my own code.

Regards,

Adi

Hi,

Dropping support I guess is a little strong of a statement. What I should say is that there are no updates on the horizon.

While I’m super proud of GS, it took a long time to develop, and there is no doubt that as a highly-opinionated framework, it ends up being difficult to conceptualize for a starter (and even some pros).  Too much “automagical” stuff happening behind the scenes. :slight_smile:

Hope that clarifies a little.  As far as the GS installation, I’ll take a quick look and see if any dependencies have changed.

Cheers.

Well, I find the code quite simple to understand and extend. I mainly had problems understanding the installation as I’m not a unix user and I wanted to use it on openshift as it offers a free package with no time limit. 

As for current status: while the admin panel is not working, the rest seems to work fine. I will attempt to use it for my new concept game. Hopefully all will go well. with your permission, If I have more questions about the code I’ll ask them here.

Regards,

Adi

Hi Chris,

My adaptations to the server proceed quite nicely, managed to add a few custom events to the system to allow a user to pick an open game from a list to join to etc. However, during my testing I’ve probably corrupted redis db or something. Restarting the service or even the vm doesn’t help.

I could really use the server admin panel. I’ve tried to reinstall it but get nothing when I try to connect from the browser. could use your help.

Just fyi, I’m getting this error on the log (which doesn’t help me much to understand the issue):

        [C]: in function ‘run’

        /usr/local/lib/luvit/luvit.lua:426: in main chunk

        [C]: in function ‘require’

        [string "    local path = require(‘uv_native’).execpat…"]:1: in main chunk

WARNING: forgot to close luv_timer lhandle=0x40380cf8 handle=0xf41d50

WARNING: forgot to close luv_tcp lhandle=0x4037f648 handle=0xf41c70

WARNING: forgot to close luv_timer lhandle=0x40375ef0 handle=0xf6c700

WARNING: forgot to close luv_timer lhandle=0x40375a28 handle=0xf6c100

WARNING: forgot to close luv_tcp lhandle=0x41049fb0 handle=0xf6bea0

WARNING: forgot to close luv_tty lhandle=0x40a49c20 handle=0xf52440

Regards,

Adi

Another more abstract question, since I’m not an expert on server side development.

I find myself adding more and more conditions on GS:onClientData( client_sock, data ) server method to treat game related actions. It seems to me that it would have been better to establish a dedicated socket connection between the game instance on the server and its assigned players. The game socket can handle just the subset of messages that relate to itself, leaving the main GS connection free to handle new clients and lobby related events.

What do you think?

I’m mainly concerned that GS:onClientData will become a bottleneck when many games are played concurrently.

The base is Luvit.io, a NodeJS like system, chances of bottlenecks are basically nil.

Anyhow, in your onClientData handler you should be just be pushing off to another module.  See the server development guide also. http://coronium.gs/server/topics/development.md.html. Additionally as much game logic as possible should be in the client, not the server. The server is meant to keep state and send/receive discrete data, which would trigger logic on the client, and whatever global calculations are needed.

Also, if you are adding to anything outside of the documented usage, you face a huge risk of hosing your instance. Sorry I can’t be more helpful, but this project is not a priority at the moment. 

Cheers.

Hi, is Coronium still supported?

I’ve been trying to get more info on the community forum but it appears to be dead.

Hi rune7,

Sorry for the delay.  For some reason I am not getting emails from the Google group, I’m looking into it.

Coronium Cloud is still fully supported and will be receiving a new update at some point.

Coronium Game Server is no longer “officially” supported at this point.

Hope that helps.

Cheers.

Hi,

Thanks for replying. Any reason you decided to stop active support for GS? I was really hoping do develop the server in lua.

Anyhow, I tried installing the amazon instance but it seems to be mis-configured or something.

Since there are no instructions on how to set it up I followed the cloud version instructions which should be quite similar I guess.

I also ran the update script that existed on the instance and it did add quite a few things to the instance.

However, I tried to install the server admin panel (as explained here: http://coronium.gs/digitalocean.html, including opening the tcp port) and run it using sudo gs-admin command but it does not show the page when I try to access it from the browser.

Any ideas what might be causing this?

Next I was planning to upload one of the samples to see if they can interact with their client before I start testing my own code.

Regards,

Adi

Hi,

Dropping support I guess is a little strong of a statement. What I should say is that there are no updates on the horizon.

While I’m super proud of GS, it took a long time to develop, and there is no doubt that as a highly-opinionated framework, it ends up being difficult to conceptualize for a starter (and even some pros).  Too much “automagical” stuff happening behind the scenes. :slight_smile:

Hope that clarifies a little.  As far as the GS installation, I’ll take a quick look and see if any dependencies have changed.

Cheers.

Well, I find the code quite simple to understand and extend. I mainly had problems understanding the installation as I’m not a unix user and I wanted to use it on openshift as it offers a free package with no time limit. 

As for current status: while the admin panel is not working, the rest seems to work fine. I will attempt to use it for my new concept game. Hopefully all will go well. with your permission, If I have more questions about the code I’ll ask them here.

Regards,

Adi

Hi Chris,

My adaptations to the server proceed quite nicely, managed to add a few custom events to the system to allow a user to pick an open game from a list to join to etc. However, during my testing I’ve probably corrupted redis db or something. Restarting the service or even the vm doesn’t help.

I could really use the server admin panel. I’ve tried to reinstall it but get nothing when I try to connect from the browser. could use your help.

Just fyi, I’m getting this error on the log (which doesn’t help me much to understand the issue):

        [C]: in function ‘run’

        /usr/local/lib/luvit/luvit.lua:426: in main chunk

        [C]: in function ‘require’

        [string "    local path = require(‘uv_native’).execpat…"]:1: in main chunk

WARNING: forgot to close luv_timer lhandle=0x40380cf8 handle=0xf41d50

WARNING: forgot to close luv_tcp lhandle=0x4037f648 handle=0xf41c70

WARNING: forgot to close luv_timer lhandle=0x40375ef0 handle=0xf6c700

WARNING: forgot to close luv_timer lhandle=0x40375a28 handle=0xf6c100

WARNING: forgot to close luv_tcp lhandle=0x41049fb0 handle=0xf6bea0

WARNING: forgot to close luv_tty lhandle=0x40a49c20 handle=0xf52440

Regards,

Adi

Another more abstract question, since I’m not an expert on server side development.

I find myself adding more and more conditions on GS:onClientData( client_sock, data ) server method to treat game related actions. It seems to me that it would have been better to establish a dedicated socket connection between the game instance on the server and its assigned players. The game socket can handle just the subset of messages that relate to itself, leaving the main GS connection free to handle new clients and lobby related events.

What do you think?

I’m mainly concerned that GS:onClientData will become a bottleneck when many games are played concurrently.

The base is Luvit.io, a NodeJS like system, chances of bottlenecks are basically nil.

Anyhow, in your onClientData handler you should be just be pushing off to another module.  See the server development guide also. http://coronium.gs/server/topics/development.md.html. Additionally as much game logic as possible should be in the client, not the server. The server is meant to keep state and send/receive discrete data, which would trigger logic on the client, and whatever global calculations are needed.

Also, if you are adding to anything outside of the documented usage, you face a huge risk of hosing your instance. Sorry I can’t be more helpful, but this project is not a priority at the moment. 

Cheers.