1. All resource needs to be carefully managed, the best way to do that is using IUnkown like interface. Every time a resource is acquired, the code increases the reference count internally, and the client releases the resource externally, which decrease the reference count.
2. Basic stuffs need to be thread safe, things like basic data structures: queue, link list, etc. and memory allocation functions. All lock-free algorithms are very good candidates but it’s very hard to get it correct; Anyway, it’s worth it. For the lock-free ABA problem, an iterator can be used to indicate an element is referenced by a client. When the iterator moves away ( ++ or -- ), or get deleted, the reference count of the element can be decreased. This provides good way to manage the delete items for non-managed code.
3. for the memory management, several points need to be taken into account:
   1. It’s useful to remember the caller thread ids,  source filename, and line numbers for each memory allocation in debug mode. So it’s very easy to find out where the memory leakage happens.
   2. An allocated memory needs two memory guard bytes, one at the beginning, and one at the end. It helps to find out memory overflow problem
   3. Memory reference count and allocation count is very important. It’s the first place to detect memory leakage.
4. For a good game editor here are several points:
   1. It should be a MVC architecture, and use the events to update the view from the controller, not the model!!!!!!!
   2. The model data should be like an object database, for all objects in the database, they should share a common interface for object management. And each object should have sibling and children data structure support for maintaining a well-defined, flexible object database structure.
   3. All tools logic should be happened in the controller. But the controller can be separated into two parts: a command line based controller, and GUI based controller. These two parts can be independent from each other, or the GUI based controller is based on the command line controller.
   4. The rendering is really not a big deal, but the key problem is the events that require to update the UI element from the controller may overwhelm the graphics capability. So the good way to design the view is maintaining an update requests cache and only do one update for the UI element if there are several same update requests from the controller.
   5. C# is the best choice for game editor (This is the really my point! )
5. For the graphics pipeline, there are the things are necessary at the build time:
   1. Collapse model, which made a single vertex buffer and index buffer for all the models in a scene. So this may introduce some limitations, but it can reduce draw calls a lot.
   2. Vertex sharing is very very important. But I really want to know the different between using one stream and the using multiple streams for the vertex data sharing. Just don’t have enough time to try.
   3. Materials need to be merged and sorted first, same material with different parameters needs to be grouped together to minimize the states changes.
   4. All the data binding, for example: the material, and the textures this material use, should be indicated by a string CRC token, rather than the direct pointer or index whatever. This gives flexibility that resource can be managed by different software module. For example, models can be managed by model manager, and texture can be managed by texture manager. The pointer can be obtained at the initialization time to allow fast resource access.
   5. Animations needs to be optimized, unnecessary animation keys should be removed.
   6. After that, the triangle strip needs to be created at the build time.
   7. All light maps should be generated at the build time or scene creation time, different light map can use different channels in one texture to save the memory space.
   8. Within the pipeline, the fx file should be exist in ASCII format rather than the compiled binary format. This gives the flexibility to post process the fx code and make it portable on different platform.
   9. Vertex data should be compressed to save the video memory and bandwidth.
6. For the run-time graphics:
   1. Instancing with LOD really sucks. I think the instancing can be obtained by pre-generate an index buffer and vertex buffer with multiple objects of the same model and use draw index call to control how many instance should be rendered. Each instance individual data (like position) can be obtained from a matrix in a matrix list sent from the CPU to GPU. The index of the matrix in the matrix list should be stored in the vertex data ( one byte should be enough. )
   2. Rendering order should be take care. Opaque first, then transparent stuffs, then HUD. A good way to do this is using 3 display lists, and each display list is for one type of rendering only.
   3. The render should be sorted by effect | material | texture | distance …….. For each sub-object in an object’s materials, and id should be generated for sorting. The id can be a 64 bits number with: effect id ( 63 – 58 ) | material id ( 57 – 50 ) | texture id for all stages (49 – 20 ) | distance 18 – 6 | other ids ( 5 – 0 ). A quick sort would be enough to sort all sub-objects. The order of each element in the id can be changed to reflect different priorities.
   4. Multi-thread should be used: one thread to calling rendering api, one for updating game objects, one for updating partcles, clouds, waters, trees and non-important environments etc…… So all the game world should be separated into two parts, one part is the object that can affect the game-play, another part is not.

That’s all that I can remember right now, I will add more stuffs if I get something.