Infrastructure Plan

We will be developing this project in 2 parts: frontend and backend. We will develop in this order:

  1. Frontend game logic
  2. UI
  3. Backend game logic
  4. Backend api
  5. Connecting to the backend api through frontend

Of course we will return and improve stuff from the previous steps, this is more of a general guideline.

Frontend Game Logic

We will implement the game in typescript with object oriented paradigm. This step should not include anything to do with the ui ( decoupling ).

UI

We will implement the ui in Angular, we will be using services and observables (link) to setup a further-developable system.

Backend Game Logic

We will implement the game in Go using interfaces and structs. Main problem with this approach is that we will be duplicating complex logic for both frontend and backend. One solution to this is that we can send necessary data to frontend from backend. But this approach has problems as well, mainly reduced ui responsiveness.

Seperate Logic in UI and Backend Logic Only In Backend
Bugs High risk of introducing bugs. Lower risk of introducing bugs and easier to debug.
Responsiveness Better responsiveness. Lower responsiveness which gets progressively worse as connection quality decreases.
DX Have to implement the same logic in two different languages. Have to implement only once.
Ease of building new features Having logic on both sides opens up more possibilities for tooling and features, but also slows the development of these features. For example, lets say we want to develop an antichess like variant to our game. We would need to implement this variant in the places again. Easier to build new features. But may lacking in tooling for frontend. For example lets sey we want to build a custom position builder where players can start from their input position to an online game or bot game. We would need to implement some logic on frontend, but not all the game which might make it awkard.

Seems a though choice... But what if I told you there exists another alternative?

There's no way I'm going to stand up for bad ingredients. We love seasonal ingredients. It's a false dichotomy to say that modern cooking is at odds with that, but some people want to have a great ingredient and no technique.

Nathan Myhrvold

We can implement our game logic in go, then compile it targeting WASM. This way, we get best of the both worlds!

Seperate Logic in UI and Backend Logic Only In Backend WASM Target Client
Bugs High risk of introducing bugs. Lower risk of introducing bugs and easier to debug. Low risk of bugs and easier to debug.
Responsiveness Better responsiveness. Lower responsiveness which gets progressively worse as connection quality decreases. I don't know. Some say wasm has bad performance.
DX Have to implement the same logic in two different languages. Have to implement only once. Have to implement only once.
Ease of building new features Having logic on both sides opens up more possibilities for tooling and features, but also slows the development of these features. For example, lets say we want to develop an antichess like variant to our game. We would need to implement this variant in the places again. Easier to build new features. But may lacking in tooling for frontend. For example lets sey we want to build a custom position builder where players can start from their input position to an online game or bot game. We would need to implement some logic on frontend, but not all the game which might make it awkard. Easier to build features with almost no drawbacks.

But first we will implement the logic in ui via TypeScript first. After we have a working prototype we can move onto compiling to WASM and make sure we have only one implementation of grant acedrex logic.