Tasks for volunteers

[piotrdz]

I've been asked recently by a friend of mine, what would be a good starting point for someone who wants to contribute to our project.

So far it has been relatively difficult to get into the project, especially for someone who doesn't understand all the little details of how the game engine is implemented.

However, with 0.1.6 release, we have really cleaned up the code to the point, where I think it's possible for newcomer to do some useful work without the necessity of studying thousands of lines of old code.

I've compiled the following list of items with more-or-less detailed description of what is the goal of each item. There are of course easier and more difficult items, so I propose to start gradually, with the easiest items first. If something is unclear, I can provide a more detailed explanation, or we can discuss it on IRC.

I post this list here as proposal, not as something set in stone. These are things that I would take up myself in the future, not necessarily how we must proceed with the refactoring. I invite everyone to discuss whether any of these ideas make sense and what else would you propose for a beginner in our project.




1. Clean up CBOT interface (easy):
  - split CBotDll.h to separate files per each class
  - create new CBot.h file, containing only #includes to files with public parts of CBOT interface; all non-essential interfaces should be hidden
  - split CBOT *.cpp files per each class
  - remove unused parts of code

2. Split level loading code from CRobotMain (easy):
  - CRobotMain::CreateScene() should go into dedicated class, for example CLevelLoader
  - each if (line->GetCommand() == "...") should be implemented as lookup in a dictionary containing mapping of: command -> pointer to member function handling this command

3. Clean up some issues reported by colobot-lint (easy):
  - easy, but boring job
  - starting in order of severity, number of issues should be gradually brought down
  - see colobot-lint HTML report for nice presentation
  - CBOT code can be left to the very last, as it would probably be rewritten from scratch

3. Create CObject subclasses for CAuto objects (moderate):
  - as first step, only create empty subclass and move related CAuto implementation into one code module
  - next steps: merge given subclass interface and matching CAuto interface:

Code:

      CAutoFoo::DoFoo() { m_object->DoFoo(); }
      CObjectFoo::DoFoo() { /* copy-pasted implementation from CAutoFoo */ }

  - final step: remove CAuto base class and merge its interface directly into CInteractiveObject

4. Get rid of remaining singletons (moderate):
  - only CLogger should really remain a singleton, as it is used all over the place, and is therefore actually useful as singleton
  - all other singleton classes should be gradually removed, replacing their uses with dependency injection, or setter functions

5. (Re-)create CBOT commandline interpreter (advanced):
  - dig up old CBOT interpreter from the files removed in Git history
  - make it work with current code
  - prepare environment for running CBOT code snippets for testing purposes

6. Look into the issue of isolating UI library (advanced):
  - the plan is to introduce CEGUI library with possibly minimal impact on rest of the code
  - existing UI code should be refactored to implement a minimal public interface
  - a new library should be created, which would depend only on common structs, and minimal graphics engine interface

7. Look into possibility of testing through recorded event traces (advanced):
  - the goal is to try to create basic acceptance tests for interactions with game objects, which can then be re-run automatically as something like regression tests; such tests would be very useful when we start messing with CBOT code and refactoring parts of CObject that involve complex object interactions
  - write serialization code for CEvent and logging of events in CApplication
  - adapt CApplication to be able to re-run recorded events from trace file (possibly with null graphics device)
  - come up with an idea of how to express testcase assertions (rely on outcome of mission? test for side effects of CBOT script execution?)

[krzys_h]

2. Split level loading code from CRobotMain (easy):
  - CRobotMain::CreateScene() should go into dedicated class, for example CLevelLoader
  - each if (line->GetCommand() == "...") should be implemented as lookup in a dictionary containing mapping of: command -> pointer to member function handling this command

This might not be as easy as it sounds because it references loading of saved scenes in a really dirty way (in BeginObject command).
Also, the code for loading saved scenes in split all over the place (some in the UI classes for loading the title for display in the list, some in CPlayerProfile for finding correct level file to load and finally a BeginObject hook in CRobotMain while the level is being loaded)

@EDIT: Actually, I think I already moved it out of UI classes. I'm not sure though.

[piotrdz]

@krzys_h: Even so, moving this code somewhere else and cutting it into manageable functions would be a good start on this. I realise there are many dependencies and we will not clean them up all at once, but we must do something with this code soon.

[Grunaka]

I will take the part 1. Clean up CBOT interface.

[krzys_h]

I updated the first post to mark tasks that are already done