As you know, I'm facing the challange of creating a small game-engine in 10 days.
This can be considered a game to improve speed and understanding of a game engine and the decisions about the design. I found that personally, when coding at home (without time constraint) I need to study too much time before taking a decision on design. After this decision is taken, and some UML written down, I code with all in my mind (and papers) in a good way.
To improve the decision time I choose the way of training myself (as with guitar, breakdancing, motorbikes...).
What is the first principle of training? Practice, practice and PRACTICE.
Reading some books of NLP and Self-Improvement, I found in Anthony Robbins a perfect description of what he call the 'decision muscle':
Decision -> Action -> Results and Feedback.
It is the SAME as a controller in a dynamic system (automation systems...), and applies to all the field of the life.
And decision making is crucial also in engine design.
To improve decision making, I found really useful four things:
- Learn more. Learn all. Many times knowing different techniques improves you understanding of other problems: any techniques, and desing has a mentality behind.
Learning the MENTALITY is powerful. Then apply to other fields. Eg: data oriented structure of arrays used in vectorized math and shaders, can be successufully applied to game objects (Pitfalls_of_Object_Oriented_Programming paper is a good example). - Try completely different approaches.
- Practice, practice, practice!
- Learn from mistakes:
there are no failure, there are only results
(Robbins)
So finally I decided to begun another iteration of my home-engine with new knowledge from books and papers.
FIRST DAY
- Total time: 10 hours
- Evident results: running up window, multithread engine loop on.
I've almost finished the Platform Abstraction Layer, on which every other layer will rely.
The first thing I noticed is that you must create a complete environment for other programmers to work with your engine. Many times, due to lack of documentation or time to study, it's better to create restrictions to code use and rails for the other programmers.
For example, if you want the complete control of how classes are accessed, you can create some macros that fordib (declare private) copy constructor and equal operator. Or you can typedef pointer, const pointer, reference and such and use ALWAYS them.
Another example can be the error detection: a bunch of macros like _CHECK( condition ), or _ASSERT( condition ), _ASSERTNOFAIL (condition ) can be EXTREMELY useful to have a consistent way of developing. With that you can redirect all these macros to write down in a global output device you messagges, and this can be in a transparent way to programmers: think of an external window that brings up when you are in debug, with all informations sent everytime a check fail (or success), something missing, asserting.
Consistency is the key.
Decide the guideline in how you want to handle situations, and then use all the c++ features to create this Consistency.
Watching other code I've felt that when you give too much degree of freedom in the code to other using your engine, they will always do what you have not expected.
This leads to the need of "extending" C++, or use it to place constraint and quickly change behaviour.
Constraints.
Flexibility.
These two words commonly are the opposite, but have a variable number of choises, but with precise choises, leads to choose one of the path you thinked of.
Take the following code snippet:
HBOOL WorkerThread::GiveUpSomeWork(WorkerThread* pIdleThread)
{
SpinMutexLock Locker;
_HPKM_CHECK(Locker.TryLock(&m_oTaskMutex));
_HPKM_CHECK(!m_uiTaskCount);
// Grab work
SpinMutexLock LockIdleThread(&pIdleThread->m_oTaskMutex);
// Taskpool has some new tasks, quit.
_HPKM_CHECK(pIdleThread->m_uiTaskCount);
// We have only 1 task, try to split it.
if (m_uiTaskCount == 1)
{
TaskPtr pTask = HNULL;
if (m_apTasks[0]->Split(pIdleThread, &pTask))
{
pTask->m_pCompletion->MarkBusy(HTRUE);
pIdleThread->m_apTasks[0] = pTask;
pIdleThread->m_uiTaskCount = 1;
return HTRUE;
}
}
// Grab half tasks (rounding up)
U32 uiGrabCount = (m_uiTaskCount + 1) / 2;
// Copy this thread tasks to the idle thread list.
TaskPtrPtr ppTask = pIdleThread->m_apTasks;
U32 i;
for (i = 0; i < uiGrabCount; i++)
{
*ppTask++ = m_apTasks[i];
m_apTasks[i] = HNULL;
}
pIdleThread->m_uiTaskCount = uiGrabCount;
// Move remaining tasks down
ppTask = m_apTasks;
for ( ; i < m_uiTaskCount; i++)
{
*ppTask++ = m_apTasks[i];
}
m_uiTaskCount -= uiGrabCount;
return HTRUE;
}
The macro _HPKM_CHECK checks the condition and return HFALSE if the condition is not met.
This in the Release version. In debug or profile version, you can substitute it with other commands that send an event to an output device, or maybe print something in the game console.
As you saw, also TaskPtr type is a typedef. This ensure that we can test and let some classes use smart pointers, provide timings about access with/without smart pointers in a transparent way.
As Engine Programmer, engine is not only a c++ (and a bunch of other languages in other subsystems...) code mess, but a TOOL with which everyone MUST express himself.
For me, this is something that really lacks in many engines, even commercial ones.
Placing many smalls constraint, guides and hints gives everyone the power to use the engine as its full glory.
With macros, templates, defines (really not new stuff...) you have to give CREDITED TOOLS to code with.
You have to redirect almost ALL calls inside your code in a way YOU decide.
Almost EVERY method call must be under your control. Even simple memcpy, strlen, sin...they must be wrapped and even in the case of using the standard functions, you have to decide it.
This TOTAL ABSTRACTION (almost) leads to better code control and later optimization.
Even in coding, DECIDING ALL is the key! Decide that every sin call leads to a modified version, maybe with a table-lookup, or to the standard function. But you have to DECIDE!
Outside of those condiserations, I've worked on the platform abstraction. This includes:
- All types redefinition;
- Multithread-pooltask implementation (completely abstract);
- Timing management;
- Engine architecture based on an abstract engine, and external-declared subsystems;
- Client definition (under Windows a window that handle OS messagges);
The almost-hated virtual table, a good enemy on xbox360 and ps3 intensive operations, can be achieved in very straightforwarding way.
The final result is an almost controlled window that takes its messagges and call its task pool to use every kind of task possible divided on all the worker threads.
I'm implementing some interesting things like parallel data processing (parallel_for...) and want to contiune this way.
Of course, these are all mine thoughs and I know that there are many other way of doing the same thing better.
But you know, I have 9 more days to end the engine!
Demiurge
