lundi 28 janvier 2019

Design - Alternative to Storing Executable Code in SQL

I'm working on a little browser game, and I've hit a design problem and the only solutions I can think of are bad.

Its a typical web-app - Angular2/HTML/JS front end, Java server with PostgreSQL DB, content hosted on nginx and Tomcat

Users can interact with various NPCs who all have custom behavior. I've genericized this logic, NPCs are stored in the DB as config rows, ID: 1 Name: Sam The NPC ImgURL: "http://bit.ly/2COdmca"

Accessing mygame.com/npc/1 issues a GET in JS to the backend API in Java to get that row from the DB and those values are bound and displayed. Storing these as config rows in the DB allows me to add new NPCs or edit existing ones without a redeploy of the server or the front end code.

So far so standard. However, I want Sam the NPC to be friendly, and visiting him increases the player's money. Another NPC, Steve, should be hostile, and remove money or items from the players inventory. Bob the NPC can, sometimes, unlock a quest for players.

This is where I'm stuck: Each NPC having totally different and arbitrary behavior means I need executable code per NPC.

My two options, as I see them, are both bad but in different ways.

  1. Each NPC gets his own Java class and is a first class entity in the server logic. All NPCs implement an interact() method and adding or changing NPCs requires a code push.

  2. Each NPC gets a new column in the DB with executable JS in, to be run via a script engine in Java. This is slightly dangerous, but also just a hassle. Writing JS that can invoke DB functions by interacting with the Java codebase and then saving it as a string in a database is kludgy.

I'm currently using option 2, but not too far in and wondering if there's an accepted way to handle something like this that's better.

Aucun commentaire:

Enregistrer un commentaire