Comment by ajuc | Hacker News Reader

Comment by ajuc | Hacker News Reader

Right now I'm trying to learn clojure, and write 2d arcade game with it. I've encountered similar problems (almost everything should be passed almost everywhere), but I think this is actually good thing to choose what part of game can change what beforehand.

My architecture (so far - it's in early planning stage): 2 threads (physic and logic thread going 10 Hz and graphic thread going as fast as it can drawing world)

objects are struct-maps with fields position, animation frame, life etc (all fields are functions of time, and can change between physic thread turns, but not in one physic thread turn).

Graphic thread just gets time and for each visible object draws it at current position (calculated from time by objects position function). So movement should be smooth and not dependent on frame rate.

physic thread in response to player input calculates new functions for objects (only for X next turns). These new functions are encapsulated in event objects, that are added to events priority queue.

On each turn (of physic thread) events for that thread are executed - each event takes set of game objects (not always all objects) and time and returns changed set of game ojects.

In C++ this will be much easier to write at first (no hard thinking needed:)), but later it could become nightmare to change because of side effects.

It sounds like you are overengineeing it.

Modern computers are fast; Program it naively and if you see it's too slow (which it probably wouldn't be) optimize the bottlenecks.

I am pretty sure you wouldn't need to make this multithereaded.

i thought it sounded pretty clever

"Clever" and "overengineered" often go hand in hand :)

But lets not lose sight that without a little bit of cleverness and overengineering we'd still programming in machine code. Also it seems to me that pretty much every popular programming language out there (PHP, C++, Java, Python, Ruby, Erlang, etc.) is the result of overengineering and cleverness.

The few languages that aren't overengineered are the ones that either have a very specific domain (JavaSript), slow to change standards (C), or are very new (Clojure).

OP's idea also doesn't sound very over engineered to me. The whole draw loop thing is simply a convention and not an obvious one. I've taught many a student who stumbled on the idea of the render loop because there's simply nothing natural or obvious about it.

In the real world everything happens at once, there is no update-render-loop. Snapshoting the state of a multithreaded physics engine at discrete intervals in order to render the game state is much closer to a model of how we perceive a fully concurrent reality.

in this case it's a good way of getting smooth animation specially in a dual core whatever whatever :)

Perhaps he's more interested in experimenting with this kind of architecture?

I know it's over the top, but it's to try sth different for once. Also - multithreading is because my earlier games was in one thread, and I've always had problems with consistent framerate - some frames was longer, some shorter. When I tried considering last frame duration as multipilier, game became not stable (too long frame and bullets will fly throught the wall, etc). And networked game is difficult to get right with nonuniform duration of frames. So I try to see if this will be better.

What's for sure overenginered is using function of time instead of simple numbers for positions. But that is just to make it different.

I definitely consider it an overreaction to call the described approach over-engineering. Separating simulation and presentation in to separate threads is common and very practical in many games (2d or 3d). It is also common and easy to support a single threaded mode that just runs both simulation and presentation update from one thread. The single threaded mode can make debugging certain issues much easier, but it is rare to have a desire to ship single threaded.

This sounds really interesting! Any chance you want to throw it up on github etc?

Thanks, yes, I'll release it when it's ready.

Reply on news.ycombinator.com