Return to SourceForge FlameDeluge Summary

Introduction

Welcome to the Flame Deluge Internet Gaming Project's homepage.

Implementation of this project started about 15/06/00. The actual design was started when Star General was released and I was terribly disappointed in the resulting game. I thought the concept was solid, but the game features and balance were extremely lacking. To that end, I have produced the workings of a design that resembles games like Star General and Emperor of the Fading Suns. I have also borrowed concepts from games such as Anacreon: Reconstruction and Space Empires III.

One of the problems I encountered with the above games was an excess of micro-management. To that end, I have endeavored to use a number of paradigms in the game to simplify logistics.

This game is designed to be a science fiction 4X game (eXplore, eXpand, eXploit, eXterminate) with an emphasis on combat and the strategy behind it. The game features a strong ground combat model. City entities form the economic backbone of the game. The game is hex based, using separate space and ground maps.

The game can handle a multitude of maps, through the use of a space-space, space-ground interface. Space-space interface is handled by jump points, through which most starships can move.

The game does not rigidly stratify forces into players; instead any unit must belong to a faction. Instead of a few large empires, there are a very large number of factions – potentially more than one per planet – each of which maintains its own agenda. However, the majority of factions are non-aggressive and non-advanced so they do not compete on the same galactic scale as human and major AI participants. This generates a game with a more homogenous and realistic feel to it.

Overall, the game strategy is designed to present the following operational problems in the course of planetary conquest.

• Assault and consolidation of jump points entering a system.
• Performing pursuit and approach operations in deep space.
• Establishing space control around a contested planet.
• Performing planetary interface assault operations to place units on the surface.
• Establishing and consolidating a landing zone and constructing a temporary spaceport to provide resupply.
• General ground combat operations against front-line units.
• Assaulting static defences and entrenched units in the aim of capturing cities.

Also, the following secondary strategic options should be presented.

• Economy development.
• Commerce raiding and the use of pickets to counter.
• Guerilla operations.
• The use of CBR (Chemical/Biological/Radiological) and weapons of mass destruction in place of conventional weapons.
• Covert operations.
• Diplomatic operations.
• Technological development.

The economic model of the game is resource based, and cities form the primary economic entities. Population is used as the primary conditional limitation on the construction of resource producing and manufacturing facilities, as well as military units. Inter-stellar commerce is modeled using an abstract paradigm based on shipping capacity.

The technology in the game does not break with current physical theory, with the exception of the jump points used to traverse star systems. Anti-matter engines power starships while ground units utilize fusion power. Starships engage each other with x-ray lasers and guided hyper-velocity kinetic penetrators. Ground units use hyper-velocity rockets armed with a variety of kinetic and explosive warheads launched from gun tubes. Some visible wavelength lasers are used in special applications. Most ground units are quite lightweight so they may be boosted out of a gravity well easily and use wheeled locomotive systems.

The demonstration version of FlameDeluge is packaged in .jar format. You will need the Java Runtime Environment (JRE) to run this program.

Program files are now available only via the SourceForge file interface.

• SourceForge FlameDeluge Summary

If you are interested in joining the project, please send me e-mail at rmcleod@uvic.ca. Please tell me what sort of skills you have, what level of commitment you are willing to make, and what subprojects you are interested in working on. Of course, you can mail me just to ask questions too.

I have made available a copy of the primary design document, in Rich-Text format. There is also a game resource/background document.

Design documents are now available only via the SourceForge file interface.

• SourceForge FlameDeluge Summary

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. [Deluge-test], [Deluge-GUI], [Deluge-Media], etc. This agreement would make message filtering very easy but would give every subproject its own unique archive. For those who are filter-declined, you have the option of receiving a daily digest from E-groups or just reading message on their website.

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. I want input from other project members on these issues, but the final decision on what concepts to include and which to discard is mine.

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 will also probably also include writing new AWT components that have a customized look to them to avoid the game from looking like "Spreadsheet Battles".

Programming: Artificial Intelligence:
Since the game is hex based, but at a very large scale, the AI needs to be quite complex and abstracted at several levels for it to be sufficiently aggressive and competent. The initial AI design uses four levels of abstraction and uses a behavior based procedure model, with the behaviors being designated by the upper abstraction layer. I strongly want to implement influence mapping to observe its effectiveness.

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 do not expect anyone to produce sound effects, as normally these are purchased. The development of theme music is a difficult question -- MIDI sounds very bad on most popular sound cards but other formats occupy too much storage to be easily distributed over the Internet.

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 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 .