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
(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
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.
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
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
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
is the project philosphy?
The project philosophy can be divided into the
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
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.
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.
is the current status of the project?
The current status of the project can always be found at the State of the Universe Address.
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
reasonable mock up of what the game might be like, based on the eclipse
architecture. No actual functionality, but plenty of code
May 30th, 2004 -
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
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!