In recent months, the galactic rumour mill has been buzzing, and we have frequently been asked if and when we are going to bring out Galaxy on Fire™ 2 for the iPhone. First, the good news: yes, we are bringing out GoF2 on the iPhone and we have been working all out on it since October of last year. But we still need quite a while, because GoF2 is an unbelievable complex and extensive game – and our quality standards for what we want to offer you are, as ever, high. To make the wait a little more bearable and to give you an impression of just how all-encompassing the work is and which details we are polishing, we will begin describing all of this regularly in our developer diary, starting now. To take a more laid back approach to all of this, we will let those mainly responsible speak for themselves in interviews.
Let’s get started with Hans-Christian Kühl, also known as HCK, the lead developer of Galaxy on Fire™:
Where did the original idea for the GoF [Galaxy on Fire] series come from?
I had the idea after we had finished some smaller games like Motoraver and Robot Alliance. I thought, ‘Let’s see what will work,’ and started to make a tech demo, that I then later expanded. After that, more people from Graphics and Design came on board pretty quickly, and the project was born.
Was it difficult to convince owners Christian Lohr and Michael Schade of the concept, or were they both excited from the beginning?
I think they thought it was a good idea from the start, especially because it was so open and free compared to projects like Motoraver or Cloud Commander, which were limited to single roads or a canyon. With GoF 1 we already had 500 different planets and 100 systems, which almost no one could have imagined for a mobile game back then.
…and thus taking a step away from linear level design toward a sandbox, an open world?
Yes, originally it was just 13 missions that had to be played through. Afterwards, the system opened, and you could fly everywhere – that was a major innovation at the time.
Playing GoF brings back memories of classic titles, especially Origin’s Wing Commander series and its sequel Privateer. Did titles like that influence the development of GoF?
„Privateer“ was kind of like „Wing Commander“ with added tradesystem and more freedom. „Freelancer“ was really the first game, that combined the best aspects of the previous titles – namely a good story, a huge universe with several factions, a tradesystem, individual ship-modification, ore-minig, generic missions and lots and lots to discover. Definitely an inspiration. An additional source of inspiration concerning the productions of various goods according to blueprints has been „Eve Online“.
What are you currently working on for GoF 2?
Currently, we are working on 3D models of ships, weapons, asteroids, as well as various hangar scenes and the bar where you get new missions. At the same time, Marc Nagel, our art director, is making 2D concepts for new ship models. Then I try to bring it all together. Next, Marc and others will help me with that and deal primarily with the shader, so that everything looks right. And, of course, we mustn’t forget the sound. We’re still looking at a lot of work.
What adjustments are necessary for porting GoF 2 to the coming C platforms?
The most conspicuous thing is the graphics. But for me as a programmer, the change from Java to C is the biggest step. Unfortunately, there’s no tool where you can push a button and everything is reformatted. Whole concepts need to be redesigned. And with a huge game like GoF 2, that already wasn’t easy with the Java version. The Java version of GoF 2 is based on a predecessor, Deep – an underwater game that was itself based on GoF 1. That means there were already two intermediate steps from development to improvement. Porting all of that to C was extremely difficult. Since we already had GoF 1 in C for the iPhone, I first had to consider whether I should take the GoF 1 version in C and turn that into GoF 2 or take the GoF 2 Java version and port that to C. I must have needed 2 weeks just for that decision. Ultimately, I decided to convert the Java project Projekt completely into C, and that was good. Of course, that is only the technical side of the programming. With the graphics, everything had to be adapted, there was no stone left unturned.
Will the work on GoF 2 make the work for upcoming projects easier?
Of course, there’s always some benefit. For GoF 2, for example, we are currently working a lot with geometry and texture shaders under OpenGL ES 2.0, which we will certainly be able to reuse in future projects. Other components of the game, such as the depiction of space with nebulas and the simultaneous depiction of a large number of objects, will also be able to be reused. But naturally, we will get the greatest added value if we develop a sequel to the current title or integrate add-ons like in-app purchases, that unlock new levels or equipment.
The GoF 2 port also resulted in a conversion from integer to float. Why? What are the advantages?
All newer end devices use a floating-point processor. Floating point operations [mathematical calculations using floating point numbers] are carried out in the hardware. For older Java devices, we realised projects using integers, because that ran faster and those devices did not have their own floating-point processor in the hardware. That brings some simplifications into the game: for example, we no longer have to calculate everything large and recalculate it small again later in order to realise small numbers in this way. Actually, we can now compress the whole game much smaller, so that the units of length are smaller. Previously, a ship had to be 1000 length units in size so that it could move smoothly. Now, a ship can theoretically consist of just one unit. Visually, the changes in the game will be apparent in that things no longer shake during camera rotation and navigation.
Does being able to use float also reduce the programming effort?
Not for GoF 2, of course, because this is primarily a port. In this case, the conversion is rather complex. But for future productions, it will be good that we can rely on floating-point.
What else has been especially difficult to implement so far?
Memory management in Java and C is completely different. Unforeseeable problems could crop up any time. You could play the game for two hours and suddenly it crashes, and at first you don’t know why – it is probably because someone at some point didn’t release something somewhere, where everything occurs automatically in Java. In addition, we now have a lot more textures and of course everyone wants everything to look great. But we ‘only’ have 10 – 20 MB of texture memory available. In comparison, with Java we had to get by with 512-byte texture. Everybody in the team said, ‘Oh, everything will fit in, we have to make use of this somehow!’ Now, they all come and say, ‘Everything should look really good now, and we still need five 1024-byte textures…!’ In the end, we have to sit there and make sure we don’t pack too much content into the game.
To be continued…
Become a fan of FISHLABS on Facebook for instant updates on all current projects.