4 ms·

This is amazing! I read everything. I completely agree about the state of the 'big three' engines. > My focus is still on browser multiplayer experiences. H

This is amazing! I read everything. I completely agree about the state of the 'big three' engines. > My focus is still on browser multiplayer experiences. Here's mine: earth.suncapped.com (https://github.com/Suncapped/babs https://github.com/Suncapped/babs) It's been ongoing for 12 years, with several burnouts and rewrites, hah. If you want, I would love to talk offline (email in profile) about player-freedom, MMO projects, and browser games. I feel like some of us have a shared history going back to older MMOs [0] and Flash browser games [1]. On my project, I sneaked past the hard networking problems by settling on tile-based movement. It worked for Ultima Online and I still believe in it. It scales really well. Networking zones measure 1000 x 1000, and tiles are 4 units, so X and Z can each be stored in 1 byte. This also helps with storing and transmitting tons of objects. See the page load time. Actually, I sneaked past a lot of difficult things, which is what strikes me about your work - you solved hard stuff directly. I haven't tried to integrate skeletal animations into my Blender pipeline yet. Yikes. I barely know how to write cameras, whereas you made a cross-platform one and blogged about it. > shared client & server game code How did this one go? I ended up literally doing a `ln` for shared frontend/backend files. > React+Redux setup was too much performance overhead for the real-time gameplay section. This is such an interesting aspect of web games: HTML-based UIs. I went with Svelte because I was curious about it. It is SO much easier than doing a game UI yes. But the "line" between web UI and game UI keeps being a problem. For example, when a player drags an object into a UI backpack: That object's graphic needs to change from 3D mesh -> mouse cursor -> png icon. Craziness. I might scupper the whole thing. A bit of a ramble, but in conclusion, wow!! Thanks for sharing this. 0: UO, Lineage, you said Exteel which I'd like to learn about. 1: (First Earth had a Flash version lol. Also a Babylonjs version.)

Vekz 3y ago
Thanks for reading and sharing your work! I host an indie gamedev coworking group in the bay area and on discord that you might find interesting. Will DM you. > How did this one go? I ended up literally doing a `ln` for shared frontend/backend files. Very easy with module imports. Same scene graph and entity component system shared between client and server.
- drcode 3y ago
  Greetings Vekz! Great to read your article! (Conrad from the coworking group)
nonethewiser 3y ago
> This is such an interesting aspect of web games: HTML-based UIs. I am neither a web dev nor (especially) game dev expert , but I recently came across this crossroads when building a small js canvas game. Should I use html elements styled with css for my game UI? After a very short time thinking about it I decided not to implement the UI this way. It seems like a good idea because html and css are easy to use. Much easier to style a button and assign it a js function than draw buttons on the canvas and check if they’ve been clicked. But I felt like it spanned a boundary that might prove hard to reconcile in some scenarios, but that was more of an instinct than a well reasoned conclusion. I’m curious what others think about it.
- fenomas 3y ago
  Personally I went with HTML for my web game UI and I've not had any reason to regret it. I mean game UIs are thorny and annoying, but it would be a lot worse working inside the canvas. My biggest surprise was, before I jumped in I figured there would probably be some existing "RPG inventory" libraries I could build from, that handled dragging icons around between icon slots etc. But I never found any game-oriented UI projects I could use, and ended up building entirely from scratch.
- SenHeng 3y ago
  Not a game but I once worked on a Miro clone. We used canvas for the... canvas part... but plain old HTML for all the UI elements as those don't need to be redrawn every time you blink.

Vekz 3y ago

Thanks for reading and sharing your work! I host an indie gamedev coworking group in the bay area and on discord that you might find interesting. Will DM you. > How did this one go? I ended up literally doing a `ln` for shared frontend/backend files. Very easy with module imports. Same scene graph and entity component system shared between client and server.

drcode 3y ago
Greetings Vekz! Great to read your article! (Conrad from the coworking group)

nonethewiser 3y ago

> This is such an interesting aspect of web games: HTML-based UIs. I am neither a web dev nor (especially) game dev expert , but I recently came across this crossroads when building a small js canvas game. Should I use html elements styled with css for my game UI? After a very short time thinking about it I decided not to implement the UI this way. It seems like a good idea because html and css are easy to use. Much easier to style a button and assign it a js function than draw buttons on the canvas and check if they’ve been clicked. But I felt like it spanned a boundary that might prove hard to reconcile in some scenarios, but that was more of an instinct than a well reasoned conclusion. I’m curious what others think about it.

fenomas 3y ago
Personally I went with HTML for my web game UI and I've not had any reason to regret it. I mean game UIs are thorny and annoying, but it would be a lot worse working inside the canvas. My biggest surprise was, before I jumped in I figured there would probably be some existing "RPG inventory" libraries I could build from, that handled dragging icons around between icon slots etc. But I never found any game-oriented UI projects I could use, and ended up building entirely from scratch.
SenHeng 3y ago
Not a game but I once worked on a Miro clone. We used canvas for the... canvas part... but plain old HTML for all the UI elements as those don't need to be redrawn every time you blink.