ID:326174
 
This post outlines the process I used to make Epic. I believe it to be highly effective based on the results it produced.


SO U WANT TO MAKE UR GAEM?

You sit down, make a blog post about how awesome it's gonna be, and hire someone to rip make you a player base. And bam, now you're a game developer.

er... but you haven't done anything to get to the "game" part.


HERE WE GOOOO

1. WANT TO MAKE GAME.

In order to make your "epic" game, you'll need a powerful instinct inside of you to always be saying, "Dude. Make it." If you don't have that drive to make something that others can enjoy as much as you do, then this is not for you.

2. LEARN HOW TO DO THIS.

You need experience. A good 90% of the people you'll "hire" will be useless vegetables if you have no experience in finding a good dev team.

You'll have to make the whole core engine solo. There's no other choice, in my opinion, if you want YOUR game to not only become playable but be YOUR game.

3. PLAY GAEMS.

Play random games that you like, or that revolve around the theme you want to pursue. If I wanted to make a roguelike zombie survivor, I'd play Rogue Survivor, Project Zomboid, and Desktop Dungeons. You'll need a role model regardless of how new you are to game design.

Oh, and don't pick shitty games. If you want to make a "dbz gaem", then that doesn't mean you should pursue the game-play of mainstream commercial Dragonball Z related games. You should try playing things like Street Fighter if you're making a fighter. (NOTE: "DRAGONBALL" is NOT a game-play theme. "Multiplayer action RPG with fighter elements" is a game-play theme. "Street Fighter mixed with WoW" is a game-play theme. But not "dragonball"- that's atmospheric.)

4. WAIT.

You have the drive to make a game, but unless the game-play is crystal-clear in your imagination it is never going to become true. You shouldn't make a game until you know EXACTLY what you want. The game should, "make itself" per se. This doesn't mean you shouldn't try- You'll know you have your game when it's there, but it might take a couple prototypes to get going.

5. PROTOTYPES!!!

This is where a lot of you people seem to stop comprehending me. You HAVE to prototype your game. This involves taking the game-play, programming it into life, and then playing it to see if it's fun. The first thing you do should NEVER be sitting around waiting for some retard to rip naruto icons for you. everrr.

When I made Epic, I sat on my couch and went through at least 5 different drastic game-changes until I had what I wanted. The first thing I did was draw some turfs(ie. grass was filling a square with green.), mobs(circles.), and random objects that would make good dungeon puzzles(chests, etc). Now that I had all the icons I needed to make this game playable, I tried experimenting with different control schemes. First I tried shmup controls- WASD and the mouse to aim your character. Didn't go so well with me. Then, I tried using only WASD's directions to control the character and had the mouse control actions...

*shines magical halo of light on self*

6. MAKE DAT CORE

Now that you have a solid idea of how the game will play, it is time for you to devote hours and hours and hours and hours and hours and hours and hours of your time to developing the game's core. Make everything. Epic had multiplayer dungeons, combat involving bows swords and magic, ability hotslots, quests, inventory screen, hp and mana bars, and er.... Just about everything I wanted, before I revealed it to the public. This was version 0.1, with three dungeons and 1 quest.

Oh, and personally up until the core is finished and I have a playable demo I don't tell ANYONE about my project. It gives me a feeling of accomplishment, when in reality I accomplished nothing until the game's playable.

BIG IMPORTANT NOTE TO ALL YOU SINGLE PROGRAMMERS OUT THERE: Make sure you program your game to be idiot proof. Make the things like abilities, quests, items, and dungeons(examples from Epic that may not be specific to your game) be so easy to add that a monkey with no programming experience can do it.

DEVELOP!!!!!

Now that your game is revealed to the public, I recommend you grab someone to help you expand your game! If you made it idiot proof like I mentioned up there ^ then it shouldn't matter WHO does it. Pick a loyal friend who enjoys playing all of your games as much as you do, and I'm 100% sure that you'll be able to get things going.

Your loyal buddy's job would be to expand the game, while your job is to expand the engine and make the game even larger than it was first intended. Each update in Epic involves Blazekid adding 4 dungeons with gear and abilities to match and me adding whatever comes to my head to the entire game, or polishing the engine/whatever. It is fun for me to do because I get to be lazy and make substantial changes with little effort and it is fun for Blazekid because he loves playing my games and now he gets to expand on them.

ANOTHER NOTE! I RECOMMEND YOU ALLOW PEOPLE TO PLAY YOUR GAME AS YOU PROGRESS. IT WILL HELP YOU GENERATE A LOT OF FEEDBACK AND DEVELOP A STRONG FOLLOWING, ESPECIALLY IF YOUR GAME IS GOOD. AND IF IT ISN'T, FEEDBACK WILL MAKE IT GOOD.

and note 2: Be ready to change things on the fly. Like I said, feedback is good AMAZING. I'll have one player sit down and play Epic for a while, and any comment that they make about inefficiencies in the game-play forces me to instantly go in and change things to accommodate to their needs. Your players are the people who are most important, and if they don't like something, changing it will almost always make your game better. (and better games get more players = more feedback = <3)

Finish it.

Before you'll know it, you'll have a huge completed game. Epic releases a new demo around once a week which increments the version by 0.1 each time. Each version has 4 new dungeons, and that's how we base how far we are in terms of progress. Between versions, however, I make drastic changes and awesome additions to the game-play. It's extremely fun to add to a fun game like this, especially since the engine is already finished. It's not like anything I've ever done before(well actually this is the method that developed Pokemon 3 years ago back when I was a crappy programmer xD) and motivation loss is almost always out of the question.

Blazekid's even worried about 1.0, because he's afraid we won't work on it any more. It's not work- it's a hobby. Epic is not demanding to work on at all. The programming is set up to be easy for me, and I can make quick changes or additions on the fly. I get so much done so fast, and I spend most of my day sitting around playing minecraft and Pyrce High(which is actually a great Mitadake High clone, lmao).




Read this if you want to have fun making a long-term project. There's so many other reasons why this development approach is working for me, but one reason stands above all others:

I have a game. Epic is a game. That's where most of you go wrong when approaching game development- you forget you're making games.</3>
You forgot one step:

Make Your Game Playable! ( I still have not been able to play Epic )

Every time something goes wrong. The first time, it just said "failed" on the BYOND logo splash screen. Then, I updated BYOND and it stayed on "opening tiny rpg.dme" or something like that for like 10 minutes and FINALLY opened up, but then the map would never show up. I was looking at a window with a huge black space and some buttons over to the right. Then I tried again not too long ago and it's saying "failed" again.

I hate you.
In response to EmpirezTeam (#1)
EmpirezTeam wrote:
You forgot one step:

Make Your Game Playable! ( I still have not been able to play Epic )

Every time something goes wrong. The first time, it just said "failed" on the BYOND logo splash screen. Then, I updated BYOND and it stayed on "opening tiny rpg.dme" or something like that for like 10 minutes and FINALLY opened up, but then the map would never show up. I was looking at a window with a huge black space and some buttons over to the right. Then I tried again not too long ago and it's saying "failed" again.

I hate you.

Lolz , this made my day (:
I think these types of posts should be left for people like SilkWizard or Falacy.
In response to Cubanbling (#3)
I don't think you understand just how good Yut is...
In response to EmpirezTeam (#1)
EmpirezTeam wrote:
You forgot one step:

Make Your Game Playable! ( I still have not been able to play Epic )

Every time something goes wrong. The first time, it just said "failed" on the BYOND logo splash screen. Then, I updated BYOND and it stayed on "opening tiny rpg.dme" or something like that for like 10 minutes and FINALLY opened up, but then the map would never show up. I was looking at a window with a huge black space and some buttons over to the right. Then I tried again not too long ago and it's saying "failed" again.

I hate you.

haha, i've had discussions with expixel and kaiochao about how we can work to fix the loading time. the problem is that we have 25 z levels(well, over 25 now) that are packed with mobs n' stuff. It would be great if we could somehow dynamically load the maps but that might cause speed problems somewhere else, and dynamically loading individual map files would require that the map files are downloaded by the clients

in short, its a pain. simple solution is to just get one dedicated live server so that people can hop on whenever.

EDIT: never mind i just fixed epic's start-up like two seconds ago x.x
I'll try again. It better work this time or there will be some consequences.
In response to EmpirezTeam (#6)
EmpirezTeam wrote:
I'll try again. It better work this time or there will be some consequences.

Not gonna work till 0.5.

The problem was with the auto-joining turfs; I fixed them so that they only set their icon states once a player moves within 14 tiles of them.
In response to Cubanbling (#3)
Cubanbling wrote:
I think these types of posts should be left for people like SilkWizard or Falacy.

I agree. Their games are crappy.
In response to Avainer1 (#8)
Avainer1 wrote:
Cubanbling wrote:
I think these types of posts should be left for people like SilkWizard or Falacy.

I agree. Their games are crappy.


I agree.
Falacy's only decent games were Celestial Chaos. Figures he wouldn't finish the only game of his that was actually worth playing. http://www.angelfire.com/hero/straygames/CCN/AlphaShots.html

Silk's decent games were Proelium and NEStalgia. Proelium 2 was disappointing - there was just something about it that didn't feel as fun as the first did. Probably because a large portion of the Proelium player base left BYOND. By the time he came out with the sequel, only a handful of us were still lingering around BYOND, played it for like the first two weeks, and then it died back off. I also played that Acheron Awakening game and I'll just say this: giving up on that and switching to NEStalgia was a smart move. =/
As far as having an actual successful game, continuously producing games, and maintain a pretty nice player base(Not to mention financially successful). Those two, are the only ones that get to open their mouths in MY OPINION. Again those two are the only two 'I' would listen to as far as giving advice on creating games that are successful. Sorry if this sounds a bit harsh. Just MY opinion.
The posts that say "here's what I did, it worked one time, so it must be the right way to do things" are often terrible, but this advice is pretty good.

For section 3 ("PLAY GAEMS"), you should stress this point more:

Street Fighter mixed with WoW" is a game-play theme. But not "dragonball"- that's atmospheric.

You don't need to base your game idea on existing games but it is important to be able to distinguish between gameplay ideas and themes. It seems obvious but a lot of people pick themes that have some gameplay implications (ex: zombie games, anime games) but they tend to focus on the theme and not the gameplay. Even if people base their game ideas on existing games that doesn't guarantee that they'll focus on gameplay. Saying you'll make a game like Resident Evil may mean (to the developer) more about the theme than the gameplay - it could just mean that they're going to make a game with zombies and guns.

You have the drive to make a game, but unless the game-play is crystal-clear in your imagination it is never going to become true. You shouldn't make a game until you know EXACTLY what you want. The game should, "make itself" per se. This doesn't mean you shouldn't try- You'll know you have your game when it's there, but it might take a couple prototypes to get going.

I'm not sure I'd say "crystal-clear" there. The problem here is that most BYOND users focus on the most irrelevant details (title screens, base icons, etc.) that they think they have 40% of their game planned out when they actually have 0-1% planned out. You don't need to have 100% of the details figured out, but BYOND game developers (on average) do need to plan things out a lot better before starting.

Also, your experience is from a game called "Epic" which sounds like an epic game, but a point that many BYOND game developers miss is that games don't have to be epic. Your game sounds complex so it's unavoidable that your advice ended up being about how to make a complex game but the advice actually works just fine for making a simple game too. Prototyping is very important. If BYOND game developers started on each project by implementing the part of the game that'll be the most fun, most people would realize that they have very few actual gameplay ideas.
I find these blog posts rather useless. Not everyone is capable of producing the same results as you, even if game developing is a poignant interest to them.

In response to Urias (#13)
Urias wrote:
I find these blog posts rather useless. Not everyone is capable of producing the same results as you, even if game developing is a poignant interest to them.

People work differently so it's not likely that anyone else will see the exact same results if they follow the same process. That doesn't mean these kinds of posts are useless.

A lot of DM users are so clueless they don't even realize that they're clueless. People have played games so they assume they know what goes into making one. It's hard to realize all of the work that goes into a game just by playing it. You can't tell what order things were developed in and how many things were prototyped. You can't see the discussions that took place to figure out how gameplay will work.

Most BYOND users know what a game is supposed to have but they have no idea what goes into making it. Their approach is to implement all the things they know a game has. Many people even do this in order (title screen first, then icons, then login/character creation, etc.). This is a silly approach and it's why many BYOND users won't see the same results even though they consider themselves to be very interested in game development.

It's kind of like filming a movie without ever writing a script or creating storyboards. The script and storyboards aren't ever shown in the movie but they're certainly important. If you tried to make a movie after having seen a few yourself, you'd be in the same position as most BYOND users who are trying to make games.
That's why the word is personal is in the title. I posted this hoping someone would find that it works for them, too. It took me forever to get into a development process that worked, and this is it.

And i'd agree with just about everything f_a's said so far. I didn't read over this post more than once so it might sound a bit biased and I may have not brought my point across very accurately, but what he said kinda helps.
If I may add something to this thread, I would like to explain exactly what the "Core" is and why this concept of the Core works for every single successful game.

The true Core of a game is what the focal point is. Every game needs to have a Core. Without one, it becomes an ambiguous pile of features and actions. Making a Core is simple. Simply take a few sentences (I do it in one sentence to ensure that my core is consistent.) to outline the Core and refine from there. Every single feature in your game needs to strengthen this Core. If a feature doesn't in one way or another accomplish this, then it should be either rewritten or removed. I typically ask myself these three questions:
1) What is your game?
2) What is the player's goal?
3) What does the player use to achieve this goal?

Remember that every game has a challenge. Without a challenge there is nothing to vie for and therefor no reason to play. Playing a game, no matter what genre or type, will have a challenge or an obstacle, no matter how simple or easy it may seem. Keep that in mind while writing your Core.

The core of a Fantasy RPG might be read as: "My game is a Fantasy RPG where the player progresses and advances their character by defeating monsters and overcoming challenges through means of both combat and skill use, with and without the aid of other players."

The core is an EXTREMELY broad statement about your game. As you can see, this Core statement envelopes pretty much every single Fantasy MMORPG on the market right now. Your Core is not meant to be specific to your game, it's meant to outline what your game is to accomplish.

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. The Core outlines the genre, the Features outline the gameplay itself. Remember to also keep these Features very broad. Any Features that seem related in any significant way should be combined. When you combine and cut out redundancy, you'll quickly realize why the seemingly low number of only 15 Features is actually quite difficult to get too. As stated before, each and every feature needs to reinforce your Core. If it does not do this, it should be rewritten until it does, or scraped completely.

The Feature list for my game might look like this:
1) Combat
2) Items and Equipment
3) Quests
4) Dungeons
5) Character Progression
6) Non-Combat Skills and Abilities

Here we have an example of a Not-too-extensive list of Features. As you can see, each feature directly relates to the Core and fortifies its statement. Does this seem weird how both the Core and Feature List both seem so eerily similar to almost every other MORPG? It shouldn't, because this is the exact method that they used to develop their games.

Each Feature needs to have a set of Subfeatures to more refine the Feature itself. Just like the Features need to compliment the Core, the Subfeatures need to compliment the Feature they fall under. For example, the "Combat" Feature that I listed can be broken down into "Player versus Environment (PvE)" and "Player versus Player (PvP)." Although both are Combat oriented, they are handled differently than one another.

From here, each Subfeature needs to be refined with more Subfeatures, and so on and so forth until you're down to individual mechanics and the very most specific level. This process of branching not only keeps things coherent and clear, but also easily maintains the Core of the game. Knowing how functions within your game relate to each other can help you organize how to handle them.

Changing a Subfeature in "Items and Equipment" shouldn't require anything to be changed in "Combat" even though they're directly related. The use of intermediary functions can keep this line clearly drawn. Changes made to mechanics in one Feature should be understood and carried out normally in all others that refer to it. This makes programming for games set up in this fashion a breeze. Adding new Subfeatures becomes much clearer and easier to manage. Adding Subfeatures is another trivial matter than requires very little effort on the part of the programmer to incorporate, however, the broader the Subfeature you're adding, the more work is required. Adding an entirely new Feature into an already existing game would require the most amount of work to fit in. A daunting task, but one buffered greatly with the preexisting model.

And for the programmers out there reading this, I would make a folder for each and every Feature. Under those folders would be the files for it, and if the Subfeatures are large enough, more sub folders. This is just one of my organizational habits which, in my opinion, is a good one.



Overall, the use of the Core Branch model of game development is a tried and true method of success. 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. When you focus your effort into something specific, you can actually make something good. And yes, even a Naruto Fangame that follows this model can be good.

Keep in mind that your Core and Features are subject to change at anytime. You are the developer and are free to change those however you see fit, however when you do, be sure to check all of your Subfeatures to make sure that they all follow the Main Feature, and if they don't, change or remove them. And also be sure to make sure that the changed Feature still compliments to Core. Hopefully you get the idea and at least one person saw a little useful information in this rambling post.
Thank you for the reply, that was very informative and helpful. I suppose I was lacking in that area when discussing game-play. I didn't go very far into game design however and instead tried focusing more on rapid development.

It's very difficult to write a post like this, because there are so many little things about game design that would cause problems for developers which most people have to learn through experience haha
In response to Yut Put (#17)
Well, there's no cookie cutter way of developing a game. It's all trial and error (Unless Trial and Error is now considered a cookie cutter method). You can gather information about how other people do it, but in the end, it's on you about how it gets done.
Trial and error seems to be the theme of my post, lol
Page: 1 2