Each idea counts

As we advance and realise our work's potential, we have new ideas to improve the components we are developing, we have developed or we will develop. Even we invent new components that could have a great utility in the future and which we haven't realised until now. Quimera Engine can grow and improve on, as any other work made by anyone, to infinite. But our time, our energy and our management capability are finite, so we have to think about ways of managing those ideas that come to our minds without making the development eternal and without losing that valuable information. One of the tools that we are going to introduce for that is the proposal list:


This list will be updated every time a proposal is made by the team members or by the users. The direct communication with the real or potential users, is something that we are pretending to promote. In order to be successful with this kind of project, the opinion of those that are going to suffer use it, is vital. The vision of designers and developers could be wrong or not to be sufficiently deep as to realise some of the needs that other programmers could have. By that, the participation of everyone is important, developers using the development forum and users using the public forum:


Of course, some ideas aren't useful or urgent as others; maybe those ideas don't fit with our objectives, have been already proposed or have been discarded because they aren't clear. Every time it will be discussed and will attempt to base, and it may or may not be finally added to the proposal list. In case that the idea comes from an external source, as the public forum, if it's acceptable, it will be added to the proposal list and will be discussed at that moment, or later.

As it can be seen, each proposal have an origin, a priority, a type and a status, described at the legend below. A proposal can be useful, but maybe it isn't a priority at the present moment. Priorities will be revised at the beginning of each developing phase and status will change as soon as a decision is taken, about to develop or not to develop it.

Proposals may not be related with API's components but can deal with new ways to work or new tools that makes our work easier. Evidently, this type of ideas will be mostly internal.

We hope this helps creating something more useful for everyone.


Phase 1 starts

If you have experience programming with C++ and you want to learn how a videogame engine works, this is the moment for joining us.

Different ways to collaborate

  • Quimera Engine development: API implementation, as it is planned. It is the more complex and important part. Advanced C++ knowledge is required, among other things. This type of work is described below.
  • Test Automation Tool development: It consists in refactoring and extending the tool that we use for automating the execution of the unit tests. It's not necessary to have a great knowledge of C++, but it requires experience developing applications with graphic user interface (GUI). It's based on the wxWidgets library, but it's not mandatory to know it. Knowledge about concurrent programming, cross-platform programming, testing, Boost UTF and design patterns, are valuable for this task.
  • Spanish / English translation and revision: Although all the team members should have knowledge about written and read English, a very high level isn't required. Thus, the public documentation must be revised to check that it is correctly written, as we do with the code. It's recommendable that the translator has some knowledge about programming, but it is not necessary. Translator's job consists in translating full articles for the portal and the wiki, as well as revising code documentation and being a reference person for the rest of the team, who can be asked about doubts. If you want to know more about a translator workflow, you can visit this link.

Developers' day by day

First of all, since the developer is in the team, he/she must know that the project is the most important thing and has 3 basic parts: The product, the team and the users. It's not useful to focus on one of them if you unconcern about the others. The project must have a reasonable quality, the team must enjoy developing it and the user must find it useful and accessible. It seems to be soon to care about users but they are there, potentially, since the beginning; we have to inform about development's status, about our objectives, about the decisions we have taken... We must provide all the information to make us known. We shouldn't lose sight of this during the development: design without losing the usability, detailed and comprehensible method's documentation, tutorials' publication, direct communication using the forum and Twitter...

About the tools a developer will need, they could be divided in communication tools and work tools. For communicating with each other, we use Skype for short conversations that need a quick answer or for team meetings, and the development forum for everything else; this includes to inform about tasks' progress, ask about not urgent doubts, share information about any topic, discuss or propose things. About the work tools, besides the C++ IDEs, we use Subversion (Tortoise client) for code versioning, hosted on Google Code, where we have the tracker too. Last, we use the Test Automation Tool for executing the unit tests.

Summarizing, someone that has just joined the team must check the wiki and follow the steps for installing the IDE and compiling the code by the first time. Then, it is advisable to read all the documentation available on the wiki, specially the suggested paragraphs on the last step. Finally, given that he/she won't have any experience with the project, one of the simplest tasks will will be assigned to him/her, for he/she to learn the work methodology. Every time someone takes a task, a tracing thread is created in the development forum with the purpose of informing about the progress and asking questions. When the task is concluded, he/she uploads a patch that will be used by other developer for testing his/her modifications. If everything is correct, the original developer uploads the code on his/her name. You can see the process detailed here.

About the work to do during phase 1, it includes:

  • String management classes.
  • Date and hour management classes.
  • Basic containers: arrays, lists, dictionaries and trees.
  • Basic custom allocators: Linear and pool.
  • Basic general classes: QObject.
  • Mac OS X portability.

You have more information about team's work methodology here.

If you want to know about our work until now, you can visit these articles: The beginning of a long way, Working in darkness.


What will I obtain of all this? It is the question most people think when they're asked about collaborating on something like this. The answer is subjective, each one gives a different value to each thing and has different purposes but, if we refer only to tangible or concrete things, as minimum, you earn:

Contacts: We know people with similar interests to ours, from the same professional guild and, maybe, we'll want to create new projects with them.
Resume: The fact of working for a while in a project like this, gives value to your resume and could help to find a related job (this has occurred actually).
The code you write as the code you've written belongs to you, belongs to everyone. All that helps to grow and improve this project will benefit to everyone, since it is public and free.
Rewards are awarded in form of games, books or symbolic presents to the more participative collaborators.

There will be no money involved since nobody finances us nor is expected to have any monetary revenue when the development is concluded.

How can I collaborate?

You can contact us via e-mail (  This email address is being protected from spambots. You need JavaScript enabled to view it. ) or using Twitter ( @QuimeraEngine ). There will be a brief written interview to know if the person is suitable to be part of the team.

To know more about what we are looking for, visit this section

A new incentive

As announced before, one of the tools that is expected to serve as another incentive for all the people involved in the project is ready. Now, as a symbolic reward after their effort, the most participative collaborators will be able to access prizes that go from t-shirts and small freak things to videogames at Origin or Steam and technical books.

The tool consists in a web site where one can see a ranking with all the collaborator names next to their score, beneath a space where the prize is shown along with its description and the required amount of points to take it. Points are obtained when solving project tasks, depending on their urgency and difficulty. Prizes have a determined duration, a period of time assigned, at the end of which prizes are delivered to the winners, if any, and scores are reset to zero for the next prize.

For more details about the ranking's rules you can visit the wiki, inside the Work methodology section:


To access the ranking (it's public) you can use the following URL:


At the moment data is fake in order to see it working, until there are enough collaborators to start using it. There are several things to be done yet, llike improving the user interface, but it is ready to fulfill its function.

Thanks Elizerox for his participation in the development of this tool. We have though, eventually, to improve it and release it as a generic and customizable application for anybody to download it and use it in their own projects. All depends on the success of the experiment.

Your opinion is valuable, if any idea comes to your mind or if you detect any error or something that can be improved, don'y hesitate to write to This email address is being protected from spambots. You need JavaScript enabled to view it. or go to the public forum at http://forum.quimeraengine.org/index.php .

The beginning of a long way

Three years

Three years of sacrifices, perseverance, learning, hard decisions, doubts and self-fulfilment have got us to here. The phase zero, the first and the hardest, has finished. In this phase, the foundations of the design have been lain and the work methodology has been proven; the infrastructure of the project has been built, the foundations on which the rest of the components (almost all of them) of the engine will be constructed, in a faster and more solid way, in the phases to come.


After the introduction, I'm going to what is more important: collaborators. Volunteer professionals, with inquisitiveness, competent, thanks to who I could gather the necessary courage to start this madness. It's been very gratifying to know people with related interests in such a limited world. The best of all is that I don't regret having accepted any of them in the team, all of them have done their best and there weren't any kind of confrontation, even when we had very different opinions which each of us has defended respectfully. I think we've enriched each other and have had fun. Due to all those things, THANKS:

  • Nexus6
  • ShengPing
  • Anderson_jag
  • Marci
  • Txaneto
  • Borderpanic
  • Skid
  • Gallo
  • DavidLuis
  • LuisJavier
  • Jmartin
  • Kibawolf

and specially Jwladi, who accompanied me for 2 years through the muddiest lands. Also, although they aren't collaborators, I would like to thank the people that encourage us in Twitter, Juan José Ruiz who mentioned us in his portal and Carolina, who has backed me and has supported part of my load during so much time.

I can't believe this day has come. One always follows a personal vision but can't imagine what one will feel when that comes true. It's strange, I don't feel happy but satisfied. I think that there are mountains of things to improve and maybe that makes me not to realize how many objectives we've achieved. I leave a very summarized list below:

  • Project geneal planification. Short and middle-term projection. Decisions about what features to include, physical and logical distribution of the components, interactions and dependencies, supported platforms. Level of usability, optimization and modularity to apply to every part of the engine. Compile-time configurable elements of the engine selection.
  • Technical-level design decisions for the first phases. Researching and choice of third-party libraries to be used.
  • Reference documentation. All the implemented features have been documented.
  • Implementation of the testing system.
  • Implementation of a visual tool to automate the execution of the tests using any configuration available, called Test Automation Tool (see dedicated post).
  • Development of the functionalities related to basic data types and mathematical entities.
  • Intensive implementation of tests for the implemented features. There are more than 4000 tests.
  • Revision of the whole code, as the features were being implemented.
  • All functionalities have been tested using all the compilation configuration combinations possible (8 by now), on Windows and Linux. Functionalities are available as both static library and dynamic library.
  • Design and improvement of the project's webs: Development forum, main portal, public forum and wiki. With English and Spanish contents. Logo of the project.
  • Maturing and formalization of the work methodology. This includes the selection of the work tools.

Having seen the reduced amount of components (of the engine) developed it may seem that 3 years have been too many. Not being my intention to try to justify that, I would like to make the people who think that way understand why it IS possible to spend such amount of time. Firstly we have the human resources available, which have been very few and with short time dedication; because the spare time we have everyday after our jobs is too little. Secondly I have to admit that some design errors have delayed us due to some corrections we had to do to the code. Beyond that, just talking about programming, there are compilation configurations, supported platforms, preprocessor definitions, design directives for each concrete component, etc. Adding to all of that the revision of every code snippet, the exhaustive implementation of the tests and the documentation writing. And we haven't begun to optimize yet, which is planned to be done later on.

Professionaly, as the project manager, I've learned a lot, I feel like I've grown. I've made mistakes like drowning me and the team with too much unnecessary functionality that has destroyed the feeling of progress of the project for a long time. Because of that I've learned to plan shorter milestones, also based on more realistic use cases. This is related to something that is difficult for many of us to know: when does someting that, apparently, can be extended and improved to the infinite finish? It's hard to say "up to here" and quieten the voices that say "but if I leave this unfinished, people are going to think that we didn't realize, we don't know how to do it or we are slapdashes". Now my estimations are more accurate and I've realized how difficult is to keep a team involved, motivated, taking part of an idea that isn't theirs in the beginning. I know the excitement of the one who joins and the despondency of who leaves. My conclusion is that, despite the huge personal sacrifices, gaining this great experience has been worth.

I've run my mouth, but only because this is the first and more special phase of the many that are to complete.

Relative rest

I would like to say that I'm going to celebrate the occasion in a big way and take a break for one month but, although a good drunkenness is not discarded, I know for a fact that I'm not going to disconnect from the project and I will dedicate my time to tie up loose ends, extend the wiki and plan the next phase. Perhaps, now that I've time, I will read a technical book of those that makes you feel a full ignorant. I'm masochistic, you know.

I use this opportunity to announce that I'm searching for crew again. I need people that are not right in the head, that want to get on board in a journey full of difficulties and dearths along with other mates that are insane and dexterous too. There won't be loot and nobody will cheer our great feats but you will have the chance to participate in something big and reach places that others haven't reached, if you survive...

What is next

Next phases will be shorter. In the phase 1 we will develop the classes related to some basic data types, like strings or date and time, an also the most common containers (lists, dictionaries, etc.). It's intended also to progress in the Mac Os X portability and maybe the development tools will be upgraded (Visual Studio 2012 and CodeBlocks 12.11).

It will be explained in future posts but I can talk in advance about two novelties that I hope to finish next month: one is a panel where all the features that are to be possibly added to the engine will be published, informing about their state and maybe connecting them to the public forum so they can be discussed; the other is a ranking system for collaborators with which the winners, depending on the established rules, will receive actual prizes (I mean, they cost money). The aim is to stimulate and recognize somehow the time spent on the project and to open the communication with final users.

It's still remaining a long way to go, this is just the beginning. I completely believe that Quimera Engine, sooner or later, will come true.