TODO 2.1 KB

123456789101112131415161718192021222324252627282930313233343536
  1. Just a bunch of thinking notes:
  2. Basically, nearly everything need to be redone.
  3. - The network protocol can't be used as is and need to be redesign considering the new constrains
  4. - gclient and meta-client should be merged
  5. - maps converted to JSON (done 2players.map.json as an example)
  6. - server is the one to deal with the SQL database (if kept)
  7. - Agents (players AI) need to run on the client side (prevent potential hack and crash on the server side)
  8. - Network protocol need to take account of that and use some form of RPC and sync messages (Maps) (should network use
  9. JSON messages? or binary?)
  10. - New "heavy" client using glfw & imgui
  11. - server split in two part, one for running a game (can be just a thread), the other for all the rest
  12. - only lua supported at first, may add compiled languages after, but both run anyway on the client side.
  13. - a form of ECS on the client side?
  14. - Should we have a tilemap engine + sprite or the 2D display, using quad for sprites and quad per tile? (would like to
  15. avoid creating another "framebuffer" based app)
  16. - The client need to have an editor for the selected language so no need to exit to edit the bot.
  17. - Two mode for client map, normal where only seen data are provided, debug where the whole map is provided (to prevent
  18. potential cheating)
  19. - Time constrains need to be kept (it is part of the game design) but instead of killing, just ignoring the commands
  20. if came too late?
  21. - Most bot function can be done locally by the client from the map state, only move/action order need to be sent to the
  22. server. As the game is somewhat turn based, we can batch all the commands to the server.
  23. - The network should be used on top of a SSL layer (not fun but don't want to send thing in clear, especially if there
  24. is any form of login)
  25. Even more random:
  26. - Do we really need the server to be in C? Other than potential performances issues, Python could be easier to maintain
  27. and make some of the server side of things. "heavy" client need to be native though.
  28. Ideas for later:
  29. - 3d view of the map, just for the fun
  30. - proper fog of war
  31. - Potential HTML based client. JSON as protocol would help a lot here.