Me and Yacker have been working on a game engine for atleast personal use in C, and I'm wondering if anyone here who has experience might have feedback/ideas/better ways to do stuff about the overall engine structure so far. One of the main points of the engine is to make it (relatively to my previous attempts) easy to swap out the renderer/input systems (as well as seperate the game specific stuff itself from most of the base engine), and so far it works like this: Spoiler Renderer/input files are in their own folder, which is switched in the Makefile. Example: Spoiler RENDERER_SDL = TRUE GAMEOBJCODE = game/objects/player.c ifdef RENDERER_SDL #OBJS specifies which files to compile as part of the project OBJS = main.c math2.c sdl/render.c sdl/input.c sprite.c image.c object.c game/gameobjects.c $(GAMEOBJCODE) #INCLUDE_PATHS specifies the additional include paths we'll need INCLUDE_PATHS = (SDL2 include path here) -I$(CURDIR)\sdl -I$(CURDIR)\game -I$(CURDIR)\game\objects #LIBRARY_PATHS specifies the additional library paths we'll need LIBRARY_PATHS = (lib path here) #LINKER_FLAGS specifies the libraries we're linking against LINKER_FLAGS = -lmingw32 -lSDL2main -lSDL2 -lSDL2_image endif The textures are abstracted into an Engine_Texture struct that contains a pointer to the actual texture, and the width/height. So theoretically it shouldn't matter if its using SDL or something else.. of course I haven't tried to replace the renderer so for all I know it could fall apart. Input would be abstracted into a game specific bitwise variable with enough bits for every button needed, that's actually checked by the game logic. Sprites are a string indexed array where an object would just call Sprite_Get("SPR_EXAMPLE"), then get back an ID for it in the array. If it doesn't have that sprite it loads its framerects/texture name from that sprites file.. and then it uses basically the same system for the textures themselves. Yacker programmed this, but I'm still not 100% sure if its a good idea in terms of performance.. Sound would probably use the same idea, but we haven't started on that yet. Objects use an array of structs with function pointers to Create, Step, and Draw functions for each object type in order. (Each object has a struct type, though all of them start with the same variables) And theres a function to add an object to this array by passing it the function pointers. The actual object list is a void** array of pointers to the objects (If they exist. When objects are deleted they move every pointer past it in the array 1 back, and it only loops through how many objects have been allocated rather than every index in the array) There's also the matter of it being C. Yacker told me C++ can have constructor/deconstructor functions (basically what we're doing for objects already but built into the language) and object struct types (Which would become classes) can be in an array so each object wouldn't need its own variant of "objects[id] = calloc(1,sizeof(obj_type_here_t));". Would it be a good idea to switch over? Thanks in advance if anyone has any thoughts on this.