- I think I aught to start building my games from the outside in instead of the inside out.
In Project Cryoship, I developed my starship energy systems this week... then I realized I really didn't have any idea where this energy was going to go, it didn't feel right at all.
I realized that I was building the furniture before the people who would live in the starship, and the starship before I had built the environment in which it operated. A lot of the reason why I've been getting stumped was the resulting lack of context.
A better way to go about it is to building the environment first, then you can understand what kind of house you'll make, the kind of people who live there, and the furniture they'll need.
I had my reasons: I was trying to emphasize the users' experience. However, there's really no reason I can't flesh out their experience in each individual component added instead of trying to start from the experience and build outward. - I think I aught to continue work on all of my old projects, assigning a single game experience goal for each, and work whichever one at a time suits my current whims.
For example:
- Project Cryoship - Single ship simulator/RPG experience.
- Planetbreakers - Multiplayer Dwarf-Fortress like experience.
- Project Cyberverse - Hacking RPG experience.
- Vehicle Wars - Persistent world game with three different perspectives of play experience.
Like it or not, one's gotta go with the flow. Furthermore, there's a much better chance I'll start releasing finished games if I revisit old projects.
It also feels really darn cathartic thinking I'll go back and revisit those old projects, likely touching them up with what I've gained in coding expertise since my last visit, instead of trying to put them behind me.
What craftsman can avoid feeling ashamed when they've unfinished work laying around the shop? What craftsman wouldn't feel pride releasing something they've toiled on in secret for so long?
Progress on Project Cryoship has not been fruitless, but it has been produced the following set of realizations.
| |
Aug 8 2010, 5:55 pm
|
|
ACWraith
 |
Despite knowing better, it took me far longer than it should have to start implementing things top-down. =(
|
I do think that the outside-to-in approach is usually better, but there are some cases where you might want to work on lower-level details first. To decide what players will be able to do you might assume that a complex starship energy system exists, but will you be able to implement it? To design something that relies on the presence of another feature, you have to know that the feature is imeplement-able. Most of the time you can say "I might not know how to do it, but I'm sure it's possible", but sometimes you might have more serious doubts. When you do, sometimes it's worth jumping into the inner details first.
Edit: This usually happens when it's more of a technology risk (i.e. "can BYOND do this?") not a personal one ("can I do this?"). A better example would be if some element of your game relied heavily on server-to-server communication. Before going ahead with the design you might want to put together a test program to prove to yourself that BYOND can handle the amount of server-to-server communication you'll need to use. | |
How about trying to plan out development? Make an outline of all of the systems, and figure out which systems are dependent upon others so you know which ones to develop first and how they all fit together.
It generally helps when you have a clear vision of the end-product so you know what direction you're developing in (also helps with fitting different systems together) | |
@ACWraith
I resemble that remark. @Forum_account Games being a microcosm to life, I suppose any rule is going to have exceptions. As some like to say, the exceptions prove the rule. (Although that saying has always bothered me: no, the exceptions disprove the rule.) I've played so many online games in the past that recognizing server/client interaction is practically second nature. Nothing I've developed yet seems to have any difficulty along those lines. Although there are certain limiting factors in this engine - BYOND isn't my first choice for fast-paced action games - it's a great platform for online play. @D4RK3 54B3R How about trying to plan out development? I've been trying to plan out development for years. Not to long ago, I put my foot down, and said that this time I'm not going to write a single line of code until I have a complete design. That backfired. It seems my ambitiousness is greater than my skill, the kinds of things I want to make simply can't be visualized to completion by me. All the pondering I'll do in an effort to establishing a clear vision of the end-product seems to have no end, and only paralyzes me. I've recently decided it's better now that I get myself to produce something. Taking a top-down approach is one way to bridge the gap, because I can build the outer architecture before worrying about the smaller details. | |