Meglomania
Frequently Asked Questions

April 5th, 2004
Justin Wick


How did Meglomania begin?


In late March of 2004, my good friend Wesley Paul stopped by my place in Pasadena, CA, and we had some rather lengthy discussions. One of the things that came out of the discussion was that we should finally get around to making that space conquest game that we'd both been thinking about making for many years (independently).  It turns out that we both have a passion for that kind of gameplay, and that we both have many ideas.  An homage, a tribute to those games of the past like Masters of Orion II, or PaxImperia.  Both had a profound influence on my youth - by day I was slaving away at busiwork in junior high, but by night I was emperor of a vast and ever-increasing space empire.

So what is Meglomania anyways?

Meglomania is a 4X Space Strategy Game.  4X stands for "eXplore, eXpand, eXploit, eXterminate."  It describes the essential elements of the gameplay of this genre, namely an unencumbered expansion that results usually in the complete annihilation of all other players.  Exploration is the vehicle of resource exploitation and strategic positioning, expansion, and finally attack.  The basic game goes as follows:

You start out as the emperor of only one planet.  As the leader of your race, you decide how resources are spent.  You erect enormous constructions and commission great starships to explore the vast reaches of galactic space through newly discovered hyperspace pathways.  Colonization brings the fire of your civilization to other worlds.  Scientific discoveries open up new and exciting possibilities.  The galaxy is yours to command - until you make first contact.  Diplomacy, espionage, treason and war soon follow.  Even alliances must end someday, the galaxy's resources are finite, but your thirst for victory is not.

It should be said that Meglomania actually encompasses two slightly different but interconnected projects:
1.  Meglomania - the playable game, including data files, rulesets, and media
2.  Domination Engine - the underlying engine kept somewhat general so as to be useful with radically different rulesets, licensed open source so others
can make their own space conquest games.


Why are we doing this?

Well, there are many reasons.  Below I'll attempt to enumerate the most important of them.

1.  Entertainment -  Playing and making games is fun.  Okay, so maybe not 100% of the activities are fun but, all in all, it's a bit of an adventure.  To create something in your mind and then see it realized - perhaps one of the strongest and most basic of human drives.
2.  Education - There is a good chance that I'll be utilizing the Eclipse framework (and one or more other technologies associated with this project) at my day job at the NASA Jet Propulsion Laboratory, so I would like to become familiar with this.  Also, building skills associated with software architecture and project management is a big plus.
3.  Recriprocity - I have personally benefitted tremendously from open source software in my life, and the project I work on at work uses, and even incorporates quite a bit of OSS.  I believe that this is a way that I can give back to the community, especially Eclipse.  I'm a total Eclipse fanatic.
4.  Social Networking - Open Source is a great way to meet new people that share your interests.  I look forward to working with people I'd never have met otherwise.
5.  Advancing the State of the Art - Masters of Orion was the single most dissapointing video game I've ever played.  I feel that if Meglomania reaches maturity successfully, its presence in the market may actually spur improvements in the upcoming crop of commercial video games.
6.  Technology Testbed - A system like this is a rather good testbed for Artificial Intelligence algorithms, and a variety of runtime optimization algorithms, including distributed processing.


What is the project philosphy?

The project philosophy can be divided into the following assertions:

1.  Iterative Test Driven Development - Always have something which is working and tested available, even between "releases."  All code in CVS must
compile, and only "experimental" portions are allowed to be broken severely in CVS.  Always having something working means there will always be something to show for the teammembers effort.
2.  Division of Labor - Each project member is assigned tasks based on his/her unique skillset.  If a task is not suitable for anyone, and not vitally important, it may wait until someone comes to the project who can perform it properly.
3.  Quality Over Quantity - Part of utilizing test-driven development is so that we can have a high level of quality assurance.  Games are not fun if they crash often, especially if you lose your game in the process.
4.  Originality is Overrated - Seriously, coming up with things so weird that no one in the history of mankind has ever thought of, that's not what this project is about.  We want to take the best elements from other related video/board games, combine them with a few new ideas of our own, and enjoy it.
The project will only be different from said games when a difference is deemed to have a net positive effect on the game or development time.  We do plan to give credit where credit is due, however.
5.  Efficiency is Overrated - Many coders have this efficiency-worship mindset which distracts them from the real issue of programming - getting computers to do useful work.  Lets face it, computers are doubling speed every 18 months, and memory capacity has been skyrocketing, allowing computers to do many new and exciting things.  Gamers tend to have high-end PCs, and games can be written to take advantage of this.  My 1 GhZ G4 Powerbook 17" laptop is the slowest computer that this game will target, and even so, a lot of performance tuning can be handled by reducing graphics quality, etc.  Our motto in regards to optimization is thus: "Make it work first.  If part of it is too slow, and easily optimized, optimize reasonably, test thoroughably, and then move on to the next task."  Programmers who don't optimize every little thing are not necessarily lazy, they are often pragmatic.  We will utilize profilers to figure out where bottlenecks in our code are so that we can increase overall speed.  The most heavily optimized portion of our game will involve the graphics (of course) however it is not yet known how optimizable this will be.
6.  Documentation is Important - Code is prototyped through a "document first" approach - that is, we do not document our code, we code our documents.  Because code is written less impulsively, this should help reduce the number of errors and thus increase our quality factor significantly.  Also for projects to be truely collaborative, it's important to have a universally available collection of design documents which are representative of the collective though processes of the designers.
7.  Software and Media Re-use - Our goal is to make a playable game and a useable engine, not to write X lines of code.  In fact, it is our stated goal to avoid writing redundant code where feasible, and to utilize well-developed software technologies developed and maintained by others.  We believe that this will significantly accellerate the pace of our development, and it is the driving factor in our liscensing of our project under the GPL.


What technologies will be incorporated into Meglomania?

Eclipse - A rich client platform supported by IBM and other industry heavyweights.  Comes with SWT and JFace, two incredible user interface libraries.

Hibernate - A SQL-database object persistence system.  This will be used to accomplish multiplayer communication and synchronization for the most part.

HSQL - A pure-java pseudo-SQL server.  Used in conjunction with Hibernate to enable all clients to be multiplayer servers.

So far that's all that's been confirmed for sure, however we will most likely use a lot of other technologies.  A full listing of technologies that we're looking into can be found here.

What is the current status of the project?

The current status of the project can always be found at the State of the Universe Address.

What is the timeline for the project?

The preliminary timeline is:

April 5th, 2004 - This web site erected
April 30th, 2004 - First technology demo - eclipse plugin.  Should be a reasonable mock up of what the game might be like, based on the eclipse architecture.  No actual functionality, but plenty of code demonstration.
May 30th, 2004 -



How can I help Meglomania?

1.  Use the program and report bugs - not only does more widespread use of the program encourage its development, but bug reports are an important way QA is maintained.
2.  Contribute Code - Sign up for the projects and get some tasks assigned to you.  Provided you're willing to write code that's up to the level of quality of the rest of the program, any help is welcome!
3.  Contribute Media - Music, artwork, as long as it's your work (or you can prove it's liscensed under the terms of the Community Commons or equivilent) is important to the look and feel of a game.  If you're artistic, we'd love your help.
4.  Microtasks - Our task tracker contains items noted as being "microtasks" which are relatively independent of the rest of the project, and only take an hour or two.  These are often times simpler than many of the other tasks, and can be a fun thing to do during a break.  Do one, do a few, it's up to you!