I havn't felt too good this and as a result I havn't accomplished anything particular. I have mostly stayed in bed and researched on the internet. But I have managed to write a little. I've implemented what I think could work as a memory pool, to avoid constant allocations. This is managed by my custom pool class and accompanied pooled_ptr<T*> smart pointer class. Its a lot like the std::shared_ptr, but instead of deleting it's content in it's destructor, it returns it to the pool. All the memory is deleted in the pools destructor.

I've also made a simple thread pool, which handles std::function<void()> objects. Thus you can't really use it for futures, which I would like it to. But I have made a wait() method, which blocks until all tasks are complete, so some basic synchronization is available. I really need to figure out a way to return values reliably. Which made me realize that the concurrency.hpp part of Ocius is horrible and terribly broken.

I feel fairly done with the basic functionality in Ocius and have started work on a game engine using its technology. This is hard. I want to have very generic game engine and just plug my game logic and specific stuff into it. I've been looking around some on open source engines and researched actual games. I think I might, possibly, have an idea now. I will look further into this in the coming weeks. I will publish more about this when I have it worked out. The basic idea however, is the Event and Actor/Components based approach advocated by Game Code Complete. This system is already done. What I'm working on is the bootstrapping process. I want to load some sort of config to the logic, and then send all the required information to all attached clients. But then how does the clients access the information they need? ie. the actors. If they plug straight into the logic, and bypass the Event system, it defeats the purpose of it. Also it makes multiplayer functionality harder. A alternative could be to serialize the actor and send it via an event when it spawns. This however introduces duplication, and it might be a hassle to synchronize everything, not the mentions the waste of memory. Separating the client/view/graphics from the logic is a known problem in game programming. There has to be a way. Secondly the graphics part of the client causes some issues. I could write on this for a while but I'm gonna skip that for now.