Create your own awesome maps

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account?
Log In

Epiar - Next Generation by Mind Map: Epiar - Next Generation
0.0 stars - 0 reviews range from 0 to 5

Epiar - Next Generation


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


Flexible, easy to use and easy to integrate scripting language


provides a flexible, human-readable format for scripting


Network support


Cross-platform "anything"


Vector graphics

Can render on a OpenGL context


2D "compositing" layer

Allows efficient rotation and scaling

Allows pixel shaders for advanced light and particle effects

physics library?




Our own simple system, as in the past?


XML library


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



Gui, Video, Renders into OpenGL context

Audio, Uses SDL's raw audio facilities

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


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


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

Visualizer, Displays the game world

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

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

Code Convention

File Management

.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

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

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

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

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

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


Namespaces, Capitalized CamelCase, Should have logical group names

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

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.

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, this is needed because C++ has no enum scope, Things to consider - create scoped enum macros and force use thereof in code conventions?, Example, enum HorizontalAlignment, HA_LEFT, HA_RIGHT, HA_CENTER

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

Functions, CapitalCamelCase, Should be verbs as commands, SetProperty, EnableShield

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;

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;

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

Syntax Details

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

Component System

A system which utilizes OOP but goes much farther in expressive power and configurability

Individual items are "Components". These components expose certain interfaces and properties, and may hold other components.

A goal is reached by connecting several small components with concrete tasks


Component Ship, Properties, "Position", Coordinate. For example, (-4, 20), Interfaces, WorldObject, redirects to WorldObject child, Ship (implicit), Child Properties, Component CargoHold, Component WorldObject, Component ModelRenderable, Properties, "Mesh", "Material"

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

Implementation Details

class Component

class Property

Neue Idee