As I learn more about programming and software design, I always ask myself tons of questions about how and why things are constructed a certain way. For me, I would normally start by creating the primitive objects, and would then make objects composed of these smaller objects. The end-goal is to create a vast system that was built form the ground up. This is what is known as bottom-up design.

However, many unfinished projects later, I found that I was having a really hard time linking all of my systems together. In the beginning it seemed pretty easy to start writing up little objects that could work inside of bigger objects (like a 2D point, or a number with constraints), but when I started to move onto bigger object compositions, things got very complicated. I found that I was making myself a huge mess that was almost impossible to keep track of.

So, recently, I decided to swap my way of design and go with the opposite way: top-down. The way this works is that you look at the big picture at all times, looking downward into the systems that would need to be created so that if you do happen to need to create something that does a certain job, you make it. This method ensures that whatever it is you're making will make use of everything that you create for it.

The way to go about designing this way is to first think of the general concept. If it's a game, then think of it simply as "Game". But what does a game have? Ah, this is our first step in top-down design. We must then think of what a game consists of, which might be sprites, levels, enemies, weapons, powerups, and whatever else might be necessary. The key factor is that these things are all linked to a root object in some way.

In Object-Oriented programming (Java at least) software has an entry point which is commonly enclosed in a class. This class is the super object which maintains all other objects created for it. It represents the program's very being and if ever removed, the program ceases to exist. It's like a universe for your software.

BYOND is sort of like that too in a way with world, although your interaction with it is a bit skewed and not quite as direct.

Back to Java. A common way to bring a universe to life is to instantiate the class it is contained in (new ThatClass();). This begins the class's constructor (like object.New() in DM) which in turn plays out whatever is necessary for the program to be run. The class is the program itself. This form of containment, called encapsulation, keeps everything kept inside of it. Not having to worry about anything else, we can begin to shape and mold our program however we want, knowing that we have already created a complete program, even if it does nothing.

Programming is a lot like circuitry. We need a complete circuit for it to run. Otherwise, something falls short and we have to go back and find that error so that it does run. In bottom-up design, the components needed to form the circuit are created first, not really having a clear idea of what the completed circuit looks like until it is finished. In top-down design, a blank, basic circuit is presented, and more complex systems are made to operate off of this, knowing that we still have a complete circuit upon every component created for it.

Each direction of design has its uses, but at least for me, bottom-up design was probably not the way to go in terms of game design. It does make sense to create components that could then be reused as many times as I would like in the program, and even other programs, but in the end, I still didn't have a complete project. So if something doesn't work one way, try another. This is what I shall do.