Epiar - Next Generation

Get Started. It's Free
or sign up with your email address
Epiar - Next Generation by Mind Map: Epiar - Next Generation

1. Libraries

1.1. NOTE: Not everything listed here should be used - this is just a list of libraries that should be considered

1.2. lua

1.2.1. Flexible, easy to use and easy to integrate scripting language

1.3. libconfuse

1.3.1. provides a flexible, human-readable format for scripting

1.3.2. http://www.nongnu.org/confuse/

1.4. enet

1.4.1. Network support

1.4.2. http://enet.bespin.org/Features.html

1.5. SDL

1.5.1. Cross-platform "anything"

1.6. cairo

1.6.1. Vector graphics

1.6.2. Can render on a OpenGL context

1.7. OpenGL

1.7.1. 2D "compositing" layer

1.7.2. Allows efficient rotation and scaling

1.7.3. Allows pixel shaders for advanced light and particle effects

1.8. physics library?

1.8.1. ODE

1.8.2. PhysX

1.8.3. Havok

1.8.4. Our own simple system, as in the past?

1.9. sqlite

1.10. XML library

1.11. Irrlicht

1.11.1. Provides most of the above, plus a full 3D engine

2. Architecture

2.1. Framework

2.1.1. Gui Video Renders into OpenGL context

2.1.2. Audio Uses SDL's raw audio facilities

2.1.3. Component Provides a generic component and property system for C++ Support for serialization and deserialization of components

2.1.4. ResourceManagement

2.1.5. Net Defines and implements the basic server/client objects needed Remoting of Components

2.2. Epiar

2.2.1. Simulation Implements the raw game logic Support movement prediction (useful for both server and client)

2.2.2. Visualizer Displays the game world

2.2.3. Editor Uses the visualizer to provide interactive editing of the game world being displayed

2.2.4. Game The subsystem that ties all this shit plus user input together to provide a playable interface

3. Code Convention

3.1. File Management

3.1.1. .h Header Files Should have header guards FILE_NAME_IN_ALL_CAPS_H Additionally, an #ifdef-ed #pragma once for those compilers that support it, in order to have faster compile times

3.1.2. .cpp Implementation files for non-template things Should first include common.h, then it's associated header, before doing anything else

3.1.3. .hpp Implementation files for template things Shoudl have no header guard Included only by its associated .h file (enforced by #error-ing when the header guard macro isn't defined)

3.1.4. Names In General, the filename should be the namespaces plus the final symbol, separated by underscores Don't use directories instead, as this brings errors with many linkers The final name should be capitalized in the case of a type, and not capitalized otherwise Examples Epiar_Ship.h for class Epiar::Ship Epiar_Win32_misc.h for related miscellaneous types and functions in the Epiar::Win32 namespace

3.1.5. Directories No separation of source and include directories For library sub-components, a post-build script should be responsible for assembling the correct files

3.1.6. Common files common.h precompiled header for those compilers that support it Should contain common macros, definitions, and library includes Helps reduce compile time for compilers with precompiled header support <Namespace>.h Common external functions and types belonging to a namespace <Namespace>_internal.h Internal definitions belonging to a namespace that shouldn't be exposed to the outside Should only be included by source files within that namespace or child namespaces

3.2. Naming

3.2.1. Namespaces Capitalized CamelCase Should have logical group names

3.2.2. Classes Capitalized CamelCase - NO PREFIXES Should be singular nouns Prefer "EngineManager" over "Engines" Use classes for opaque "objects" Internal symbols that must be in the public or protected interface but should not be used should be prefixed with an underscore

3.2.3. Structures Capitalized CamelCase - NO PREFIXES Should describe the set of data contained within it as noun Use structures over classes for sets of concrete data that are kept in a relatively small scope class-local, internal to a namespace, etc.

3.2.4. Enumerations Capitalized CamelCase - NO PREFIXES Should describe the enumeration type as noun Enumeration Values PREFIX_ALL_CAPS_WITH_UNDERSCORES The prefix should be an abbreviation of the enumeration name Example

3.2.5. #defines NAMESPACE_ALL_CAPS If associated with a namespace, the namespace should be contained in the name C++ Preprocessor does not respect C++ namespaces

3.2.6. Functions CapitalCamelCase Should be verbs as commands SetProperty EnableShield

3.2.7. Variables lowerCamelCase no prefixe Should accurately describe what they are without being overly verbose. Prefer uint i; over uint shipIterationLoopIndex; Prefer uint numRows; over uint nr;

3.2.8. Template Arguments When no ambiguity is present, a single capital T is allowed template <typename T> class List; Prefix T template <typename TClass, typename TBase> class Inherit; template <unsigned int Tcount> class Counter;

3.2.9. Interfaces Same as classes, no prefix! Not required, but preferred to end with "able" Renderable Enumerable Doable

3.3. Syntax Details

3.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

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 Properties "Position" Interfaces WorldObject Ship (implicit) Child Properties Component CargoHold Component WorldObject 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

5. Neue Idee