Skip to content


Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time


hey this thing sucks rn don't look at it

what is this

sledgehammer (working title) is a browser-based game for 1-4 players, featuring peer-to-peer multiplayer. it's basically a clone of crossroads for the c64.

originally i was building it with no framework, trying to use a redux-ish control flow, but eventually i got really frustrated with how difficult i was finding that to architect, and instead rebuilt it in pearl, a component-entity game framework. this has been going okay, but has involved building a lot of scaffolding on top of pearl to support online networking, and it's currently pretty hacky.

it uses webrtc for networking, powered by simple-peer and a lobby server i wrote called groovejet.

how do i play it

it's currently live at

how do i run it

to run:

npm install
npm run dev

you'll also need a groovejet server running

what's left to figure out

this is a long-term-ish planning list and not meant as todos; that's living in a workflowy document.

how to only send changes over network

goals: less data sent, less cpu used updating, allow memoized rendering to work on the client w/o special logic

  • store shallow of each serialized component
  • diff copies against each other
  • maybe do deep copies for e.g. vectors? but eh
  • watch out for arrays/lists - unity has a special SyncList[PrimitiveType] class for this
  • unity serialization happens on NetworkBehaviour:
  • unity also passes a initialState bool to both serialize and deserialize functions to differentiate between initial serialization and subsequent updates
    • this would work for World/TileMap, since session destroys and recreates it!
  • godot just has like first class rpc stuff which, idk, seems neat, but requires manual sychronization of everything as far as i can tell

also a big thing here is potentially using udp-like semantics, since webrtc gives you a choice. this would be good for snapshots, but not so good for RPC-like things (e.g. if i end up adding separate "entity created/destroyed" messages, or player input messages). think i could create two different channels per peer to solve this?

how to maintain object hierarchy

goals: allow e.g. world to own entities, make cleanup of scenes easier

thoughts on collision

i'd like semi-automated collision stuff. basically have some concept of collision layers, and some sort of collision protocol? and possibly automated collision resolution (by preventing collisions from happening in the first place)?

  • collision protocol
    • so a preresiquite for automated collision pairing is that I need to be able to say obj1.isColliding(obj2), which isn't a concept that currently exists right now
    • basically need an obj.getCollider()
    • maybe this is something like obj.registerCollider(component), then obj.getCollider()
    • obj.registerCollider could happen within collider creation. could also check for existing collider and error out if there is one
    • then if obj1.isColliding(obj2) is passed, it actually calls obj1.getCollider().isColliding(obj2.getCollider())
    • this does mean that in some cases you'd end up with "obj1's collider knows how to handle obj2's collider, but not vice versa", which is really tricky :\
    • maybe won't be an issue if tileMap walls get turned into collidable entities...
  • can maybe consider automated collision resolution but it'd be a stretch, especially in a tile-based world
  • collision layers...


No description, website, or topics provided.






No releases published


No packages published