Solomn Architect wrote:

From here, you write about 5 - 15 broad Features that you plan on including in your game. These Features are what distinguish your game from the others.

That sounds good, but...

both the Core and Feature List both seem so eerily similar to almost every other MORPG

So much for distinguishing this game from others =)

I'd take the opposite approach. Being overly descriptive seems like a good approach. It sounds like a smart thing to say "let's plan everything before making it", but that's not necessary. You're just creating more work. By the time you're done describing what items are and how they can be equipped, you'll be burned out. When it's time to describe what makes your game unique your motivation will be gone.

You don't need to describe the gameplay to someone who knows nothing about computer games. You're describing your ideas to someone who knows a lot about computer games. Take advantage of this. You can skip the obvious details about how many things will work.

Whenever possible, I try to plan things in terms of other games. Instead of saying "combat is a feature of the game", you'd say "combat will be like Final Fantasy X", or "combat will be like Streets of Rage meets World of Warcraft". Often you're just describing the game to yourself, so reference whatever you're familiar with to make it easier to describe your ideas. The features you need to plan are the ones you don't have reference points for (which is worth the time spent planning, since this is what'll make your game unique). Even then, not all games have unique features, so large amounts of planning and detail is rarely necessary.

The reason a lot of gameplay sucks in most BYOND games (Yes, MOST BYOND games) is that the developers never used this model to focus the gameplay into anything coherent.

If anything, BYOND games are boring because they use this approach. People build up simple, obvious details into a mountain of work. I can't find the posts anymore, but there were some blog posts about Eternia's shopkeeper interface and how you could buy items to dye your armor. Those are the kinds of features that BYOND developers focus on far too much. Not only should those features be added later (unless the game is 100% about armor dying) but they should be trivial.

Yut Put wrote:

In the end, I came up with a very coherent and unique game that is fun to play and doesn't really feel like a clone of anything.

I'm not sure how you can come out and say it's not going to feel like a clone of anything, especially when you say you had a vague idea for a concept that mentions other games. It's just like any game you see these days, it's either a sequel or existing game ideas tweaked in some way.

I don't care if you have the best idea ever and absolutely no one has heard of it before. The only thing that matters is whether it's fun to play.

Forum_account wrote:

Solomn Architect wrote:

From here, you write about 5 - 15 broad Features that you plan on including in your game. These Features are what distinguish your game from the others.

That sounds good, but...

both the Core and Feature List both seem so eerily similar to almost every other MORPG

So much for distinguishing this game from others =)

Haha, True, it does appear as though I contradicted myself, so let me clarify. Each individual Feature does the task of distinguishing your game. Yes, all MORPG's incorporate these Features, but each Feature is different. Is Combat real-time or turn based? What are the stats of Items? Does player progression involve base levels are gauges of power, or more like a system similar to The Elder Scrolls series with individual levels in skills? Once you know WHAT you want, you can begin answering the questions of HOW will it work.

I'd take the opposite approach. Being overly descriptive seems like a good approach. It sounds like a smart thing to say "let's plan everything before making it", but that's not necessary. You're just creating more work. By the time you're done describing what items are and how they can be equipped, you'll be burned out. When it's time to describe what makes your game unique your motivation will be gone.

Motivation is another trivial matter in and of itself. If you lack the willpower to go on, then you lack the willpower to go on, no matter how you set up. People get into the groove of how they imagine their game in their head, but when they start running through the list to get that image, it can be a daunting task and you love motivation either way. If you make a solid list of features, you get tired of the list and quit. If you just start at one feature and expand, you start running into bugs, trying to fix 3-4 systems at a time because you have no organization, you feel like you're not making any progress and you subsequently quit yet again. Motivation is a matter of willpower. There's no magic formula to develop games in a manner that conserves that motivation. You just have to power through it and understand that progress is ALWAYS being made, no matter how small it may seem, and that those small progress jumps add up quickly. Unmotivated people need a Pep-talk, not another way to start over and try again.

You don't need to describe the gameplay to someone who knows nothing about computer games. You're describing your ideas to someone who knows a lot about computer games. Take advantage of this. You can skip the obvious details about how many things will work.

It all comes down to the fact that if everything is spelled out clearly, you're less prone to forgetting. Obviously systems that are very simple shouldn't be gone into great detail about, but an honorable mention will keep you from overlooking it when you actually begin programming the system. I'm a very forgetful person, which is why I take this extra step. If you have an extraordinary memory, feel free to skip it then.

Whenever possible, I try to plan things in terms of other games. Instead of saying "combat is a feature of the game", you'd say "combat will be like Final Fantasy X", or "combat will be like Streets of Rage meets World of Warcraft". Often you're just describing the game to yourself, so reference whatever you're familiar with to make it easier to describe your ideas. The features you need to plan are the ones you don't have reference points for (which is worth the time spent planning, since this is what'll make your game unique). Even then, not all games have unique features, so large amounts of planning and detail is rarely necessary.

It's this view of thinking about everything like a player that gets a lot of developers into trouble. You may take this approach, however you also most likely do subtle things from a developer's view without even realizing it. This may work for you but is so disorganized that unless you already know what needs to be done, it just makes a mess. You have much experience with game design, which is why you can simply skip the formal organization and jump right in. You know what needs to be done in what order and you do it that way. People of less experience need a framework to start with.

The reason a lot of gameplay sucks in most BYOND games (Yes, MOST BYOND games) is that the developers never used this model to focus the gameplay into anything coherent.

If anything, BYOND games are boring because they use this approach. People build up simple, obvious details into a mountain of work.

You shouldn't build onto simple and obvious details. You simply specify down until you have small enough pieces to grasp the concepts of as a whole. This will most likely take the form of procs you'll need. Like I said, knowing how your game is going to work will help YOU and that's what it's all about. Design Documents are for YOU the DEVELOPER. It's to organize everything in a coherent fashion to your benefit. This lets whomever is programming simply to read the Doc and write the code quickly.

I can't find the posts anymore, but there were some blog posts about Eternia's shopkeeper interface and how you could buy items to dye your armor. Those are the kinds of features that BYOND developers focus on far too much. Not only should those features be added later (unless the game is 100% about armor dying) but they should be trivial.

This proves my point. Dying Armor didn't fit the game because they had no Core Branch to organize and say what does and doesn't fit with the game concept. This is why I choose a very simple form of writing a Core: "My game is a [Type of Game] where the player [Goal of Game] by [Method of Completing the Goal]." This makes a very bold statement that can be followed very easily. If you wanted to add a portion to the Core about character customization, then there should be an entire feature dedicated to that, rather than just one simple thing.


The point of my post was to merely show people how the professionals do it, and obviously it works. For smaller games and projects, organization becomes less and less important, but it's still helpful. This isn't the only way of doing things, and it certainly isn't the best for everyone, but it's the best for me. When I say Professionals, it's obvious that you need clear-cut organization when you have 30-40 people on a design team and a standard needs to be met. Designing games by yourself is only really required when working on a larger project. Otherwise, like with simple Arcade-style games, having a broad feature list is too extensive. You obviously can't efficiently build a Tetris clone with this method, it's just TOO simple.

I would agree with EmpirezTeam here. A lot of the fun of making stuff with DM is that it's pretty darned easy really, and you can just play about with things and see if they are neat or not.

A design document definitely adds some structure, but I'll be damned if you can't achieve the same end-result with a little A5 shopping list of stuff that's essential for the game and must be core. Everything after that core game feature is just nice bits and pieces you can add as you go and as you think of it.

I have digested more than a few 20+ page BYOND design documents in my time, and boy did people waste a lot of time, motivation and effort on them.

There's a million different ways to implement something. That's what kills most of my projects. For every procedure written, I usually come up with several different ways to do the same thing better or worse.

Funny thing is, the only games I've made that have been played are the ones I completely winged. Throwing all planning and design out of the window is the only way to get a finished product, I find.

I need to stop posting in these forums and start getting something done. IainPeregrine's articles on how to get something done haven't really helped me at all, unfortunately.

Text is often an inefficient way to describe things. BYOND makes it pretty easy to implement things. You can spend an hour writing about how you want the arrow keys to make a player move, how the space bar will make the player jump, how the number keys will activate special attacks, and how holding down the number keys will charge the attacks. Or you can instead spend that hour implementing those things. I hardly ever leave "todo" notes in my BYOND projects because it's often easier to do what needs to be done than it is to describe what needs to be done.

Kaiochao wrote:

There's a million different ways to implement something. That's what kills most of my projects. For every procedure written, I usually come up with several different ways to do the same thing better or worse.

I've noticed a lot of BYOND users have this habit. New developers are able to get things done because they're happy to find one way that works, they're not concerned with finding the best way to do something. More experienced programmers get stuck writing things over and over. Since they became aware that there are better and better ways to do things, they feel obligated to find the best way.

This is similar to the problem here. New users don't worry about all of the details that go into a game. More advanced users have realized how complex games are and they feel obligated to plan every detail. Here are some things that might help you avoid this problem:

1. Focus on the interface something provides, not how it's implemented. A good way to do this is to not just implement something, but to implement something that uses it too. For example, if you implement a way to schedule timed events you might spend all day rewriting it. If you implement a way to schedule events and also make a game that uses it, you can't make too many changes to the scheduler before it affects the game. Having something that uses the scheduler binds you to keeping its interface. By sticking to the interface you're also making it possible to make behind-the-scenes improvements later on.

2. Only make changes to infrastructure-type things that are necessary or make them easier to use. If you implement an on-screen inventory and use it in a game, don't waste time adding features unless the game needs them. These kinds of changes are essential. Don't rewrite code for the on-screen inventory unless it makes the inventory easier to use. These kinds of changes aren't essential, but there are only so many ways to make it easier to use.

Why not? That's actually a fair way of pinpointing things that can be improved. When you actually sit down a player or few, have them play through for a while, and then ask, "Okay, what DIDN'T you like?" you immediately get a short list of things that can be improved, "This feature is a bit clunky" or "This mechanic seems too complicated that it's worth" then you begin to make a game for the players, and not yourself. (Which is where the basis of most games stem from)

I was speaking more along efficiency issues. If a player finds something that could look or work better, I'll be more than happy to change it. When it comes to mechanics though, I'm adamant. When a few people start whining, "This fight is too hard! Make it easier!" I would simply laugh and walk away. If the vast majority of players don't like something controversial like game mechanics, I'll see about changing them.

actually none of the changes have been detrimental and if one player experiences an inefficiency than it is highly likely that all of them do. whether something is changed or not is completely up to me, but most of my feedback is legitimate. (I also spend several hours a week doing complete play-throughs of Epic before I release a new version to see if everything is OK and to make sure it is all really fun/polished and the feedback normally agrees with what I'm experiencing.


tenkuu wrote:

I'm not sure how you can come out and say it's not going to feel like a clone of anything, especially when you say you had a vague idea for a concept that mentions other games. It's just like any game you see these days, it's either a sequel or existing game ideas tweaked in some way.

Not at all. Play Epic and tell me if it feels like a direct clone of anything(It really doesn't.) The game has a strange air of familiarity partly because of the intuitive structure of the design which is based around user-friendly game-play and also because of the iteration of ideas I liked in other games, but at the same time you can't say it's a clone of anything at all because it is a unique experience.