Return to SourceForge NetColony Summary

NetColony is a political simulation game focussing on colonial development. As a political simulation, a range of human affairs is covered in the game: war, economics, crime, science, etc. Players manage Interests, each being a political force with a specific Agenda. The Agenda is what the Interest must seek to do, and its success will be judged not by how much money it has or how many units it has, but by how well it met its Agenda. It is possible to pursue an Agenda with no money, no units, nothing at all but sheer political power, a factor we call in this game Influence. There are many different kinds of Interests: some are government agencies, some are corporations, some are institutions. The game is based on Ben Levy's Pi3Orionis PBEM game.

The game runs in a play-by e-mail style, somewhat like Stars! or VGAPlanets. Turns represent six-months of game time and can take up to a month of real time as all the political jockying goes on. Normally, the game is run by a referee who adds a lot of flavour and versatility to the game engine.

Project Organization

The project is organized in two ways. The first is the program/ package hierarchy, which represents the physical code using the standard Java abstractions. The second is the conceptual project/subproject hierarchy which represents continuous and separate work areas.

The program is defined to be the complete set of source code, while a package is contained in an individual directory of the program structure.

The 'project' is a defined work area, such as programming or graphics. These projects are then further divided into sub-projects. Generally people will be assigned to a single sub-project but obviously there will be a fair amount of cross-over.

Communication will hopefully be accomplished by using a set of mailing lists. I will create a forum or mailing list for each subproject. I.e. netcolony-design, netcolony-gui, netcolony-media, etc. This agreement would make message filtering very easy but would give every subproject its own unique archive.

The project/subproject hierarchy will be organized as follows:

• Support
• Program Structure and Game Design
• Game Resource Development
• Quality Assurance (Testing)
• Server and Technical Support
• Programming
• Graphical User Interface
• Artificial Intelligence
• Game Mechanics
• Media
• Sprite Graphics
• Art Graphics
• Music and Sound Effects

Support: Game Design and Program Structure:
The construction of the game mechanocs and dynamics as well as object oriented design of the program is mainly one of my own tasks.

Support: Game Resource Development:
This covers all the various creative writing tasks in the project, such as writing background history, producing empire/faction outlines, designing scenarios, and even writing help files.

Support: Quality Assurance:
This task will probably be given to someone involved in the game resource development once we have produced nearly functional versions of the game. It will involve recruiting beta testers and recording bug reports.

Support: Server and Technical Support:
By default this task falls to me, but I would appreciate someone to maintain the webspace and e-mail groups, as well as handle inquiries from people interested in joining the project and other various administrative details.

Programming: Graphical User Interface:
GUI programming will use the Java AWT toolkit. It may also probably also include writing new AWT components that have a customized look to them to avoid the game from looking like "Spreadsheet Battles". Of course, the game basically is spreadsheet battles so I digress.

Programming: Artificial Intelligence:
Although I have not formally desided if there should be computer players, it would be nice to at least have computer players that can act as station keepers for inactive Interests.

Programming: Game Mechanics:
This subproject involves writing the procedures that involve combat, movement, production, etc. This subproject will be fairly mathematical because of the algorithms involved. This subproject will also likely be responsible for programming wigets, like a map and unit editor.

Media: Sprite Graphics:
This subproject involves producing sprites for the various map graphics, such as terrain, structures, units, etc. It would also involve drawing GUI graphics. The images should be in GIF87 format, and any transparency should be in magenta -- that is, R255-G0-B255. If a colour palette needs to be supplied, I will do so.

Media: Art Graphics:
This involves producing the various scenes displayed for the opening screen, game events, etc. JPEG format is the most likely to be used, as I assume any artists would want to draw and then scan images.

Media: Music and Sound Effects:
I'm not very familar with the development of sound effects. Any theme music would probably be in MP3 format, but music and sound are not among my priorities.

We will be using Java 2 SDK ver. 1.3. This is the latest stable Java development kit, and includes a Just-In-Time compiler from Systamac (IIRC). It also includes the Java Foundation Classes, formally known as Swing. I have a personal dislike of Swing.

The choice for using Java over other possible languages and libraries, such as C++/OpenGL, was made for a variety of reasons. Java is easier to write in and is more self-consistent. It has a number of built-in packages that provide functionality that C++ with OpenGL simply don't have. Java has much greater cross-compatibility. Java is completely free and downloadable by all, and even more importantly it has a non-restrictive license.

The negatives generally revolve around that fact that Java is slow. However, the Just In Time (JIT) compilers continue to improve in performance. I have seen recent benchmarking that showed Java to have an impressive fraction of the performance of C. Also, our computational demands will not be that heavy. The other disadvantage of Java is that, because of its cross-compatibility, it does not offer low level access, which can make customization difficult.

I would like to ensure that the program works on Windows32, MacOS, and Linux platforms. Currently, I am concerned primarily with testing the software for Win32 and there is no support for the other platforms until someone offers to provide it. I would prefer not to use the Java SWING libraries if possible -- they seem to be excessively slow and they have difficulties painting under my mouse cursor.

I'm currently the webmaster. I'm interested in giving this up. Sourceforge provides our webspace, of course.

I assume some form of version control will almost certainly be necessary unless the programming team is very small.

SourceForge does, of course, provide CVS server space to use.

We will be using Javadoc to create documentation, in addition to other methods of documentation. You can learn more about using Javadoc by reading the documentation for Javadoc that is packaged with the JDK documentation package. One webpage of particular interest for people unfamiliar with writing comments for Javadoc is http://java.sun.com/products/jdk/javadoc/writingdoccomments.html.

• Naming Conventions: Classes have the first letter of every word capitalized, methods have the first letter of words after the first word capitalized, variables are lower case, final (constant) variables are all upper case and words are seperated by underscores. When you can choose between a full name and an abbreviation, use the full name.
  e.g. public class BigBadClass
  protected void doInternalOperation()
  int garbagedata;
  final int HUGE = 30;
• Whitespace rules: I prefer using actual tabs characters (i.e. /t) to multiple spaces. If you cannot use tabs, use three (not four, not five) spaces. In general, all parathesis, operators, variable names, etc. should be in expanded format with a single space seperating them. This includes seperating opening paranthesis from control statements, but not method calls. However, this does not apply to typecasts.
• Curly braces: Each curly brace will occupy its own distinct line. This is clearer than the traditional Unix method of placing the curly brace on the function declaration line and allows extends and implements lines in a class declaration to have their own individual lines.
• this keyword: The keyword this should be used when it will help to clarify the origin of a variable or method. By this I mean that it is not required for methods or variables declared within the current .java file, but should be used for inherited methods and variables.

E-mail webmaster at rmcleod@uvic.ca .