Dragon Basher: New Quantum Server

  Prev 1 2 3 4 5 6 Next

Posted: 06‑04‑2018 09:55


Joe


Fire Flipper
1485 posts
If you haven't noticed, I have let the dragobasher.com domain expire - I can justify paying for it any longer. Instead, I'm going to focus on another new gaming engine - this one with a lot of potential.

The idea behind a quantum computer is to use the least amount of physical energy possible; so instead of a one foot long wire it uses a one inch wire - thus the electric can get there faster with less power.

The idea behind my quantum gaming engine will be to do as little as possible; the less the server has to do the more it can get done. This starts with a new directory named only with one letter: "q".

Each player gets their own directory (their player name) where they start off on an island with a teleport to other player servers that are online.

Every object in the game will be represented by a two digit item code, and a hex z=location - thus the entire world can be sent to clients as a single string. Players will be an item code, with the object codes sent during login. Buildings will also be an item code, each player server can define which buildings they want in their game.

The idea is they can change their island into their own server with items and buildings, eventually tilesets.

Okay - so what makes this different?? The idea is the server will not do much of anything, it will be up to the clients to do everything. There will be "core server" commands that can delete, change, or insert an object into the game. That is all. That would leave virtually all programming up to JavaScript, which virtually anyone can edit on their computer themselves.

So there is the plan, until it gets done enjoy the Queville re-boot. :)

-Joe

DevTeam Member

 


Posted: 06‑10‑2018 20:22


Joe


Fire Flipper
1485 posts
I'm having a lot of success with something called "Node.js" which is a JavaScript server ... it was easy enough to install, and with it I was able to write and run an example web server and think this is exactly what I've been looking for.

With it, players with node.js installed will be able to run their own server that they can customize. When a player logs in, there will be a list of player servers online and each player server can have up to twenty-six players online at any give time.

Each player-server can have it's own custom JavaScript client, or they could use template clients with various themes such as a "capture the flag" client, and a "zombie" client.

In this respect, games become like FPS games where teams are formed and players have a mission to accomplish such as rescue a hostage or escape from a POW camp.

I have talked with QuaCzar about this before, not sure his status but I should have a working example online at some point this summer. It will be yet another re-write, this time with a huge focus on simplicity. Everything will be in JavaScript making it easier and faster to get everything done. :)

https://nodejs.org/en/

-Joe

DevTeam Member

 


Posted: 06‑12‑2018 20:36


Joe


Fire Flipper
1485 posts
As of right now I have a node.js "server" running that returns the file client.htm ... which is a copy of the current running Queville server. In theory, if the router and firewall are setup correctly anyone could connect to my computer with their browser and the client.htm page would load for them. If node.js did Perl, we could be logging in right now.

So what I want to do is start re-writing the Perl server in this node.js ... JavaScript is a lot easier than Perl so this should be quick to get done. There may need to be a Perl front-end, but overall I am hoping everything gets done locally at the player level.

Hope for some sort of demo soon. The ability to use JavaScript timers instead of Perl flat files will drastically change development of this gaming engine.

-Joe

DevTeam Member

 


Posted: 06‑13‑2018 09:24


Joe


Fire Flipper
1485 posts
I'm at point now where I realize the client.htm page I am working on should be compatible with any other server written in any other language, which is a good point to be. :)

In order for this to happen, the actual server I'm working on should be barebones get-the-job-done quick-and-dirty style. Below are the comments I have written that outline my way to do so.

My approach is that everything in-game is an "item", including players and buildings. One does not need to be actually "logged in" to see the world - thus as soon as the client is loaded the server will send it the "world" to be rendered before it even knows the player's name.

The server itself only "adds" or "deletes" items from this "world". When an item is added, it will last for one-minute and then the server will delete it and let the client know it deleted the item. The client can then decide what to do with the expired item, ie: a tomato plant becomes a tomato. The client can do this by adding the tomato after the plant expires.

Every two-seconds the client will send a list of items to add and delete while receiving a list of items in-game. To move, the client would send the command to delete the player's item and then add a new item for the player in the new location. While the server itself will have no concept of a "player" or an "inventory", the client can still be programmed to let people pickup and drop items.

I expect lag ... this is a different engine than Queville, and even different than 'dragon'. But I see a lot of potential, especially in the "simulation" genre of games.
The key factor is that the core server can be done quickly and then anyone that can write JavaScript can write games.

//
// Accepted Server Commands:
//
// Add [item][z] Put item on map
// Delete [item][z] Delete item on map
//
// Server then sends Commands:
//
// [update][item][object]
// [expired][item][z]
//
// Server then returns Items:
//
// [item][z]
//

-Joe

DevTeam Member

 


Posted: 06‑15‑2018 10:33


QuaCzar


Fire Flipper
1824 posts
Sorry I haven't been very active here in a while. I'm very busy IRL. I'm hoping to be active again this summer.

A new name seems appropriate for the new engine. Maybe it will be easier to convert my LAN JavaScript games based on mutual distrust. (That is, the programming/security concept, like bitcoin uses.) They use smart client scripting and dumb servers. Dumb cloud servers can be very efficient. The client cost isn't usually high enough to cause problems, though I like to make sure only games of the same version are talking to each other, so clients don't need to have backwards and forwards compatibility bloat or concerns about fairness.

Most of my games have players join a table/room to play, which is easier to manage than one world for that game, but I also use one persistent world for some things. I haven't maintained these games in a few years, but they are still in use. I'm hoping to get back to them, as well, if I can get time...

-QuaCzar : SysOp | Anarchy Leader | #1 Magic

 


Posted: 06‑15‑2018 10:43


QuaCzar


Fire Flipper
1824 posts
I have used node.js as a web server, itself, in a limited fashion. I don't know if that is an option, let alone practical, but it would be more efficient than starting a new node.js with each request, so I thought I'd mention it. Perhaps a node.js server could be an option for some users, so they wouldn't need to install anything else.

-QuaCzar : SysOp | Anarchy Leader | #1 Magic

 


  Prev 1 2 3 4 5 6 Next

Hunt food, smith weapons, and prepare for battle! Can you stop
the Evil Que from taking over the entire game? Browser based multi-player
fantasy role-playing game that requires no downloads or plug-ins! Free to play forever!

By being at queville.com, you agree to our Terms of Service.