1. Code Convention
1.1. File Management
1.1.1. .h
1.1.1.1. Header Files
1.1.1.2. Should have header guards
1.1.1.2.1. FILE_NAME_IN_ALL_CAPS_H
1.1.1.2.2. Additionally, an #ifdef-ed #pragma once for those compilers that support it, in order to have faster compile times
1.1.2. .cpp
1.1.2.1. Implementation files for non-template things
1.1.2.2. Should first include common.h, then it's associated header, before doing anything else
1.1.3. .hpp
1.1.3.1. Implementation files for template things
1.1.3.2. Shoudl have no header guard
1.1.3.3. Included only by its associated .h file (enforced by #error-ing when the header guard macro isn't defined)
1.1.4. Names
1.1.4.1. In General, the filename should be the namespaces plus the final symbol, separated by underscores
1.1.4.1.1. Don't use directories instead, as this brings errors with many linkers
1.1.4.2. The final name should be capitalized in the case of a type, and not capitalized otherwise
1.1.4.3. Examples
1.1.4.3.1. Epiar_Ship.h for class Epiar::Ship
1.1.4.3.2. Epiar_Win32_misc.h for related miscellaneous types and functions in the Epiar::Win32 namespace
1.1.5. Directories
1.1.5.1. No separation of source and include directories
1.1.5.2. For library sub-components, a post-build script should be responsible for assembling the correct files
1.1.6. Common files
1.1.6.1. common.h
1.1.6.1.1. precompiled header for those compilers that support it
1.1.6.1.2. Should contain common macros, definitions, and library includes
1.1.6.1.3. Helps reduce compile time for compilers with precompiled header support
1.1.6.2. <Namespace>.h
1.1.6.2.1. Common external functions and types belonging to a namespace
1.1.6.3. <Namespace>_internal.h
1.1.6.3.1. Internal definitions belonging to a namespace that shouldn't be exposed to the outside
1.1.6.3.2. Should only be included by source files within that namespace or child namespaces
1.2. Naming
1.2.1. Namespaces
1.2.1.1. Capitalized CamelCase
1.2.1.2. Should have logical group names
1.2.2. Classes
1.2.2.1. Capitalized CamelCase - NO PREFIXES
1.2.2.2. Should be singular nouns
1.2.2.2.1. Prefer "EngineManager" over "Engines"
1.2.2.3. Use classes for opaque "objects"
1.2.2.4. Internal symbols that must be in the public or protected interface but should not be used should be prefixed with an underscore
1.2.3. Structures
1.2.3.1. Capitalized CamelCase - NO PREFIXES
1.2.3.2. Should describe the set of data contained within it as noun
1.2.3.3. Use structures over classes for sets of concrete data that are kept in a relatively small scope
1.2.3.3.1. class-local, internal to a namespace, etc.
1.2.4. Enumerations
1.2.4.1. Capitalized CamelCase - NO PREFIXES
1.2.4.2. Should describe the enumeration type as noun
1.2.4.3. Enumeration Values
1.2.4.3.1. PREFIX_ALL_CAPS_WITH_UNDERSCORES
1.2.4.3.2. The prefix should be an abbreviation of the enumeration name
1.2.4.3.3. Example
1.2.5. #defines
1.2.5.1. NAMESPACE_ALL_CAPS
1.2.5.2. If associated with a namespace, the namespace should be contained in the name
1.2.5.2.1. C++ Preprocessor does not respect C++ namespaces
1.2.6. Functions
1.2.6.1. CapitalCamelCase
1.2.6.2. Should be verbs as commands
1.2.6.2.1. SetProperty
1.2.6.2.2. EnableShield
1.2.7. Variables
1.2.7.1. lowerCamelCase
1.2.7.2. no prefixe
1.2.7.3. Should accurately describe what they are without being overly verbose.
1.2.7.3.1. Prefer uint i; over uint shipIterationLoopIndex;
1.2.7.3.2. Prefer uint numRows; over uint nr;
1.2.8. Template Arguments
1.2.8.1. When no ambiguity is present, a single capital T is allowed
1.2.8.1.1. template <typename T> class List;
1.2.8.2. Prefix T
1.2.8.2.1. template <typename TClass, typename TBase> class Inherit;
1.2.8.2.2. template <unsigned int Tcount> class Counter;
1.2.9. Interfaces
1.2.9.1. Same as classes, no prefix!
1.2.9.2. Not required, but preferred to end with "able"
1.2.9.2.1. Renderable
1.2.9.2.2. Enumerable
1.2.9.2.3. Doable
1.3. Syntax Details
1.3.1. In a nutshell: K&R style, hard tabs, no pretty-prenting of functions to line up, exceptions allowed when it improves readability in that particular section
2. Architecture
2.1. Framework
2.1.1. Gui
2.1.1.1. Video
2.1.1.1.1. Renders into OpenGL context
2.1.2. Audio
2.1.2.1. Uses SDL's raw audio facilities
2.1.3. Component
2.1.3.1. Provides a generic component and property system for C++
2.1.3.2. Support for serialization and deserialization of components
2.1.4. ResourceManagement
2.1.5. Net
2.1.5.1. Defines and implements the basic server/client objects needed
2.1.5.2. Remoting of Components
2.2. Epiar
2.2.1. Simulation
2.2.1.1. Implements the raw game logic
2.2.1.2. Support movement prediction (useful for both server and client)
2.2.2. Visualizer
2.2.2.1. Displays the game world
2.2.3. Editor
2.2.3.1. Uses the visualizer to provide interactive editing of the game world being displayed
2.2.4. Game
2.2.4.1. The subsystem that ties all this shit plus user input together to provide a playable interface
3. Libraries
3.1. NOTE: Not everything listed here should be used - this is just a list of libraries that should be considered
3.2. lua
3.2.1. Flexible, easy to use and easy to integrate scripting language
3.3. libconfuse
3.3.1. provides a flexible, human-readable format for scripting
3.3.2. http://www.nongnu.org/confuse/
3.4. enet
3.4.1. Network support
3.4.2. http://enet.bespin.org/Features.html
3.5. SDL
3.5.1. Cross-platform "anything"
3.6. cairo
3.6.1. Vector graphics
3.6.2. Can render on a OpenGL context
3.7. OpenGL
3.7.1. 2D "compositing" layer
3.7.2. Allows efficient rotation and scaling
3.7.3. Allows pixel shaders for advanced light and particle effects
3.8. physics library?
3.8.1. ODE
3.8.2. PhysX
3.8.3. Havok
3.8.4. Our own simple system, as in the past?
3.9. sqlite
3.10. XML library
3.11. Irrlicht
3.11.1. Provides most of the above, plus a full 3D engine
4. Component System
4.1. A system which utilizes OOP but goes much farther in expressive power and configurability
4.2. Individual items are "Components". These components expose certain interfaces and properties, and may hold other components.
4.3. A goal is reached by connecting several small components with concrete tasks
4.4. Example
4.4.1. Component Ship
4.4.1.1. Properties
4.4.1.1.1. "Position"
4.4.1.2. Interfaces
4.4.1.2.1. WorldObject
4.4.1.2.2. Ship (implicit)
4.4.1.3. Child Properties
4.4.1.3.1. Component CargoHold
4.4.1.3.2. Component WorldObject
4.4.1.3.3. Component ModelRenderable
4.5. The live state of the system can be exported by simply querying all the properties of a component, and imported by instantiating a component with the given properties
4.6. Implementation Details
4.6.1. class Component
4.6.2. class Property