Tweet
PROJECT-> Project directions
A bit of introduction
Lot of work and discussion has taken place within the first week followed the release of the source code. A bit of everything, here and there. Bug tracking and fixing, minor documentation of small pieces of code, attempts to compile the code in several compilers, ongoing discussions about adding new features, which compiler is best to use and all kind of useful and wasteful information. If you take a minute and watch all this lying in front of your eyes several thoughts and emotions will cross your mind, some different to each one. Admiration, excitement, frustration, anxiety just to count some of them. A common thought however would be the lack of coordination and organization. I think it's about time to do something to fix this. I suggest the following directions:
Project directions
A) Documentation
1) Document the source code. Here we actually need to a) put a description in the top of each source file of what is its purpose and function, b) comment parts of source files that need explanation, like complex functions, c) document any changes made in the code. Coders that will undertake the task of fixing bugs could handle these tasks as well in the files they are going to work.
2) Structure of the source code. Here we can map the structure of the source code and dependencies, make the code tree. This can be done in conjunction with the code documentation.
B) Compile the source code
1) Compiler. As I see it we have two alternatives: a) use different compilers to build the code. Each time a coder will change a file and compile the code on his/her own compiler all previous alterations made from other coders will have to be included as well. If the previous change was made by a coder with a different compiler then it is possible that a fair amount of errors appear and several corrections and adjustment have to be made. If the next alteration is made by the previous coder the same errors will appear as the code was adjusted to the last coder's compiler. This will force us going back and forth everytime someone with a different compiler works on the code. The other, b) would be a combination of a primary compiler and secondary compilers. Each coder will be able to use the compiler he/she prefers and send only altered files to a coder who uses the primary compiler, to compile the code and make any adjustment needed, if any. If the primary compiler is the most popular among the coders you can figure out how much time will save us. It is a good idea that the coder that receives the altered files be always the same person. You can discuss the compiler issue in the C++ Compiler: Which one? thread.
Note that there is a third alternative, modify the code so that is cross-compiler but that has not been tried yet.
2) Document compilation differences. We need to document each adjustment made from compiler to compiler or simply from secondary compilers to the primary compiler if chooce that technique, for each file alteration that gives erros to different compilers. This can be pain in the arse but it could prove to be a very useful and perhaps vital job.
C) Bug tracking and fixing
1) Report bugs. There is a good thread where you can report any bug that you are aware of, under the CTP2 Bugs and alterations [fix list] title. Make the trouble to read all posts before you enter a bug to avoid duplications. Note that a bug tracking system is on the works and will be available soon as the default way to report bugs.
2) Bug Tracking System. We are definitely in a need of a good system. It will simplify and speed our bug fixing work. Refer to the Bug Tracking System: Which one? thread for information and recommendations on the system.
3) Bug fixing. This is one of the main responsibilities of the project. It is currently one of our primary goals. My suggestion would be to assign coders in specific areas, if possible in areas of their interest. More than one coder in the same area could be a good idea also. This is to be defined in more detail by the program leader(s).
4) Quality Assurance. Fixed bugs, improvements and additions should be validated to assure correct behavior. A test team must be formed for this purpose. This is to be defined in more detail by the test leader(s)/Manager(s).
D) Improvements and additions
1) Improvements will greatly help to make code run faster and smarter, improve they way users interact with the game engine.
2) Additions will expand the capabilities and fun of the game with new features and art.
Minor improvements can be made simultaneously with the bug fixing but major ones and additions should be done in a later stage, after we get familiar enough with the code and fix most of the current bugs so have a more stable build and solid knowledge of the code.
E) Porting the code
1) Port the code in different compilers. Actually this is already happening as we speak. There are efforts to make the code compile, link and run in MS Visual C++ 6 and MS Visual C++ .NET free of errors. There are also thoughts on using gcc as well. It is advisable that the less possible number of compilers is used so we proceed in the actual work of bug fixing and code improvement as soon as possible. In later stages it would be a good idea, possibly, to port in more compilers.
2) Port the code in different APIs. There is an attempt to port to SDL going on currently.
3) Port the code in different operating systems. Currently the only alternative operating system to Windows is Linux and some progress is done porting to it. If you have experience in programming and porting in Linux environments and you are not willing to spend any time on working on Windows environment then you can start porting the code to Linux. There are no thought currently for porting it in other operating system than Windows and Linux. That might change in the future.
F) Resources
1) Files. All files related to the project, the source code and documentation should be hosted in a server, easily accesible and with high availability. Right now the only option is settler2, the Apolyton CS server.
2) Website. We will need to run a website that will include all available information regarding the project and its progress. The website is under construction currently and will be hosted in Apolyton the most likely but that has not been cleared out yet. It is under discussion.
3) CVS. We will need to host and run a CVS. No progress has been made yet. There is an ongoing discussion here.
4) Forum. We currently use a single forum for all related threads to the project. However as the number of threads and work in different areas will increase in the future it could be a good idea to include a different sub-forum for programming related issues and another one for discussions on new additions (features, art).
That's all for now. Keep in an eye on this post as it will continually be updated with changes and additions depending on the circumstances.
Lot of work and discussion has taken place within the first week followed the release of the source code. A bit of everything, here and there. Bug tracking and fixing, minor documentation of small pieces of code, attempts to compile the code in several compilers, ongoing discussions about adding new features, which compiler is best to use and all kind of useful and wasteful information. If you take a minute and watch all this lying in front of your eyes several thoughts and emotions will cross your mind, some different to each one. Admiration, excitement, frustration, anxiety just to count some of them. A common thought however would be the lack of coordination and organization. I think it's about time to do something to fix this. I suggest the following directions:
Project directions
A) Documentation
1) Document the source code. Here we actually need to a) put a description in the top of each source file of what is its purpose and function, b) comment parts of source files that need explanation, like complex functions, c) document any changes made in the code. Coders that will undertake the task of fixing bugs could handle these tasks as well in the files they are going to work.
2) Structure of the source code. Here we can map the structure of the source code and dependencies, make the code tree. This can be done in conjunction with the code documentation.
B) Compile the source code
1) Compiler. As I see it we have two alternatives: a) use different compilers to build the code. Each time a coder will change a file and compile the code on his/her own compiler all previous alterations made from other coders will have to be included as well. If the previous change was made by a coder with a different compiler then it is possible that a fair amount of errors appear and several corrections and adjustment have to be made. If the next alteration is made by the previous coder the same errors will appear as the code was adjusted to the last coder's compiler. This will force us going back and forth everytime someone with a different compiler works on the code. The other, b) would be a combination of a primary compiler and secondary compilers. Each coder will be able to use the compiler he/she prefers and send only altered files to a coder who uses the primary compiler, to compile the code and make any adjustment needed, if any. If the primary compiler is the most popular among the coders you can figure out how much time will save us. It is a good idea that the coder that receives the altered files be always the same person. You can discuss the compiler issue in the C++ Compiler: Which one? thread.
Note that there is a third alternative, modify the code so that is cross-compiler but that has not been tried yet.
2) Document compilation differences. We need to document each adjustment made from compiler to compiler or simply from secondary compilers to the primary compiler if chooce that technique, for each file alteration that gives erros to different compilers. This can be pain in the arse but it could prove to be a very useful and perhaps vital job.
C) Bug tracking and fixing
1) Report bugs. There is a good thread where you can report any bug that you are aware of, under the CTP2 Bugs and alterations [fix list] title. Make the trouble to read all posts before you enter a bug to avoid duplications. Note that a bug tracking system is on the works and will be available soon as the default way to report bugs.
2) Bug Tracking System. We are definitely in a need of a good system. It will simplify and speed our bug fixing work. Refer to the Bug Tracking System: Which one? thread for information and recommendations on the system.
3) Bug fixing. This is one of the main responsibilities of the project. It is currently one of our primary goals. My suggestion would be to assign coders in specific areas, if possible in areas of their interest. More than one coder in the same area could be a good idea also. This is to be defined in more detail by the program leader(s).
4) Quality Assurance. Fixed bugs, improvements and additions should be validated to assure correct behavior. A test team must be formed for this purpose. This is to be defined in more detail by the test leader(s)/Manager(s).
D) Improvements and additions
1) Improvements will greatly help to make code run faster and smarter, improve they way users interact with the game engine.
2) Additions will expand the capabilities and fun of the game with new features and art.
Minor improvements can be made simultaneously with the bug fixing but major ones and additions should be done in a later stage, after we get familiar enough with the code and fix most of the current bugs so have a more stable build and solid knowledge of the code.
E) Porting the code
1) Port the code in different compilers. Actually this is already happening as we speak. There are efforts to make the code compile, link and run in MS Visual C++ 6 and MS Visual C++ .NET free of errors. There are also thoughts on using gcc as well. It is advisable that the less possible number of compilers is used so we proceed in the actual work of bug fixing and code improvement as soon as possible. In later stages it would be a good idea, possibly, to port in more compilers.
2) Port the code in different APIs. There is an attempt to port to SDL going on currently.
3) Port the code in different operating systems. Currently the only alternative operating system to Windows is Linux and some progress is done porting to it. If you have experience in programming and porting in Linux environments and you are not willing to spend any time on working on Windows environment then you can start porting the code to Linux. There are no thought currently for porting it in other operating system than Windows and Linux. That might change in the future.
F) Resources
1) Files. All files related to the project, the source code and documentation should be hosted in a server, easily accesible and with high availability. Right now the only option is settler2, the Apolyton CS server.
2) Website. We will need to run a website that will include all available information regarding the project and its progress. The website is under construction currently and will be hosted in Apolyton the most likely but that has not been cleared out yet. It is under discussion.
3) CVS. We will need to host and run a CVS. No progress has been made yet. There is an ongoing discussion here.
4) Forum. We currently use a single forum for all related threads to the project. However as the number of threads and work in different areas will increase in the future it could be a good idea to include a different sub-forum for programming related issues and another one for discussions on new additions (features, art).
That's all for now. Keep in an eye on this post as it will continually be updated with changes and additions depending on the circumstances.
Comment