Phoenix

Java clone/remake/patch of the game Emperor of the Fading Suns (EFS). This software is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. Uses original EFS data files and requires EFS 1.4 to be installed. Should work with all mods. Phoenix website (may be more easily navigable than this document.)

If you have a mod that works with EFS but not with Phoenix open an issue (if you have problems with Hyperion, read New in version 0.9.1 below first.) If you encounter a Java Exception or Error, or Phoenix won't start or crashes, open an issue. Being bug free is important, being crash free and supporting all EFS mods is critically important.

TOC

• News
• Contributing
• 1: Getting Phoenix
• 2: Installing and running
• 3: Changes
• Copyright disclaimer

News

Version 0.50.0 released 20 oct 2015

Contributing policy change to "Yes for predefined tasks" as of 28 apr 2015

Required java version for precompiled release binaries changed from java 7 to java 8 as of 5 may 2015

Project format changed from native NetBeans to Apache Maven as of 18 may 2015

End user distribution changed to single unified zip file as of 19 may 2015

Contributing

Policy

"Yes for predefined tasks." (Tasks which require no programming also available, see below.)

Important note: to maximize the chances that Phoenix stays afloat legally, the Phoenix distribution SHALL NOT contain any copyrighted material beyond that which is necessary to reproduce "EFS.EXE" functionality (such as faction names, some static GUI texts and the GUI layout specifications. But NOT the values of variables in "DAT" directory.) Instead, all material SHALL be read from the separately user installed EFS1.4 (and mod) files. As a rule of thumb, if it is not in "EFS.EXE" it must be excluded from the Phoenix distribution. This rule includes the project wiki (and actually everything published by the legal entity distributing Phoenix.)

Another note: this is my first time officially administering a project publicly, so expect things not necessarily working as expected out of the box.

Project format and development tools

Before v0.11 all Phoenix code has so far been Java 7 compatible and NetBeans alone has been the IDE of choice. This is now changing, at least partially. The core Phoenix code will likely stay purely Java, but if convenient, certain functionality could be implemented with other languages and/or even be independent side projects. All such solutions must however be distributable in formats compatible with the major Java platforms (at least BSD/OSX, Linux and Windows.)

Phoenix used to be a NetBeans native project with NetBeans metadata. The project has now been converted to Apache Maven format (the directory structure is so far not converted to Maven default.) The rationale was that Maven format and tools are supported by all major Java IDEs (eg. Eclipse, IntelliJ IDEA and NetBeans.) A recent survey had 97% of responders say they use an IDE, with 48% using Eclipse, 26% using IntelliJ IDEA non-free, 10% using NetBeans and 7% using IntelliJ IDEA free. Now, this is just one web survey, but if it has a grain of truth in it, then it seems that by having a common free project format, possibly an order of magnitude increase in potential contributors could be achieved if free choice of IDE is a major deciding factor.

I have most experience with NetBeans, some with Eclipse and none with IntelliJ IDEA, and so far only NetBeans and Eclipse have been tested with the Maven format Phoenix. Thus, if someone comes along with a strong background of IntelliJ IDEA or something else, and would like to stay exclusively with them, the Phoenix project currently does not provide much out of the box support beyond being Maven format. But then again with my short experience in doing larger than small real world projects, I would not expect to be able to advice veteran developers.

A bit of history

This section used to officially discourage all contribution. It's not that I don't value cooperation (and some people have actually provided code) but I considered myself a lousy project manager (still do) and will rather spend my time coding than integrating. But as a project, Phoenix has advanced far more than I wagered when I started.

I thought the project is probably going to be abandoned before any running code is produced. So far (as of 28.04.2015) it has taken 2,5 years of real time to get here (actually, code reading the various graphics formats was written in spring 2010.) If Phoenix is to reach a stage of playability equaling (and hopefully above and beyond) that of EFS1.4 and I work at the same pace and with the same mentality it may take 2,5 to 5 years to finish at minimum. I would rather it didn't take so long. Thus, the policy of no contributions will be at least temporarily suspended.

Mostly this will depend on my ability as a project manager. I find myself bad at managing teams of people. Thus, contribution process will be as loosely integrated as possible, without compromising ultimate project integrity. This will hopefully be achieved by trying to identify sub projects which require maximally independent implementation.

Defined tasks and being assigned

Potential sub projects or simply "tasks" are defined as issues. A preliminary list of tasks is found in issue #4. All contributable tasks can be found by selecting issues with the contributable label Read the issue of the task that you think you can do and post your intentions to "Task assignment thread" #12. From simple implementation POV (assuming maximally independent tasks), task assignment may not be strictly necessary. From project POV, task assignment ensures no duplicate, useful, work is produced needlessly.

Don't worry about possible failure

Now, I can't force anyone to enlist. But, do not fail to enlist because you think that you may not produce any useful results and that you will be embarassed later for having to publicly admit that, implicitly or explicitly. When I considered setting up camp at GitHub and thus releasing Phoenix source to the public I worried about what people would say about the quality of the code (consider this brilliant 30 line display of craftmanship ... of course, that should not be taken as a style suggestion) but I have had nothing but positive responses to Phoenix, even from those who have certainly taken a deeper look at the code. If you enlist, and then fail to produce anything beyond "Sorry, I failed :(" then consider that at maximum, all that was wasted was your time and effort, and even then that was probably a learning experience. You weren't paid and the only administrative effort is removing @yourusername from the assiged list for the task.

Consider these words of famous physicist Freeman Dyson: You can't possibly get a good technology going without an enormous number of failures. It's a universal rule.

For those who are thinking of coding, tasks "Automated testing" #5, "Automated test generation" #6, "Unit window animations" #7 and "Random galaxy generator" #8 should provide tasks with simple or no necessary administrative Phoenix code integration. The tasks that require no coding obviously require no code integration and as such cannot have negative impact on Phoenix code.

Main repository contract

Notice: the following "repository contract" is not a guarantee or warranty. "Contract" is to be considered a software engineering term, not a legal term.

In the main Phoenix repository the default branch is master. As per git default configuration this is the branch which will be shown when the Phoenix link is clicked. The master branch SHALL contain all the releases, excluding orange "Pre-releases", and is intended to be kept at production quality at all times. A master branch HEAD which does not compile or run is considered a critical bug and should be reported as an issue (presently, I only have access to Ubuntu 1404 and Windows 7 so in the hopefully rare event that errors concern BSD/OSX or something else I am not in the position to make specific attempts to fix bugs in those cases.) Initial feature development and/or testing SHALL not be done on the master branch. The master branch SHALL not be rebased, amended or its history otherwise altered unless critical issues such as serious errors or copyright violations are revealed or the proper authorities (eg. GitHub administrators) issue directives.