grcooper / fioria-mmo Goto Github PK

Going to make auth easier and more secure by just using slack auth. Going to make it such that you only need identity permissions so any team can add this as an integration, and it doesn't add to the integration limit.

Will need to make a basic homepage with an add to slack button as our login.

https://api.slack.com/docs/slack-button

Enemies do not have to be anything fancy at the moment, possible just blobs that move around, however in multiplayer they add a bunch of things we have to consider:

• How to spawn them? We have to do this server side so everyone sees them
• We must store them in the DB? Otherwise we could store them in the game state and regenerate the monsters every time the server goes back up
• Damage will work the same way as movement, take the hit, send a message to the server, then do the damage on the client side once we receive a message back
• Players can now die, have to handle respawns

At some point it would be good to upload this to heroku to get people to test it on an actual server rather than just localhost

As in the docs we need to add basic attributes to the players, store this and retrieve this from the DB on join.

This is going to be a long process which I will do eventually. Waiting on Alex to give me a more detailed map of the world so I can convert that using a tileset i recently found on a free-use site.

Adding collisions with objects needs to happen before this can, as I need to make sure that collisions work.

We also need to think about how to split up the map into chunks.

I would like to have it such that buildings are the real size, but we might switch it out for jrpg style small houses and then when you walk inside of them it takes you to a different zone.

Be able to attack using magic(ranged) swords (melee) and bows (ranged).

With completion of this issue we should see visible projectiles come from the player and suitable animations.

May want to revisit our current movement animations and take them from the site:

http://gaurav.munjal.us/Universal-LPC-Spritesheet-Character-Generator

This is an interesting idea to contemplate but isn't an immediate goal.

I also bring up automation, as in automated tests or automating a series of events, because I believe the first step to achieving this is having event replaying.

Event Replaying

The best analogy to think of for replaying of events comes from Redux, where at any point you can see the ordered list of operations that have been run, you can checkpoint it, replay them, and even omit or modify some then replay them. This can be seen in the GIF on the Redux Devtools page.

In the context of game state replaying events can be thought of as how the way the server executes is an input of client actions that it runs, with some control of speed for the side effects that happen such as spawning or action rate limits (moving speed, attacking speed).

Automation and testability

This is the ability to run through a suite of automated tests which consist of just automatic replaying of events. An important asset to this would also be to have a viewable world map for the current server state. This would make it easier to understand what is currently happening to understand what differences may have occurred. This is akin to the Factorio automated testing, where you can view the simulated world and visual see it, at a sped up rate, but differs in that the simulation and viewing client are the same programs.

A basic idea of how this might work would be simply exporting all of the operations that occur and replaying them on the Phaser frontend, just at a speed up rate.

Alternatively, we could build something into the server to view the world directly from it at any given time, even during normal execution. The two obvious approaches are:

• Export a picture or the world state to view
• Provide an interactive map

This approach of an interactive map was actually quite common with Minecraft and proliferated among server owners.

Prior art

Factorio automated testing

Found in the Factorio blog, there's a brief preview of how the automated testing runs and is truly amazing to just run through all of the simulations. Obviously, this is very different from a client-server interaction but nonetheless is a cool and useful feature.

Redux event replaying

The general architecture of Redux lends itself to the well-defined rules of the backend state simply being the result of functional changes in the previous state. In summary, everything that happens is in the form of func(previous_state, action) -> next_state, so there are no side effects occurring and given the same inputs, you get the same output. More details of the architecture can be found on the Redux page, along with a neat GIF previewing the capabilities on the Redux Devtools page.

Minecraft interactive map viewers

Now a common plugin server maintainers use when they run a public Minecraft server, these plugins provide a way to view live Minecraft worlds in essentially Google Maps (well, possibly cached but generally live). You can check out examples just by searching "Minecraft leaflet map", one such example is https://minemap.net/.

The method for doing this is actually quite simple, and I had previously done this for procedurally generated maps. Using Leaflet.js, a Javascript library for interactive maps, you can point it to your map server which serves URLs of form /{x}/{y}/{z}, where z is your zoom level and x,y are your map tiles and it just works!

Currently if you open the game, then open the game in a different tab, then switch between the games the old instance remains stationary while the new instance continues to move.

We are currently updating position by checking if keys are pressed in an update loop. Phaser already has this built in as we can just add functions to keypresses. This is probably more optimized and also makes our code cleaner.

It would be good to know how everything is going to be set up beforehand. Specifics include:

• what is a player
• assets we need
• What do we want players to be able to do
• How are monster systems going to be set up
• How are we going to properly structure our netcode

There seems to be a server version and a client version of the current player. We need to only have one of these, likely a client so things are not as laggy, and then just check to make sure the client is at the correct location every so often.

This might come from The current client getting a message from the server about itself. We should not be receiving these messages and displaying a new player for the incoming message from the same player_id

A good start to handling client-server communication would be to declaratively define all message types. This would also mean we have some sanity on the types being thrown back and forth and all message structs would be defined in one place, making it easy to track what they are and where they're used.

• ProtoBuf.js (Javascript protobuf compilation)
  • Problem: How do we make it part of the automatic bundler compilation, i.e. with Brunch?
• exprotobuf (Elixir protobuf importing on compilation) or protobuf-elixir (protobuf compilation into Elixir modules)
  • The former option appears to be easier and a more widely used library

Consequently, we could use gRPC instead of websockets, but that's a future future thing that doesn't matter for now because websockets are already working and easier.

Currently when the player goes out of bounds the server player can, while the client cannot.
We need to check for bounds and only send messages if the client can do that action.