To Watch a Machine Churn...
sdxm saelee eastfist machine gears 2D game engine design practical efficient
We're software engineers. We observe the world around us and try to simulate it via coding. That's what we do (some for a living, and others like myself for a hobby). It's a challenge to make incredibly innovative, yet intuitive software. If we designed software as stylish as "raining code" like what is depicted in The Matrix films, we'd probably get a ton of feedback from users telling us how impractical it is. Sometimes, we can "see" it all in the code, but we can't forget that we still have to abstract it enough so that it becomes as "real-worldly" as possible. That means we have to base our software design on the world around us.
This reminds me of a feature implementation where a user suggests to have the arrow keys on a keyboard mapped backwards. For example, the user wants the right arrow to move an object left, and vice versa. For the sake of practicality, it doesn't make sense, does it? If you were driving a car, an incredibly practical process, would you want the car to swerve left when you turned the steering wheel right (when driving forward)? This is an example of observing and implementing real-world practicality.
So when I'm developing my version of what seems to be the ubiquitous hobbyist's 2D game engine, I'm going to think in terms of animation. I could think on the level of physics and box collision and a tiny plumber that bounces off mean-faced mushrooms, but that's another level of design concepts. Firstly, I don't want my engine to be physics-based because I'm not creating a simulator. And lastly, I could try to copy what's been done by Nintendo with their Mario games for a learning practice, but then I'd be wasting time developing their gimmicks rather than building a solid, efficient core for my engine. So what I want is a solid animation engine.
In animation, you take an image painted on a transparent cel and overlay that onto a pre-painted background. You take a picture of that and put the next cel onto the background. You repeat this process for countless frames until you get the illusion of movement, or animation. So, at it's most basic, that's what a game engine should be seen as. Except, you throw in the interactivity. Otherwise, duh, it's just a movie. Das why it's called an "interactive video game", Paw!
Imagine watching an industrial machine run. What if you wanted to simulate that process in a quick program? Let's say you have a pulsating yearning to write up a sticker labeler simulator. I suppose the size of the stickers don't matter. But where they're stuck onto does matter. You don't need to know what kind of adhesive it uses, nor the ink printed on it. All you need to know is the sticker goes onto whatever object it goes onto.
Finally, you're at the helm of the control box. You can control where the stickers go. And production wants all 3,000 products labeled... FAST. If everything goes correctly, the machine should give the appearance of absolute competence. If not, I suppose a movie of the machine running could be edited to make it seem sensationally competent and the most interaction you'll have with it is twiddling your thumbs.