From 0ffe80db86bb39afff8376344c82be8120c89359 Mon Sep 17 00:00:00 2001 From: vilmibm Date: Fri, 30 Dec 2022 00:16:20 -0500 Subject: [PATCH] readme and notes --- README.md | 18 ++++++++++++++---- server/cmd/main.go | 9 --------- 2 files changed, 14 insertions(+), 13 deletions(-) diff --git a/README.md b/README.md index d848eed..c95cf2e 100644 --- a/README.md +++ b/README.md @@ -12,16 +12,23 @@ the alpha version of tildemush does work! you can script objects and make rooms - has memory leaks - consists of very poorly abstracted spaghetti code - has a half-implemented client -- is extremely hard to add to (I gave up trying to do scheduled tasks) +- is extremely hard to add to - has a very brittle, very fragile, 100% hacks scripting language for game objects - has a very inelegant and inefficient system for handling revisions to game objects code I feel very strongly that a total rewrite is necessary. I also feel very strongly that Go is a better choice for this kind of application than Python. -## new technical stuff +## new stuff from tildemush - API is grpc/protobuff based -- client uses `tview` which I find more pleasant to work with that `urwid` +- client uses `tview` which I find more pleasant to work with than `urwid` +- WITCH is powered by https://github.com/yuin/gopher-lua +- a much simpler approach to script editing + - I'm going to take a much simpler approach to scripts than I did in tildemush: objects just get one text column for their script with no revision tracking. + - this can totally change in the future but I don't think it's necessary for a beta +- "cron" system: WITCH scripts will respond to a "tick" event and decide if enough time has passed for them to re-call their callback. +- "global chat" since it is my hope that hermeticum can largely supercede IRC on https://tilde.town , I intend to have an always available global chat in a pane in the client so users can feel like a part of a "main" while still wandering around and exploring rooms. +- "loudness" system. this is not fully designed yet, but events should be "audible" in a regressed way for objects that are contained by things contained in a room where a verb is executed. ## the name though @@ -34,4 +41,7 @@ wisdom. I like the idea of mapping these mental spaces into a computer. I haven't moved over any design docs or notes or anything like that. Refer to the tildemush repo for that kind of stuff. -to regenerate the API code: `protoc --go_out=. --go_opt=paths=source_relative --go-grpc_out=. --go-grpc_opt=paths=source_relative proto/hermeticum.proto` +## development + +- to regenerate the API code: `protoc --go_out=. --go_opt=paths=source_relative --go-grpc_out=. --go-grpc_opt=paths=source_relative proto/hermeticum.proto` +- database connection currently hardcoded to a postgresql database called `hermeticum` owned by `vilmibm` who has pw `vilmibm`. if you want to hack on this locally, update the call to `NewDB` accordingly. Eventually this will be handled via environment variables. diff --git a/server/cmd/main.go b/server/cmd/main.go index 5b0d37d..fb18c97 100644 --- a/server/cmd/main.go +++ b/server/cmd/main.go @@ -21,15 +21,6 @@ var ( port = flag.Int("port", 6666, "The server port") ) -/* - I'm going to take a much simpler approach to scripts than I did in tildemush: objects just get one text column with no revision tracking. to avoid re-parsing scripts per verb check (as every overheard verb has to be checked against an object's script every verb utterance) i want an in-memory cache of lua states. i'm not actually sure if the goroutine unsafety is a problem for that. if it is, i can put goroutines in memory and send them verbs over channels. annoying, but should work if i have to. going to start with a naive map of object ids to scripts, re-parsing them if they get edited and updating the cache. - - The cache will grow without bound as users enter rooms with objects. they ought to be garbage collected. i can do that in a goroutine though (check DB for objects in rooms with no players). One complication will be when I have "cron" support for objects. they will need to be "live" (ie, their scripts executable) in order to do their periodic tasks. - - An idea I just had for a cron system: respond to a "tick" verb. at server start, once all in-world objects get parsed, start emitting "tick" events from a for loop in a goroutine in rooms with objects. this can be optimized for having a way to flag periodic-able objects so they don't get the verb if they wouldn't respond. - -*/ - func _main() (err error) { l, err := net.Listen("tcp", fmt.Sprintf(":%d", *port)) if err != nil {