I've written an actual game, a 2D platformer.
If there's a domain where it's easy to demonstrate that the view is purely a function of the state it's precisely in gaming. In many games you can toggle (in dev or even for some during gameplay) between "the real view" and, say, wireframe view of the game (with lots of debug infos added too for example). Or you can toggle between a 3D view of your game or a top-down 2D one. Or you can toggle between different types of rendering (as in Diablo 2 where both a 2D and fake 3D view where available and the modern Diablo 2 ressurected, where you can you can show... The 25 year old view if you want to, at any time).
Many games are 100% deterministic and the entire game user(s) played can be recreated from only a record of the user(s) inputs (which is why some save files for long games can be tinier than tiny). And it'll replay the same on different screen configurations / different platforms.
The view in a game at time n is literally f(state n).
> real game
turn-based and real-time games have different kinds of complexity, so a platformer won’t expose you to all of it.
turn-based games are roughly going to give you an easier time separating the game code, but the UI code is going to feel like a debilitating slog.
> Many games are 100% deterministic
Until you use floating points, networking, or different platforms.
This is more likely to be true in turn-based games, and super unlikely in anything real-time and multiplayer.
Most games like that periodically sync state instead of relying on applying actions on each client
64-bit x86 and modern non-x86 architectures are usually deterministic for primitive operations at least, but libm differences abound.
It’s different behavior if the order of operations are non-deterministic.
Plenty of room for such things in games. Most of the time the effects are too small to notice. They can chaos-theory out of control, though.
So real time games nearly universally sync state instead of relying on deterministic synchronization via events/actions.
For a good read, look up lockstep deterministic networking.
There’s way too much nuance here to be so dismissive
Come back when you have things worth contributing.
This might explain why you aren't a genius. He's not saying anything that hasn't been featured on HN before.
This is a popular article: https://www.gamedeveloper.com/programming/1500-archers-on-a-...
It details how Age of Empires decided to make the game deterministic, how this had significant benefits, and how it's extremely difficult to do:
> At first take it might seem that getting two pieces of identical code to run the same should be fairly easy and straightforward -- not so. The Microsoft product manager, Tim Znamenacek, told Mark early on, "In every project, there is one stubborn bug that goes all the way to the wire -- I think out-of-sync is going to be it." He was right. The difficulty with finding out-of-sync errors is that very subtle differences would multiply over time. A deer slightly out of alignment when the random map was created would forage slightly differently -- and minutes later a villager would path a tiny bit off, or miss with his spear and take home no meat.
Do you think you look good by announcing that, since you don't know the subject you're discussing, you're not going to trust someone who does?
So not only was I insulted, I was insulted even though I was right. Also I have studied chaotic dynamical systems, so I have formal education in this.
The interesting thing about chaotic systems is that they have very divergent futures for very similar inputs, not that they're random.
Also I don't really care about being considered a genius, and I think it's sad that anyone would want to be thought of as one.
> The interesting thing about chaotic systems is that they have very divergent futures for very similar inputs, not that they're random.
If you were paying attention... that's exactly what ape_key was referring to. The problem under discussion is that very similar inputs to the game logic lead to radically different states of the game at a later time. The nondeterminism is what gives rise to the fact that the inputs are "very similar" rather than "identical".
- more performant and responsive than most company applications
- while displaying complex real time geometry
- pretty well engineered
- fun and engaging
- didn't require reading 500 page manual to get byFor example, to make even a "simple" game on something like Boardgamearena, you're supposed to create a state machine: https://www.slideshare.net/boardgamearena/bga-studio-focus-o...
I don't even know what that is, and it's a lot more complicated than anything I'd ever seen on the frontend in the HTML/JS world. (To be fair, that's probably because I never had proper CS training. I'm just a self-taught web dev.)
But it seems to me that even simple games require creating really complex engines that aren't really similar to the businesses needs I've coded for in the past...
Not disagreeing with you at all, it all just seems so overwhelming compared to simple stuff like HTML/CSS/JS.
A lot of people got drawn into the industry in its latest boom and found themselves glueing together remote services using an ever-changing collection of heavy frontend frameworks and never experienced actually modeling an application from top to bottom. It doesn't need to be a game, but doing more of the dirty work that "[you] have no idea how to model" andis "more complicated than anything [you]'ve ever seen" can help induct you into a much richer and more cognizant craft practice.
To me, it's a lot clearer how to deal with a traditional ecommerce database setup like Northwind Traders (https://en.wikiversity.org/wiki/Database_Examples/Northwind). I've had to do that many times and know how to model such a thing.
I have no idea how to start modeling the state for a game like Wingspan (https://boardgamearena.com/gamepanel?game=wingspan), much less something more complicated, like Magic: The Gathering, where any of several tens of thousands of cards can interact with each other in novel ways, maybe even leading to infinite loops and such. In my mind it's like a giant if-then flowchart with a billion flows. I wish I could see the source code for the rules engine of such a thing, but with a step-by-step tutorial...
It's in English rather than computer code, but it sets out the data model and game loop in a way that should feel pretty familiar to programmers.
If you’re past the complexity threshold for Next.js, you’ve run into what’s really probably the most fundamental construct in computing.
They’re not that complex. They’re just presented in academic language.
If you can program professionally, you’re very capable of self-studying a bachelor’s degree’s worth of CS.
In terms of the logic, I wrote an entire platform to simplify multi-player board games which I'm evolving to tackle various businesses. https://www.adama-platform.com/
One thing I will caution is to not try and lean into making DOM layout do what you want. Represent the different elements as divs that are absolutely positioned, and you can go a long way. You'll probably still want a lot of seemingly duplicated data in places that you control directly, but that is part of the point.
scrolling - both in terms of event dispatch, and in terms of sizing (incorrect absolute positioning can break this), possibly focus as well. I don't pretend to understand under what exact circumstances the spacebar works for pagedown, but it's certainly something that fails often on fancy webpages but works intuitively on simple ones.
copy-paste. No, middle click is not just another way of meaning ctrl-v, I want the correct buffer dammit!
rich text editing is poorly supported however you do it, but be sure to have a fallback to a plain text mode that uses the browser controls
I'd be surprised if copy/paste is something you want in your game. Scrolling for a game is again something you probably have specific ideas on. You could make it so that a side scroller builds everything so that html scrolling gets what you want. Odds are high that you'd have an easier time taking over a lot of that on your own. (Indeed, this is essentially how popular mapping "tiles" work. You don't have all tiles in the DOM, but play with the ones visible to work as desired.)
And what I mean for absolute positioning is more in line with what I do in https://taeric.github.io/cube-permutations-1.html. And even there, I do not keep some things in state such that I have no control over the actual path a face travels as it moves into its new current spot.
Also event-driven programming. (especially the idea of delaying effects, e.g. so in an RPG someone can perform a Reaction which disables the effects of an Action performed by another character before they’re applied).
Learn about stacks.
When you’re ready to make your brain bleed a little, try designing on paper the data structure to make D&D turns work.
Hints: player initiative is a circular array, reactions are a stack, actions/reactions are events. Actions are events which modify characters, reactions are events which modify other players events.
Ignore abilities which e.g. create new terrain or whatever. Ignore movement, positioning, targetting entirely.
This will be fun!
Also I can recommend the free book Game Programming Patterns. It’s useful for programming concepts even if you don’t make games
I remember the first time hearing about them and being totally confused by the wikipedia page. I think the first article that made sense to me was this one, because it used a webapp example: https://www.infoq.com/articles/robust-user-interfaces-with-s...
And then developing a few sample applications, especially with Elm or another language with custom types, really completed my understanding. The diagrams and math notation are more intimidating than the actual code.
Doodling on paper (or just mentally envisioning a data structure) is way more fun than writing actual code.
I certainly would dissuade the OP from trying Elm. Not as part of learning state machines at least. Too many things at once and not necessary.
Instead I would attempt to do some kind of action game with the 2D canvas context. You might start by just trying to get a dot moving around with the keyboard arrows. Do a little research into a very basic “game loop”, which is basically.
function update(){ //handle the input //do some other stuff }
function draw(){ // render code here }
Once you get a ball moving around, tweak you program to add something else, like giving the ball gravity. Then add something else, like making it bounce off the sides of the canvas. Keep doing this until you have a basic game. You really only need to know a handful of techniques to get something basic working, and from there you’d be surprised at how far you can go. Don’t worry about code quality or trying to do it right, just try to figure out how you can get the game to the next step.
Biggest one being that anything you want to be able to do visually has to be represented somewhere as state. Pretty much period. And this state will be far more complicated than the simplified state diagram that you will come up with if you are only modeling the intended actions of a game.
If you are lucky with extra computing power, you can layer your code so that the core rules of the game are able to be written independently of how you represent the cards in play. But I assert that you will often be surprised that accomplishing this separation is more code than the alternatives.