[X]





Roadmap Obsolete - Erroneous - Broken links - Confusing

Quimera Engine is not a beginning-to-end planned project. We know the goal but not all the paths to achieve it. Every step we take, we can only see what is some meters ahead to be prepared and be able to make the right decisions just before we reach the next stretch. Since the engine is divided into several isolated levels, this way of working is even more appropiate, due to every part is a different challenge and demands a design and some requirements that may not match what adjacent layers do. Besides, we think that a very exhaustive planning could lead us to frustration and waste of time, since even the best plan will be twisted and truncated by reality. Not all the problems can be foreseen, we have to accept that.

This doesn't mean that we move forward in a disorganized way, to each his own, without knowing where to go. We progress phase by phase, which are short plannings whose objecttives and priorities are well detailed and, commonly, group functionalities that facilitate the development of the next phase.

The main idea is to develop the engine from the bottom to the top, from the low level to the highest level parts, building the cross-cutting or common components (the core) as it's needed and going back to finish the postponed parts whose priority has become higher.

Gestation Obsolete - Erroneous - Broken links - Confusing

The gestation process of the project consits of, at least, the following elements:

Idea: Every project is born thanks to an idea, a vision, the imagination of a work. At the same time, the idea is based on previous knowledge and the belief that it is viable. In our case, the idea is about a library that acts as an engine or core over which to build videogames in a simpler way than without our engine.

Training: Carrying out a technological project requires some complex knowledge that the full team must acquire to move forward as a whole. A period of time is needed to let every team member learn whatever he needs and also technical documentation or a common information source.

Definition: It's about establishing the transversal objectives and priorities of the entire project, its bounds, its shape and the conventions to be used during the development.

Research: Once the team knows the basics about the technology on which the project is based, it's time to research on the available technical tools that could help to achieve. There are many cross-platform open source libraries whose licence allows their use for commercial purposes, which can accelerate the development of our software. It's necessary to know them well, to learn how they work and to compare them to similar solutions.

Environment preparation: Having a good working environment is vital for the team to work confortably, not supposing an obstacle. It's necessary to establish the working process based on tools which everybody can access to manage the source code, the taks and the documentation.

Technology selection: After the investigations, it's time to make decisions regarding of which technologies will compound the project. Every team member should be on charge of a exhaustive research on one concrete technology, to explain it to the team later.

Trials: In order to check that the working process works before the real development starts, some days will be dedicated to test it, involving as many elements as possible, including load tests. Maybe be realize some things are not viable, are useless or ar not defined yet.

Phase 0 Obsolete - Erroneous - Broken links - Confusing

Prerequisites Obsolete - Erroneous - Broken links - Confusing

  • The workflow has to be defined.
  • The tools have to be defined.
  • The team members must have a minimum knowledge about C++.
  • There must be a previous design of the engine.
  • The communication channels must be defined.
  • The number of people in the team should allow to progress in a fluent way.

Objectives Obsolete - Erroneous - Broken links - Confusing

The main porpuse in this phase, called zero for not being completely focused on the development of the engine, is to create the infrastructure that will allow us build the engine in a fast and firm way. It's about making reliable tools which help us to avoid future problems and to make the rest of the structure more stable. Therefore, its not so important to progress on the development of the engine during this phase but to assure that the quality of our progress is the maximum. Otherwise, the future developments would collapse and the work would have to be reviewed and repeated. It's worth to invest a big ammount of time and effort on this phase to prevent that from happening.

The scope of this phase includes:

  • Settings and improvements of the workflow.
  • Development of test applications.
  • Math library: Algebraical and geometrical classes. Development and intensive tests.
  • Common library: Constants definitions, helper classes.
  • DataTypes library: Definition of basic types used by Math.
  • Windows and Linux 32 bits portability.
  • Development of the test environment. Implementation of unit tests for all the developed libraries.
  • Development of the Test Automation Tool. This tool will let us automate the tests for the entire engine for all the configurations.
  • Design and deploy of web tools and their contents: Development forum, public forum, portal and wiki.
  • Design and generation of the API reference documentation.

Priorities Obsolete - Erroneous - Broken links - Confusing

  1. Creation of the structure of the code projects.
  2. Development of Math and other libraries needed.
  3. Creation of the test environment.
  4. Intensive testing of the developed libraries.
  5. Creation of the Test Automation Tool.
  6. Publication of the project in the Internet.

Development requirements Obsolete - Erroneous - Broken links - Confusing

  • [Design] Minimize dependencies.
  • [Design] Testability.
  • [Code] Internal documentation of the methods, specially when the code is not very clear due to optimizations.
  • [Code] Speed optimization.
  • [Code] Clean code (self-explained or well-documented).
  • [Code] High coverage unit tests.

Phase 1 Obsolete - Erroneous - Broken links - Confusing

Prerequisites Obsolete - Erroneous - Broken links - Confusing

  • There must be a well-defined project structure.
  • Basic types must be defined.

Objectives Obsolete - Erroneous - Broken links - Confusing

The main purpose of this first pure-development phase is to complete the engine's DataTypes library and progress in the development of the most important components of Tools layer.

The scope of this phase includes:

  • Common library: Definition of QObject.
  • DataTypes library: Types for strings.
  • Time library: Types for date and time quantities management.
  • Memory library: Pool allocator and stack allocator.
  • Containers library: Most common containers: list, array, tree.
  • Mac OS X portability.

Priorities Obsolete - Erroneous - Broken links - Confusing

  1. Memory.
  2. DataTypes.
  3. Common.
  4. Time.
  5. Containers.
  6. Portability.

Development requirements Obsolete - Erroneous - Broken links - Confusing

  • [Design] Minimizing dependencies.
  • [Design] Testability.
  • [Code] Internal documentation of the methods, specially when the code is not very clear due to optimizations.
  • [Code] Speed optimization.
  • [Code] Clean code (self-explained or well-documented).
  • [Code] High coverage unit tests.

Phase 2 Obsolete - Erroneous - Broken links - Confusing

Prerequisites Obsolete - Erroneous - Broken links - Confusing

  • Basic types must be defined.
  • Functionality to be able to store information with some kind of order.

Objectives Obsolete - Erroneous - Broken links - Confusing

The development of the System layer will begin during this phase and some environment resources, like the file system or the thread management, will be accessible. We will make also the first steps to the internal diagnosis tools creation.

The scope of this phase includes:

  • Exceptions library: Definition of the QAssertException class.
  • Diagnosis library: Call stack tracing.
  • IO library: Complete, but text stream reading and writing classes.
  • FileSystem library: Full.
  • Threading library: Full.
  • Timing library: Full.
  • Change of cross-platform IDE: Code::Blocks will no longer be used.
  • Assertion improvements.

Priorities Obsolete - Erroneous - Broken links - Confusing

  1. Exceptions.
  2. Assertions.
  3. IO
  4. Timing.
  5. Diagnosis.
  6. FileSystem.
  7. Threading.
  8. Change of IDE.

Development requirements Obsolete - Erroneous - Broken links - Confusing

  • [Design] Minimizing Diagnosis library's dependencies.
  • [Design] Testability.
  • [Design] Usability.
  • [Design] Performance in classes intended to be used intensively.
  • [Design] Abundant technical documentation.
  • [Code] High coverage unit tests.

Phase 3 Obsolete - Erroneous - Broken links - Confusing

Prerequisites Obsolete - Erroneous - Broken links - Confusing

  • Basic types must be defined.
  • Functionality to be able to store information with some kind of order.
  • Be able to measure real time.

Objectives Obsolete - Erroneous - Broken links - Confusing

During this phase we will be finishing any pending work from Phase 2 (file system navigation classes, thread management classes and call stack tracing classes) and some important types will be added: the hashtable and the hashed strings.

The scope of this phase includes:

  • Exceptions library: Definition of the QAssertException class.
  • Diagnosis library (to complete): Call stack tracing.
  • IO library (to complete): Full.
  • FileSystem library (to complete): Full.
  • Threading library: Full.
  • Containers library: Implement the dictionary and the hashtable.
  • DataTypes library: Implement the hashed string type.
  • Migrate the Test Automation Tool to CodeLite.

Priorities Obsolete - Erroneous - Broken links - Confusing

  1. IO
  2. Diagnosis.
  3. FileSystem.
  4. Threading.
  5. Containers.
  6. DataTypes.
  7. Exceptions.
  8. TAT migration.

Development requirements Obsolete - Erroneous - Broken links - Confusing

  • [Design] Minimizing Diagnosis library's dependencies.
  • [Design] Testability.
  • [Design] Usability.
  • [Design] Performance in classes intended to be used intensively.
  • [Design] Abundant technical documentation.
  • [Code] High coverage unit tests.

Phase 4 Obsolete - Erroneous - Broken links - Confusing

Prerequisites Obsolete - Erroneous - Broken links - Confusing

  • Basic types must be defined.
  • Functionality to be able to store information with some kind of order.
  • Be able to measure real time.

Objectives Obsolete - Erroneous - Broken links - Confusing

The objective of this phase is to develop a graphics engine prototype inorder to find the best way to integrate it into the game engine, find which parts are paralellizable, design the data model and the abstractions for the managment class instances. The engine will be build on top of OpenGL 4 and must be “easily” portable to DirectX using the same public interface. The complexity degree depends on the progress achieved for 6 months.

Long term planning Obsolete - Erroneous - Broken links - Confusing

This section compiles the actions intended to be performed some undefined day. These tasks are not included in the short/middle term planning because their priority is very low or because they depend on how the project grows in terms of collaborators, users or funding.

Reward system Obsolete - Erroneous - Broken links - Confusing

We want to work on a system to reward those collaborators who work more. An example could be to assign points to the tasks, so a collaborator accumulates them as he finishes the tasks, and receives a symbolic gift when some ammount of points is reached. This is almost done.

Marketing Obsolete - Erroneous - Broken links - Confusing

Actions to increase the project popularity. Like for example:

  • Make t-shirts with a typical “hello world!” code that has to be written to run Quimera Engine.
  • Make t-shirts with the Quimera Engine logo.
  • Advertise the project in Stratos and other webs visited by other colleages.
  • Paste posters in the universities.
  • Offer some kind of C++ initiation courses, to amplify the number of users of the engine.

Donations Obsolete - Erroneous - Broken links - Confusing

Establish some kind of donation system to invest on advertising, servers, etc.

Crowdfunding Obsolete - Erroneous - Broken links - Confusing

Create a crowdfunding campaing to earn funds to invest on tasks of the project.

Design the documentation front page Obsolete - Erroneous - Broken links - Confusing

Design a proper front page for the API documentation.

Floating bar development for webs Obsolete - Erroneous - Broken links - Confusing

Create a floating tool bar that contains links to the rest of webs in every one of them: wiki, portal and forums.

Continuous integration server Obsolete - Erroneous - Broken links - Confusing

Mount a server that, automatically, downloads the latest version of our code, compiles it, executes all the tests and shows a set of reports periodically.

Test server Obsolete - Erroneous - Broken links - Confusing

Mount a server to be used as a remote test center, so you can send local code and it passes all the tests. This way, we wouldn't need to execute them by ourselves in our machines and would be able to keep developing.

Pay for a project management program Obsolete - Erroneous - Broken links - Confusing

Buy the license to use some online project management program that integrates everything and which lets to make use of the data.

Installation package Obsolete - Erroneous - Broken links - Confusing

Investigate how to create, with simple steps, an installation package for the engine.

Development of tools to configure the engine Obsolete - Erroneous - Broken links - Confusing

Creation of a simple application to generate configuration files for Quimera Engine.

Provide templates / wizards for Quimera Engine projects creation Obsolete - Erroneous - Broken links - Confusing

Creation of templates or wizards for Visual Studio or Code::Blocks with which facilitates the creation of an application that makes use of Quimera Engine.

Very long term planning Obsolete - Erroneous - Broken links - Confusing

This category groups those plans that will be taken up after the first version of Quimera Engine is released.

NaCl portability Obsolete - Erroneous - Broken links - Confusing

It would be very interesting to use Quimera Engine on web applications, by using Google's NaCl technology, which allows the use of native C++ code for developing applications that run on the web browser in the client machine. For more information: http://en.wikipedia.org/wiki/Google_Native_Client .


In Other Languages