January 22, 2012

Galaxy Engine - Project Closing
By Justin Meiners

It has been over a year since JAM Studios first launched Galaxy Engine, but now I have decided to officially close the project. This has been a great learning experience for us technically and from a project management standpoint, but for me personally I have learned far more about community management and working with everyone involved with open source. It was awesome to hear from everyone telling me about new projects you were working, or feedback and improvements on the engine. Seeing what people were doing with the engine was truly amazing, It was also great to work with all the community projects and everyone involved brought a lot of experience that our studio could not provide. I thought after such a great and sometimes difficult experience I would take this opportunity to share what I have learned.

Techincal
One thing that became very apparent early on, was that it was extremely difficult to design project components with having a strong core system built. Nobody at our studio had any low level 3D graphics experience and so we really did not know the way things should work or be designed. I started out with some basic proofs of concept and a core architecture we had used in 2D games, and built essentially 3D special effects off of that. It then became a pain to keep these effects functioning as the core matured. One good example of that was the terrain system, which was written even before we had static meshes loading. The terrain was written to handle just terrain rendering and it had to be rewritten numerous times just to successfully compile as new scene architectures came out and many core features suffered because of this. Any of you familiar with the project know several of these classes in a poor state that are still part of the source. Another big lesson we learned, was that it was impossible to create such a system that had so many parts relying on each other, without having a demo to constantly be building on. We didn't do this earlier on and wrote classes with the mentality of "this is how I think this will work" and testing without actually using them the context of a real game. As we began to use our tools and code for a demo, design flaws and bugs became obviously apparent in a way that could not have been found another way (How many revisions of the material system did we go through in a month?). Another advantage to doing this, was that it helped prioritize what were necessary features and what were just extras. Our rendering architecture is also complete garbage and its design came from the simple lack of inexperience with 3D graphics. It is still a miracle to me that side by side OpenGL ES 1.x and OpenGL ES 2.0 rendering work (I promise it actually does). The cross platform support was constructed in a similar way to the rendering architecture and although they both were slightly improved, it would have called for a total rewrite of the engine to really fix either of them with the knowledge we have now. One of our biggest selling points with Galaxy Engine was that it was based on Objective-C, a language we loved and other people were more comfortable with too. Using Objective-C ended up being a bad decision for larger scale games, and objc_msg_send showed up at the top of every profile, leading us to rewrite more processor intensive components in C which became hard to work with compared to the rest of our OOP. C++ can provide almost all the OOP features of Objective-C, and with speeds far faster than it too. I have worked with C++  for almost as long as Objective-C now and I can tell you that the benefits of using C++ far out do the pains that come with it for high performance applications.

Project Managment
The best part of operating Galaxy Engine was working with the open source community. Galaxy was featured on many blogs and I was blown away by the initial amount of users that came in contact with the project. I was unprepared for this and consequently few learning materials existed at launch. This large interest also brought several very smart contributors that made some valuable additions, but we also learned one very important lesson. You cannot rely on the community to bring critical features to a project. I started out dividing up features to different contributors, but some were inconsistent with their work, or didn't know the rest of the project to make their feature fit correctly. Giving them direct access to the repo also led to some issues with Xcode version compatibility and changed settings being committed, breaking the code for everyone. If I were to do it again, I would take a Blender like approach to development. Critical features would be developed in house and community developments would involve evaluating and integrating the best branches.

I will keep the Google Code page up for a while, but eventually it will be shutdown. We will still provide a zip of the source code as some projects still use it extensively. I hope someday we will return with a new and improved open source project. Thanks to everyone involved with the project!

 


May 23, 2011

JAM Studios - Update
By Justin Meiners

Hey, sorry its been a while. We have all been really busy with stuff and I know a lot of you have been wondering what iss going on. Galaxy Engine development by any of us is currently postponed. We are moving in a different direction right now and we can't afford to have anyone committed to it. I will still be providing some help and bug fixes, just don't expect any new feature updates. The latest version (0.9) completes the platform system so you now should be able to develop for OpenGL, OpenGL ES 1.x and OpenGL ES 2.0 with minimal changes to your project. I have a small sample of OpenGL ES 2.0 which I should get on the repository some time. Most of the systems in the current release work very well and will get your project done.

If you have any questions email us at [email protected]!

On another note I decided to write this little feature on what I thought some of the most influential games to me have been. So here is a quick rundown on some of these and a statement on why I think they are. I am also not going to get into the way old school stuff so nobody cry about Joust or something. I want to start writing more posts like this so hopefully you guys like them!

Super Mario 64 - Brought the 2D platformer to 3D and created the basis for pretty much any 3D game.

Doom - While Wolfenstein may have invented the FPS, Doom made it popular and the technology brought from it has been used in hundreds of games since.

Call Of Duty 4 - If you love or hate Call Of Duty you can't deny the influence this game had. It obliterated everything multiplayer before it and the system of a persistent multiplayer character with EXP and unlocks has been in any every major multiplayer shooter since.

Super Metroid - This game made big innovations in storytelling and the adventure game concept of unlocking abilities that then allow you to explore previous areas has been used in numerous adventure games since.

Halo - Revolutionized the shooter with its incredible game mechanics, single player, and LAN multiplayer.

Metal Gear Solid - Nobody had seen storytelling and presentation like this in a video game before. Kojima had you hooked from the first cutscene and connected you with relatable characters and conflicts.

SimCity - Just go play the original and you will see why. Back in the day there was no such thing as game genres a bunch of people just thought what would be fun? This game is a perfect example of this.

 


Old News


CakePHP: the rapid development php framework

Peak Memory Usage: 6.126 MB