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: 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.
E-mail webmaster at
rmcleod@uvic.ca .