3 ms·

I can say as someone who fell in love with coding that doing it professionally did not extinguish that fire. Still spent 12 or so hours doing game dev this week

by and0 5y ago

I can say as someone who fell in love with coding that doing it professionally did not extinguish that fire. Still spent 12 or so hours doing game dev this weekend, and a few hours every night this week. e: To clarify I started learning in 2013ish, became a full-time dev in late 2015. So 6 years later, still finding joy in the day-to-day, but definitely have a special fire for the pipe-dream projects.

EarthLaunch 5y ago
That makes me curious what project you're working on, and you might be interested in my own pipe-dream project! There's a playfulness in doing something seemingly impossible, because succeeding at it simply means having fun playing with it.
- and0 5y ago
  TL;DR multiplayer roguelike (or general tile-based) framework in Typescript https://github.com/and0p/chaos-core https://github.com/and0p/chaos-core
  - EarthLaunch 5y ago
    Oh very cool. You wrote your own ECS. I toyed with ECSY but realized it's not performant for games. Opinionated event messaging hmm. Mine's a low-res MMO client/server in JS. I loved Ultima Online and experimented with 'military' isometric projection, but landed back on 3D.
    - and0 5y ago
      Yeah! More accurately just EC, no real systems here. Roguelikes are highly deterministic and are not real-time, so a system updating all its respective components for every "tick" wouldn't really fit. The biggest obstacle with roguelike development is the way the components that make up an entity have to communicate in an agnostic way. Think if a wizard tries to freeze a warrior, where in the code/flow do you specify if that is or is not allowed? And what happens when you have extreme edge cases like if a specific area, a status applied to a teammate, or some random event nearby maybe says that the warrior is actually immune to being frozen? And what if the wizard's freeze spell is so powerful that it can ignore all of those obstacles? The approach I went with is that the EC side is relatively basic but all the components can optionally tap into a flux/redux-style event system, and those messages are very powerful in how they allow themselves to be modified or permitted/allowed while being deterministic. (And of course the message system allows for easy client/server logic, and super easy unit or integration testing of gameplay systems which hasn't felt like anything I've used before.) I'm quite liking it so far, hoping to have something more concrete in 5-6 months.

by and0 5y ago

EarthLaunch 5y ago

That makes me curious what project you're working on, and you might be interested in my own pipe-dream project! There's a playfulness in doing something seemingly impossible, because succeeding at it simply means having fun playing with it.

and0 5y ago
TL;DR multiplayer roguelike (or general tile-based) framework in Typescript https://github.com/and0p/chaos-core https://github.com/and0p/chaos-core
- EarthLaunch 5y ago
  Oh very cool. You wrote your own ECS. I toyed with ECSY but realized it's not performant for games. Opinionated event messaging hmm. Mine's a low-res MMO client/server in JS. I loved Ultima Online and experimented with 'military' isometric projection, but landed back on 3D.
  - and0 5y ago
    Yeah! More accurately just EC, no real systems here. Roguelikes are highly deterministic and are not real-time, so a system updating all its respective components for every "tick" wouldn't really fit. The biggest obstacle with roguelike development is the way the components that make up an entity have to communicate in an agnostic way. Think if a wizard tries to freeze a warrior, where in the code/flow do you specify if that is or is not allowed? And what happens when you have extreme edge cases like if a specific area, a status applied to a teammate, or some random event nearby maybe says that the warrior is actually immune to being frozen? And what if the wizard's freeze spell is so powerful that it can ignore all of those obstacles? The approach I went with is that the EC side is relatively basic but all the components can optionally tap into a flux/redux-style event system, and those messages are very powerful in how they allow themselves to be modified or permitted/allowed while being deterministic. (And of course the message system allows for easy client/server logic, and super easy unit or integration testing of gameplay systems which hasn't felt like anything I've used before.) I'm quite liking it so far, hoping to have something more concrete in 5-6 months.