Member Discussions

Why is it that these games never get finished? I've worked on any number of games, I'd easily say 100 by now, and not one of them has ever finished. About 90% of the time the coders flake out or say they don’t want to work on it anymore. Or they keep adding new features that aren’t needed and keep ignoring the ones that are needed, until they loose interest.

I’m a concept artist by trade, and always try to stay on top of my designs and make sure I’m ahead of schedule. And I think I do a fine job. But it can be so frustrating trying to work in this field. I love it, but hate it at the same time. In most cases we had the hard part of the game done, the networking, movement, icons, interfaces, they quit when the fun part is just coming up! Is it not fun to them anymore/? What’s the deal? ARG!

Anyway, so I’ll have some credibility I’d like to post some work from my games I’ve done in the past.

First
Playable Version
I did all art and 95% of the design. One other person worked with me on this, he did all coding and did good work. He had to quit though… I also did every room description in the game unless work has been done on it since I left, but I seriously doubt that.

I can’t seem to link images so you’ll have to paste them or check out these two links.
http://www.lorestrome.com/weekly/
http://www.lorestrome.com/trash/oldgamefiles/

http://www.lorestrome.com/trash/oldgamefiles/Deleron.gif

http://www.lorestrome.com/trash/oldgamefiles/Deleron2.gif

http://www.lorestrome.com/trash/oldgamefiles/duskbane2.jpg

http://www.lorestrome.com/trash/oldgamefiles/outmap.jpg

http://www.lorestrome.com/trash/oldgamefiles/sc03.gif

http://www.lorestrome.com/trash/oldgamefiles/screenduskbane.jpg

http://www.lorestrome.com/trash/oldgamefiles/sewer.jpg

The top game being just over a year old, so I’m a far better artist now. Here is some of my pro work.

http://www.lorestrome.com/weekly/albums/userpics/10001/zamurai.jpg

http://www.lorestrome.com/weekly/albums/userpics/10001/stoneclan1.jpg

http://www.lorestrome.com/weekly/albums/userpics/10001/unicorn.jpg

I have tons more but I’m sure you get the idea. Most of those game samples are old and outdated, but it has been a while since I’ve worked on a game for fun.

Of course I’ve got tons of ideas, etc, but who doesn’t right? And I’m excited and interested in hearing people’s ideas, even though I’m a bad lurker I still read posts and such with enthusiasm and at all times during the night when I should be sleeping. =]

Back to the point of this post… I just want to finish one game. The steps seem clear cut and I’m bound to do it one day. And I can do almost anything needed, but not by myself as I couldn’t code my way out of a simple box. =]

Plan out game, story, functions, etc, coders like to skip this imo, or spend so much time on it they never get started… or start over ten thousand times and just spin their wheels

You get networking stuff working, so multiple people can connect and chat

Artist get concepts laid out, make page for archiving news and info, commands, etc

Get npc’s, room stuff, etc done. The basics, let me know if I leave something out

Make a few good rooms, few npcs, keep it small.

Start working on needed commands, inventories, saving, items, etc

Start simple fighting, you know, nothing complex

Now you open it to players and let them find your problem early, nip that stuff in the bud

Now you make the game, skills, spells, more areas, etc, take your time, work outward, and do it right instead of trying to do it quickly

NOW add all the gravy, not six or ten steps ago…

Maybe I’m wrong, but it seems so simple, yet I’ve never been on a team who can do it, but the best part is we’ll always make it to the later steps, where the game making should become fun. It just drives me insane. This might not be the right order, but I think I’m close, and I think people need to start small and work out. I’d rather play a small game that is clean, near perfect, and fun, with few bugs, than a 100,000 room game that is boring. Most people aren’t going to read room descirps and crap anyway on a mud that size, and usually those rooms are copy pasts of other rooms.

My idea of a good game that I’d love to someday make, even though I have little coding skills which pretty much seems to assure me I’ll never get to do it.

Full, finished rooms and areas that have ZERO repeats. Look at the forests and roads here, nothing is repeated and I think it just look’s nicer and helps the player feel like they’ve traveled somewhere.

Few races, but real races. Races that have traits and cultures that players understand and care about. Stuff that isn’t generic. I hate that. In aelfengard the primary race were humans, they were bulky, strong, and many of them semi-gothic in nature. Gnolls were one of the peaceful and cool natural races of the world.

Interaction and RP. Muds seem so boring without RP. And player vs player muds seem like a waste of work almost. My idea has always been to have arena’s set up for player VS player actions. Or player vs player areas where you know you can be attacked if you enter.

I also wouldn’t really want to work on an existing mud, doing catch up work is almost never fun and I do enough of that as an artist =D I’d like to build something up from scratch with a few cool ‘friends’ and have something to show. Aelfengard was just that and I’m sad it is over, but we’ve not touched it in over a year so I’m moving on. I really think it would have been a huge hit as far as small, free, muds go.

Also, I’m not against funding a project once it is established and running, funding meaning paying for some needed costs once the game is a success. Aelfengard didn’t make it that far.

I have a ton other ideas but again, they’re just ideas, any feedback or comments would be nice. Have fun everyone and have a nice new year.

An old link posted right before we started working on Aelfengard. Just thought some of you might find it interesting. Link

The majority of projects fail because the team failed to understand the scope of what they were trying to conquer. Programmers are (and this goes for the rest of us as well) extremely optimistic about their abilities (and by optimisitc, I mean unrealistic). Usually due to inexperience (we don't know how long it will take to do project x unless we've done it before - and even then we're normally overly optimistic over gains from that experience).

Take from the above what you wish. As far as something actually useful for you, I wanted to address your ranking of mud functions.

Your list:
Designers create Design Doc (What is the game?)
Coders implement Network Layer (Multi-person chatroom)
Artist concept work, host webpage for news/media
Builders begin making npcs/rooms
Builders focus'a few good' npcs/rooms
Coders work on commands, inventories, saving, etc
Coders work on preliminary combat system
Open game to alpha players
Continue work in all areas - now focusing on mud 'flavor'

My list:
Designers create Design Spec
Artist concept work
Builders work to specify room/object/player functionality
Coders implement bare-bones networking / account system
Coders implement bare-bones database/file access system
Coders implement bare-bones player/mob/room code
Coders implement bare-bones transport/comm code
Builders begin to develop proof-of-concept zones
Coders work to provide base-functionality for above
Artists derive media for site from proof-of-concept work
Coders clean up network & save/load code
Host webpage for news/media

Now you can start work on inventories and basic object (meaning room, exit, player, monster, item, weapon, etc) interactions. The builders work with the coders telling them what they need for their zones then testing out newly developed systems. The artists work with the builders to create content for the website (coders can't provide anything in this regard for a long time).

The biggest difference in our systems is mine slows down more after a bit of development. This is a natural progression in software development as the further in development one progresses, the larger the system being worked on. Network I/O is an easily modularized system (independent of the rest of the game). Social code, for example, is not - it will rely heavily on player interaction code, room code, database code, network code, etc. A couple things I didn't include that, in a decent-sized team, should be are early implementation of error-handling and logging - these are incredibly helpful later on with debugging (one of the first modules I developed for my game was error-reporting).

Best of luck with your future projects though. To your advantage, working with a group is much easier than by oneself (easier to motivate a group than self-motivate constantly).

- Kelson

I want to start a MUD and I don't intend on it being something that doesn't get finished. I am still looking for a head coder though... I'll have to look at your ideas and stuff at another time, but, it sounds impressive!

Hey, thanks man. I've worked on big projects before, but being an artist and working with builders and such is not fun. I've done it for both recreation and professioanly, and still do. But being an art drone stinks, while if I double as builder, etc, then it is more of a hobby and less of a job. Also your plan sounds like it is for a much larger project as you stated. I just want something small, solid, few hundred players max, you know. I always say you should aim low, but aim really well. That way you're not let down, but pleasantly surprised. As for the coders, you're 100% right. They often just run in and don't pace themselves. Aelfengard was closest thing I've done to my idea of what I'd love to work on. I miss the days when I used to play fun muds, and a new area opened, we were all so excited and used to form parties to explore.

Code is like the foundation of a building...

If you know your building is going to be 2 stories high, you build one type of foundation. If the building is going to be 10 stories, it's a completely different one.

If you start "small" and build the foundation for a 2 story-high building, you will spend $10,000. A 10-story foundation would cost $20,000. However, if you decide to add extra floors after the foundation has been laid, you end up either tearing out the foundation completely, or spending a heck of a lot of money strengthening it ($30,000), way more than if you had built the foundation for a 10-story building in the first place.

Most experienced programmers have learned that management will tell them they want a 2 story building, but come back half way through the project and ask for 10 stories. Thus, they aim for the 10-story foundation, if they're thinking ahead. (Although I would contend that most MMORPGs don't think ahead too far. I'm not sure about contemporary text MUDs.)

Having said that, if the coders you've worked with think they can build a 10-story foundation quickly, then they're delusional. Also, if they don't first build the foundation to the foundation, and instead worry about gazillions of small features, they're doomed.

A good programmer will try to tackle the most difficult/unknown problems first, and leave the easy ones until last. A poor one does the easy/small stuff first, leaves the difficult problems until last, and gives up at the difficult problems.


By the way, some of the UI you've created for Aelfengard (I don't have Java so I haven't tried it) looks like the client UI for the toolkit I've been developing. http://www.mxac.com.au/mif. If you could manage some programming, and waited long enough for my toolkit to be out (it's a 10-story foundation) then it might prove useful.

> A good programmer will try to tackle the most difficult/
> unknown problems first, and leave the easy ones until last.

I disagree. A good programmer will try to tackle the most important problems first, and leave the least important ones until last. The 'unknown' problems obviously can't be tackled until you know about them ;)

In a professional environment I tackle such problems based on priority. When there are multiple problems of the same priority that need to be fixed for the same release, I'll alternate between easy and difficult ones so that I seem to make fairly consistent progress with my workload - in theory it's nice to say "do all the difficult problems first", but in practice it can be quite a career limiting move if you appear to be the slowest developer in the team.

Within a mud environment I do much the same thing, but for a different reason - motivation. The most difficult and time-consuming problems wear me down, and sometimes I need a break. Thus I'll pick a completely different (and easier) problem and work on that for a bit, to rebuild my motivation for the project.

I have checked your client, and man, that thing is good. Great work.

I must say I am VERY impressed where were you when I needed you. I ran SpaceConquest for many years on pure text wishing for someone like you. I can't wait to see how many replies you get.

While it looks nice the "minium requirements" are a tad bit heavy I think. It also doesn't work on any *nix based systems it would appear. I, personally, haven't seen many M*'s running on windows systems. I'm sure I don't get around enough but most M*'s I've seen are coded for *nix and "recompiled" t run under windows or cgywin.

my .25
yes the goverment taxes everything now. :)

All of this info was helpful thanks guys. I'm no coder, and don't try to act like it. But it just seems to me you'd do what needed to be done, then add all the gravy and extra crap later. You know, let us make our mud work before setting up some crap that networks it to ten thousand other muds. Forget what it was called, but anyway. That was just one example, and the coder is god in these worlds, I can only draw and build, so I have to wait for the coder to do his little thing before we can move on with actual game creation.

Well, it really WAS great work wasn't it. I just did the art and building, no code.

Ahh thanks, but i think I'm capable of far more, I'v ejust never found a coder that really WANTS to finish something. As an artist, I do what needs to be done, then add gravy later. Or at least try to do things that way. I can only compare coding to that in my head because it is what I know.

Big difference between 'wanting to finish something' and 'wanting to do module A, B, C and then start on D, E (since they need A,B,C) before working on F and then likely improving A/B/C now to work 95% of the time instead of 75%...and that is just the first cycle of that. When you make a picture, it is a one time production - then you are done. That is not the case with engineering projects where work continues long after the first production (especially with software engineering).

Just wanted to make sure I hit on that - making a standalone project from scratch in your spare time as the sole programmer is far more challenging, I would argue, than being an administrator, builder, or any other position on the mud. Administering a mud comes in a close second - it is years of work only ever making minute progress (the key being the very long timeframe we're speaking of with constant challenges...).

-Kelson

Programmers do what needs to be done, but often the gravy is needed to many sections before it all can be done. For example, I originally developed my socket code as a thesis project. That was my base and I built from there until it needed re-working, then other things needed re-working, then other parts, then other parts, then I advanced the code I was actually developing... (the problem stemmed from the asynchronous nature of the socket server code - Windows is accessing memory I try to de-allocate after my function finished with it, bleh).

Kavir wrote: "I disagree. A good programmer will try to tackle the most important problems first, and leave the least important ones until last. The 'unknown' problems obviously can't be tackled until you know about them ;)"

I'd say, yes and no.

Yes, you tackle the most important stuff first.

But, if there's something you know you don't know how to do, and you don't really know how long it will take, then you try to put that at the beginning of the schedule so you don't get any big surprises later on. Such features are often put in the prototype. (Of course, I don't think most MUDs are prototyped, nor do I expect it.)

For example: In the GDC05 design-track recordings (which you can pay $60(?) and get a CD-ROM audio of), Peter Molyneaux described how they prototyped the morphing and other bits of the game first. While morphing was an important part of Fable, it is also a feature that no one knew exactly how to solve and exactly what the problems would be.

To emphasize your point about important stuff, Peter Molyneaux also bemoans the fact that they left combat until later, which they shouldn't have.

> But, if there's something you know you don't know how to
> do, and you don't really know how long it will take,
> then you try to put that at the beginning of the
> schedule so you don't get any big surprises later on.
> Such features are often put in the prototype. (Of
> course, I don't think most MUDs are prototyped, nor do I
> expect it.)

Well what you're talking about here is really part of the design phase rather than development. And yes, you should certainly make sure your features are feasible before you start trying to code the mud!

I created prototype codebase for testing my combat system, but IMO it's far too much work for most features. It's usually more than sufficient just to put them down on paper, and create them in an open-ended way so that they can be changed later if necessary.

Hey, I wasn't meaning to offend. I said I know very little about programing. But you try painting the same events in the same world a thousand times and see how well it all fit togethor. You've got to plan, and it isn't a one time deal. I'm not saying the programers don't know what they're doing, I was asking why they quit. I don't and work just as hard, and I believe that. If I did, it would be a better reaosn than "I don't feel like it' or just vanishing.

I think maybe I wasn't clear, I simply meant why don't people build the base stuff first, and get something functional, then add on to it? Why do they cut corners to get to 'neat' things and then end up getting over whelmed when they try to back peddle and pick up what they were doing?

You have work horses and show horses. I'd say on most muds one person does 90% of the work while the rest slacks off, is busy debating futilities, power struggles, being important, and various other activities that have little to do with the advancement of the MUD itself. People who claim it's different are either in denial or belong to the group of show horses I just described.

You basicly run into the same problems as communism when there's no incentive, mainly because social codes prevent you from being a tiran who gets angry when people pick their noses, you can only do that when you pay them money.

Finding one person who gets the job done for free is close to impossible, let alone a team of 4 to 8 persons required to get something done before the inspiration runs dry.

Hyptosis wrote: "I think maybe I wasn't clear, I simply meant why don't people build the base stuff first, and get something functional, then add on to it? Why do they cut corners to get to 'neat' things and then end up getting over whelmed when they try to back peddle and pick up what they were doing? "

Why do people lick the creamy filling out of oreo cookies first before they eat the biscuit bit?

This is a bit of a pointless comment, but: Avoid coders that cut corners in order to get to the neat stuff. As you've already noticed, they won't get anywhere. A good coder won't do that, but they might be hard to find since they're either employed, already part of a group, and/or working on their own project.

And as scandum pointed out, you're very lucky if you find a group of people that all pull their own weight.

Indeed, and it is damned frustrating.

Well, no secret there, been trying to do it for about 5 years now. I'm an illustrator by trade and I'm willing to put out for the project. Meh, guess I just have a better work ethic. Thanks. =]

Not all programmers quit.

But a lot of people call themselves "programmers" (or much more often, "coders"), when they're neither motivated, nor particularly skilled. Very often, these people will work until they have to do something they don't know, or until they get bored. At this point, they quit.



Also, I know I've had a lot of projects peter off because I don't know if anyone else will ever look at it - programming is an activity that often does not make how much progress you've actually made visible. In art, you can probably guess how much you've got left to go on an image... with programming it's far, far harder to figure that out.

> Ahh thanks, but i think I'm capable of far more, I've
> just never found a coder that really WANTS to finish
> something.

I doubt any coder deliberately sets out to create a project that they never plan to finish. But creating a game takes a lot of time and effort, and unless the coder is being paid they're probably only creating the game for fun, as a hobby. Once that hobby ceases to be fun, their motivation will start to lag.

The first phase of mud development will generally be frantic, as the developers start turning their design into code. After a few weeks, however, the excitment will wear off as they realise the sheer scope of what they're trying to do.

As the weeks become months, with the majority of your free time being spent implementing complex and frequently boring parts of the codebase with no real feedback or sense of achievement, it can become increasingly difficult to remain motivated.

The more you code, the more things you realise you've overlooked, so that the amount of required work actually seems to increase the more you do. You think to yourself "I've put in months of work here, and it's not even playable yet - in fact there's even more to do than we thought there was at the start!" and wonder if you'll ever be able to create something that's even usable.

Of course it's easy to say "they're lazy" when you're the one sitting back while they pour hundreds of hours into the mud (rather reminds me of a manager I once had who couldn't understand why programming took so long - "it's just typing", he would say). But if you're really as motivated as you claim, why not teach yourself to code and help them out?

k

"Of course it's easy to say "they're lazy" when you're the one sitting back"

I never sat back, and always did more than my share. Never ment to suggest anyone was lazy. I just like people who do what they say and was wondering if there were any out there. Thedia, the last guy I worked with, was a skilled coder and could do stuff in hours I've seen others work months on. I have tremendous respect for him and his skills, but yet, he still couldn't finish the project. And if anyone understands inspiration, I'd think it'd be an illustrator. It is VERY hard to paint a picture you think is both stupid, boring, and uninteresting, but your client requests it and you need the cash. I'll find someone to work with someday, thanks.