I am curious how people go about making games, particularly RPGs in Byond. It seems that when I work on any project I tend to build the systems before I do the graphics and map. This seems contrary to how most of this community programs. I see many games that are nothing but a shell of pretty graphics. What do you think is the most efficient way to produce a RPG?
This can be applied to any game, but RPGs in particular have a tendency to focus heavily on graphics, at least in Byond.
ID:152479
 Sep 3 2006, 7:06 pm
|
|
Start out with ideas for race names, unique systems, and what you think people will like. Then, program as you would play, example: ServerStuff/CharacterCreation/ Mining\Fishing\Fighting\Woodworking
That's how I would do it, icons come last. | |
I usually dream about somehting I wanna make. :D
Other than that, I often doodle a lot of concepts out and such. like Areas, Menus, Storylines, turfs. etc. I waste a lot of notebooks. :P Then proceed to start making core things , like D4RK, and work my way up to it. Biggest problems for me is just character icons and the barrier of laziness to make more turfs. :P | |
I personally prefer:
1) Decide what type it's going to be, and what the main goal is. 2) Do all the graphical stuff. 3) Add all the basic systems, such as character creating and the battle system. 4) Start on the story(and try to come further than this step, for once!) 5) Test, polish, and poof! New game! Though, I hardly ever get any farther than step 4. I have backed up something around 280 MB on a CD, filled with unfinished projects... Not sure if there is anything wrong with this method, but meh. I have a few active projects that are getting close to step 3, but I already started on the beginning of the story -on paper-, I'll see if that will cures me from my motivation-losses. O-matic | |
I don't know, I seem to feel that creating the systems first helps to finish a game. Or if nothing else you will have some systems you can use for something else. If you make the map/icons first then all your left with is a map, that you probably can't use again.
| |
I usually do my graphics, then ask other people to code, notice how I have no games published, so no, this doesnt work. :(
| |
Drumersl wrote:
I don't know, I seem to feel that creating the systems first helps to finish a game. Or if nothing else you will have some systems you can use for something else. If you make the map/icons first then all your left with is a map, that you probably can't use again. There's a pitfall to making systems as well, tho. It's possible to become obsessed about a particular system or even an aspect of a system so much that you spend all your time polishing and rewriting it and neglecting the game as a whole. I sometimes forget that my mission isn't the system, it's the game, and if I don't set some deadlines and very simple, clear goals for those systems then I'll have built the shiniest damn four wheels in the world but still be missing the car. | |
TheMonkeyDidIt wrote:
It's possible to become obsessed about a particular system or even an aspect of a system so much that you spend all your time polishing and rewriting it and neglecting the game as a whole. I sometimes forget that my mission isn't the system, it's the game, and if I don't set some deadlines and very simple, clear goals for those systems then I'll have built the shiniest damn four wheels in the world but still be missing the car. This is quite possibly the biggest obstacle I run into with Haven development. I'm (according to personal opinion) an excellent designer and I'm (according to somewhat popular opinion =P) an excellent library designer, but I tend to spend more time writing internal libraries for my games than I do writing the games themselves! For instance, Haven has what might be the very best spell effects system on BYOND (modesty is for saps =)). It runs like a well-oiled machine. But... there is no spell system yet. No spell system means no way of using the spell effects system except for special hard-coded behaviour. ;-) | |
I honestly have no idea. But maybe you can learn from what doesn't work!
I've always thought it would be better to build all the systems first, so that they all run smoothly and look decent, with all the necessary features built-in already. Then I could crank out all the content without having to worry about recreating any of it because some systems changed and they became incompatable with the new stuff. Doesn't work. Well, I suppose it COULD work, but only if you had someone else building the actual content, while you were building the systems. Actually I think thats the way that works best overall, if my experience with Theodis means anything. RacingGame comes to mind - Theodis built the car mechanics, the track editor/loader and the car editor, along with any other weird systems that went into that game. After he built all that, I built most/all of the tracks and cars. So he built the game, I built the content. Well, it would have been a good game if BYOND handled those games better. I'm not sure exactly why, but when you're building either the systems OR the content, you seem to do a better job of it. Maybe its because if you try to do both, you end up feature-creeping your own stuff because you want to create new content functions all the time - while someone who only builds content has to work with what systems the system designer provides. So it would probably work best to have some person build all the systems in an RPG, while another person writes dialog, creates maps, items, creatures, and so on. Because in my experience, I can create good content if I'm only working on content, and I can create good systems if I'm only working on systems. But if I try to do both, I end up revamping the systems over and over and never getting around to building any decent content (See Kades). Anyway, that's my take on how to create an RPG. Which order you build the systems in isn't all that important. Just don't get stuck on one system. Oh, and here's another thing to note: We've all played games that had one aspect which was relatively simplified, and we thought, "Hey, this'd be better if it had a few more variables". Well, you're wrong. Suppose you've got your armor system. In a game you played, there were armor points, and the more armor you wore, the more armor points you got. Too simple, right? Needs more variables. So now you've got your chance to make it the way you want, and you add different damage types, and different armor locations. Now you can get hit on the arm with slashing damage, and the armor points are determined by the slashing protection of whatever is equpped on your arm, if anything. So you end up having 12 different armor locations and 12 different damage types. Now you've just over-complicated the heck out of everything, because all those variables are going to come back and bite you. You're going to have to determine for every piece of equipment how much of each damage type it can absorb, which locations (because one isn't enough!) the armor is equipped at. That full plate armor must cover the torso, shoulders, arms, waist and legs, right? What about monsters that have built-in armor? Dragons with scales! They've got built in armor, so you've got to determine how much damage of each type they can handle in each location. Its nothing but hassle, I tell you! Just stick with the freakin' armor points. Is sooooo much simpler. | |
Yeah, simplicity usually makes a game more enjoyable. To many attributes are hard enough for the player to keep track of, let alone the programmer. However, it is sometimes hard to keep a game simple while at the same time somewhat original. But it can be done.
| |
Drumersl wrote:
I don't know, I seem to feel that creating the systems first helps to finish a game. Or if nothing else you will have some systems you can use for something else. If you make the map/icons first then all your left with is a map, that you probably can't use again. Yeah, I think having the base of the game is motivating a bit. But still nothing for me, I'm the lazy kind of developer(who hardly ever finishes a project), but I enjoy creating icons. So I do that first, but multiple times it got proved to end up in the "discontinued" list. Being the obstinate me that I am, I never program and then draw. This time, I tried writing the first part of the story on paper, so that I now what to base it on... I'm nearly done with all the graphical stuff, so we'll see where this will bring me, or rather, whether this will bring this into the "discontinued" list... >_> O-matic | |
Well, I'd say that logically, the engine should be the first priority... Graphics don't make a game, so the game itself should be more important...
However, I personally have a sort of need to build the world of my game before I can do any of the major programming work... I like to see everything in action, in front of me, and not have to visualize it all in the abstract while programming some systems... This is especially necessary since I test things bit-by-bit... I program a small chunk, and then compile and run to see if it works... Rinse and repeat for every little bit... If I didn't have the graphics, maps, etc. all done beforehand, I couldn't run the world after every added line of code... Well, I could, but I couldn't see what I was doing...lol And since I try to avoid doing the same work twice, I don't ever use placeholder graphics or maps... I make the intended final version first thing... So, I most often tend to work on graphics, mapping, etc. as some of the very first steps, and then make all of these things come alive by programming systems afterwards... | |
Once I get around to one that I like, I send it around to my peers, see if there are any improvements to be made to the idea.
After that, I start work on icons (Or I get someone else to start work on icons). Most, if not all, icons that come up in the original idea of the game session are produced before I start any programming work.
Then, I start programming the backbone systems like Stats, inventory, equipment, skills, combat, etc. This is the longest and the largest stage of my approach to developing the game. I do a lot of private testing in this stage. If there are any graphics that I require that aren't done, I either do them or get someone else to do them for me.
When all of that is done, I stick some in content (or rather, a lot of content) and start public testing.
Note that this is pretty much how I go about developing any game, and that I never use placeholder graphics. Whenever I do graphics (Or someone else does graphics) for my games, they're usually the final ones... unless someone else donates prettier ones or I do prettier ones.