Skip to main content

One post tagged with "review"

View All Tags

· 3 min read
Harry Nguyen
Lyly Nguyen
  • There are support libraries for games
    • mymes -> Send message
    • myrank -> Top player info
    • my history -> game history
    • my pot -> game jackpot
  • EDK:
    • WS Handler
    • Authentication
    • Payment
    • Agones
    • Merchant management
    • User management
  • Can run standalone service

Points Of Satisfaction

  • Have HTLM to call to cheat . Easy for QC test
  • The features already have libraries to address common features
  • EDK
    • Good for integration
  • Game setting: enough to build the setting & allow http.

Points Of Dissatisfaction

  • There is no documentation page for aggregating documentation
    • Getting started: Introduction for beginners in game development
    • Functions of libraries
    • Diagram illustrating the structure of a standalone game
    • Integration with 'gateway' or something similar
  • Game cloning speed
    • There is no standard document for quickly cloning a game
      • How to design proto?
      • How to implement logic?
  • Logic game
    • There aren't flow chart to describe the implementation flow (Session, channel, message, user-actor model.)
    • When looking at it for the first time, you don't know where to start
  • UnitTest
    • There is no local test for testing the game -> So the deployment must ensure the logic of testing

Points for Improvement

  • Add libraries into mykit to Init project

    • Include common code libraries to avoid having to copy (mymes, myrank ..)

  • Create multiple channels in a service

    • Why not create multiple channels -> Users can play on various different channels for one game
    • Reason:
      • Currently, users are opening multiple tables and can place multiple bets in one game -> I have observed that users often do this
      • Currently, Long Hổ uses library protoactor.NewActorSystem to support multiple channels -> actor_system -> channel_actor -> user_actor => We should use this advantages

  • Define proto according to a specific template, with clear divisions

    • game.proto: Defines the API for a component or service. This typically specifies the remote procedure calls (RPCs) and message types used for communication.
    • game_model.proto: Defines the object models or data structures used in your application or system. These models are often used to represent data in a structured format.
    • game_config.proto: Defines the configuration settings for your application. These settings can be used to customize the behavior or parameters of your application.
    • game_code.proto: Defines error codes and possibly error messages that can be used in your application to handle and report errors.
    • game_butler.proto: Defines APIs specifically for operators or administrators to manage or control aspects of the system.

  • UnitTest

    • Auto Team will build standard test to call and test local witch connect to stg.

  • Logic game

    • There should be a flow chart to describe the implementation flow

Conclusion​

  • We need to improve the structure to shorten the game development time for developers. Allocate time for enhancing logic and performance.

Reference​