Is This A Good Engine Layout Or Not?
Simply Put:
1. Have a base class called eng_Kernel.
2. Have other eng_**** classes, and together with the kernel all make a functional window and initiate DirectX with basic Direct Input.
3. One of these other classes is eng_TaskManager, which manages what state the app is in etc, calls the setup and update/render functions that lie in the app side of the program.
4. To begin with only 1 C++ file, say app_Kernel, inherits from eng_Kernel and also has the winmain() function, which creates an instance of app_Kernel and creates the window calling app_Kernels functions etc.
5. Have other generic classes like cubes panels XFile loading etc.
with this basic framework it only takes me about 10 lines of code to get a blank window up and running. All the functions that would need to be overriden are virtual so there is plenty of scope for alterations if necessary.
Any sensible contributions and suggestions welcome and any constructive critism more than welcome.
regards,
ace
Use namespaces, first off. Looks like an Engenuity spinoff to me so you might be okay, but the only way to know is to go ahead and make all the mistakes. You can read a ton, but nothing can touch actual experience.
A base class? Shouldn''t a class eng_Kernel contain the eng_TaskManager? I''m not sure if this is an official design pattern, having never read the design patterns book, but google for the microkernel pattern for what you should include in it. Maybe by eng_Kernel as a base class, you mean a task that would be managed by the eng_TaskManager?
About point 5: classes for cubes, panels, and .X file loading aren''t really generic. Cubes aren''t necessarily a basic part of an engine, and what if you decide to go API-independent? Then your .X file loading would have to be encapsulated in your D3D-specific rendering functions. Unless you intend to write your own X file parsing routines, of course, but then you might as well parse your own custom format.
Having only 10 lines of code to get a blank window up and running isn''t necessarily something to brag about. Although short setup code can be something that shows the flexibility of engine, an engine whose setup code for Pong is 1000 lines long where you only have to change a few of those lines in the AI / physics code to create a completely different game is just as flexible.
About point 5: classes for cubes, panels, and .X file loading aren''t really generic. Cubes aren''t necessarily a basic part of an engine, and what if you decide to go API-independent? Then your .X file loading would have to be encapsulated in your D3D-specific rendering functions. Unless you intend to write your own X file parsing routines, of course, but then you might as well parse your own custom format.
Having only 10 lines of code to get a blank window up and running isn''t necessarily something to brag about. Although short setup code can be something that shows the flexibility of engine, an engine whose setup code for Pong is 1000 lines long where you only have to change a few of those lines in the AI / physics code to create a completely different game is just as flexible.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement