vilmibm
/
hermeticum
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

readme and notes

trunk
vilmibm 2022-12-30 00:16:20 -05:00
parent 3715a2f841
commit 0ffe80db86
2 changed files with 14 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
README.md
View File

@ -12,16 +12,23 @@ the alpha version of tildemush does work! you can script objects and make rooms
- has memory leaks - has memory leaks
- consists of very poorly abstracted spaghetti code - consists of very poorly abstracted spaghetti code
- has a half-implemented client - 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 brittle, very fragile, 100% hacks scripting language for game objects
- has a very inelegant and inefficient system for handling revisions to game objects code - 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. 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 - 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 ## 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. 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.

9
server/cmd/main.go
View File

@ -21,15 +21,6 @@ var (
port = flag.Int("port", 6666, "The server port") 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) { func _main() (err error) {
l, err := net.Listen("tcp", fmt.Sprintf(":%d", *port)) l, err := net.Listen("tcp", fmt.Sprintf(":%d", *port))
if err != nil { if err != nil {