Internal Architecture Improvements
Posted: Mon Mar 03, 2008 1:04 pm
Since some people don't like me "hijacking" the Features thread, with your permission I'll create a new one.
I want this thread to be a place of discussion of _internal_ mechanics and improvements for the Love Machine (AKA the Love Engine). It is also a good idea to clearly state architectural decisions here before we forget and start asking “why the heck we did it this way???”.
Currently I am working on the new project structure to be (hopefully) more logical, clean and allowing more hacks from all project members. I rewrite it from scratch because I believe that in the current state it is wiser to do so than to tweak it by little incremental steps. I also want to stress one more time my good intentions, I certainly not hijacking anything and the final word is always Rude’s.
So, to business.
Here are some of the things I came up with:
1. General project directory structure
common – most commonly used, usually quite independent stuff
drivers – a set of modules to implement interfaces with other systems, like Video, Audio, Input, etc. The user must be able to select any driver from CFG file at run-time. So you will have complete freedom what to use - DirectX or OpenGL or something else.
game – a set of classes, related to game support, such as the main Game class, etc.
lua – lua source code and a wrapper. I made a decision (that can be easily changed) to incorporate Lua into EXE file, not to use it as DLL. a) there are lots of DLL’s already, b) it will be slightly faster, c) it will be smaller and d) if the Lua is updated you would have to recompile DLL anyway.
platform – this is where all the system-dependent stuff is (also, probably, in drivers). Under this folder there are folders for each platform – Windows, Linux, etc.
This structure of course is not fixed. Any ideas are welcomed.
2. There will be one main “love” object and most inter-module communications will go through it. Each platform must initialize this pointer with system-specific implementation of the abstract class Love. For example WinLove is the class, inherited from Love to implement windows-specific application functionality, like HWND, etc.
3. About files – how I see it. There is a folder with all the game packages (.love). It is read-only; we should not mess with developer’s archives. But there should be additional folder, called “save” or “saved games” where there is one file per each game (like “gamename.save”) that holds the current state of the game.
4. About how to organize graphics drawing – I think it is best to be left for each driver. One driver may use SDL to draw shapes, another may use my approach of drawing everything manually in a buffer and then flushing it to video memory. I believe it will be more flexible. Another example – one driver may use standard Windows messages for input, another – DirectX, another – something else. We may even consider creating these drivers (or plug-ins) as DLL’s. Because one of the problems of such kind of engines is that in non-trivial games there is always some non-standard functionality that is missing or too slow to be done in scripts. It would be nice to allow users to extend Love with plug-ins.
Enough for now
What are you ideas?
I want this thread to be a place of discussion of _internal_ mechanics and improvements for the Love Machine (AKA the Love Engine). It is also a good idea to clearly state architectural decisions here before we forget and start asking “why the heck we did it this way???”.
Currently I am working on the new project structure to be (hopefully) more logical, clean and allowing more hacks from all project members. I rewrite it from scratch because I believe that in the current state it is wiser to do so than to tweak it by little incremental steps. I also want to stress one more time my good intentions, I certainly not hijacking anything and the final word is always Rude’s.
So, to business.
Here are some of the things I came up with:
1. General project directory structure
common – most commonly used, usually quite independent stuff
drivers – a set of modules to implement interfaces with other systems, like Video, Audio, Input, etc. The user must be able to select any driver from CFG file at run-time. So you will have complete freedom what to use - DirectX or OpenGL or something else.
game – a set of classes, related to game support, such as the main Game class, etc.
lua – lua source code and a wrapper. I made a decision (that can be easily changed) to incorporate Lua into EXE file, not to use it as DLL. a) there are lots of DLL’s already, b) it will be slightly faster, c) it will be smaller and d) if the Lua is updated you would have to recompile DLL anyway.
platform – this is where all the system-dependent stuff is (also, probably, in drivers). Under this folder there are folders for each platform – Windows, Linux, etc.
This structure of course is not fixed. Any ideas are welcomed.
2. There will be one main “love” object and most inter-module communications will go through it. Each platform must initialize this pointer with system-specific implementation of the abstract class Love. For example WinLove is the class, inherited from Love to implement windows-specific application functionality, like HWND, etc.
3. About files – how I see it. There is a folder with all the game packages (.love). It is read-only; we should not mess with developer’s archives. But there should be additional folder, called “save” or “saved games” where there is one file per each game (like “gamename.save”) that holds the current state of the game.
4. About how to organize graphics drawing – I think it is best to be left for each driver. One driver may use SDL to draw shapes, another may use my approach of drawing everything manually in a buffer and then flushing it to video memory. I believe it will be more flexible. Another example – one driver may use standard Windows messages for input, another – DirectX, another – something else. We may even consider creating these drivers (or plug-ins) as DLL’s. Because one of the problems of such kind of engines is that in non-trivial games there is always some non-standard functionality that is missing or too slow to be done in scripts. It would be nice to allow users to extend Love with plug-ins.
Enough for now
What are you ideas?
Excellent. LÖVE [virtual] Machine. Puns are truly endless.