readme and notes
parent
3715a2f841
commit
0ffe80db86
18
README.md
18
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.
|
||||
|
|
|
@ -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 {
|
||||
|
|
Loading…
Reference in New Issue