Allocators for game engine

I am currently coding a memory allocation system for a game engine, and I was wondering if there were any experienced developers out there who could help with some advice about what allocator structures are useful.

I know that sounds a bit worrying to some people, and so I think I need to justify my position a little bit. I have read the answers here and here (and also the blogs they point to here, here and here). But see, I have tried the "make a game first, over and over, and then the code you reuse is your 'engine'" thing, and it didn't really work for me. I found that I actually got bogged down in those things I was doing again and again (probably didn't reuse my code very well) and didn't get very far in any game.

So, I decided I would code these things that I was reusing over and over again once more... do it once and set i开发者_运维知识库t aside.

I really found myself out of my league, so I bought a few books. Game Engine Architecture by Jason Gregory (GEA) is really good, btw, but I also have Game Coding Complete (McShaffry) and Programming Game AI by Example (Buckland). GEA has some really good ideas about high performance allocators, and that really interested me, so I thought I would give it a go.

I have coded a stack-based allocator, and am nearly finished a pool-based allocator. Both have the capacity to be memory aligned and can be assigned to work with different memory budgets (i.e. any allocator could for example use "retail" memory or "development" memory etc). I have found just creating these components such a rewarding thing in terms of my programming skills/interest level.

I am wondering if there are any developers out there who would be willing to recommend any other allocator structures that are useful or come up regularly in game development. ? Or if there are any developers who have never used anything else in their entire careers?

Again justifying my question (I can nearly hear people whispering "Just make your own game and see what structures you need...", but...) Game Engine Architecture has been such a great resource for me because the author is willing and unashamed to say "hey, this is what the industry mostly sorta does". And it would save me a lot of time writing a whole heap of games and figuring it out what is useful, if somebody can do some 'experience-reuse' and say 'think about this structure'.

Seriously, the biggest obstacle to writing a game is thinking you need to design all kinds of fancy library code first. Most games need this kind of thing much less than any other type of application. Games almost always deal with a very finite number of data/objects determined mostly by the deverlopers and only slightly affected by the players' actions (massively multiplayer games being the only possible exception to this rule) and as such you can even get by making static arrays for all the data if you're slightly crazy.

Unless you're developing for PlayStation or other console junk with a broken standard library, you should not even think about writing your own allocator. It's completely orthogonal to game development and a waste of your time. This is 2011 not 1992 and you're not dealing with DOS systems with 2-4MB of ram where you have to manage your own data caching and discarding. Let the virtual memory system do the work for you and spend your time making a game, not half of an operating system.

Well, honestly, the ones I've been using most are Pool<T> for short-lived objects and pre-allocated heap as a replacement over C++ default allocator.

But once again, develop what you need when you need it.