Design Methodology

 
Post new topic   Reply to topic    mudlab.org Forum Index -> Design
View previous topic :: View next topic  

Design Methodology?
System Need/Encouragement
 16%  [ 1 ]
Looks/Sounds Cool
 33%  [ 2 ]
Haven't considered how I design in this regard.
 0%  [ 0 ]
Other (described below)
 50%  [ 3 ]
Total Votes : 6

Author Message
Zephen_Descartes



Joined: 21 Sep 2007
Posts: 20

PostPosted: Sat Sep 22, 2007 12:11 am    Post subject: Design Methodology Reply with quote

What's your design methodology? How do you start designing a feature? Do you start with a cool sounding idea, such as "Let Players make their own spells", or do you start with more details such as: "Create a cash sink that is also a medium for player expression"?

Myself personally, I usually work on the latter, focusing on the needs of the game as well as the most fun gameplay ideas, and then retrofitting a theme onto it from there. I created a fishing/shrimping and food system by thinking of a way to allow newbies to effectively enter the player market by their own merits as well as creating an alternative resource for regeneration management.

I'm going to reoptimize the food system soon because I want to open up the ability to customize and micromanage the regeneration element of your character through a consumable medium since our characters are all heavily skill based and very mix and match. I didn't want to use potions or the like for this as they're too easily gained and tend to be more top heavy in terms of the ability to make, meanwhile food is usually fished by newbies the most as it's roughly similar results regardless of your level of gameplay. There are bonuses for time invested in fishing for instance though.


Probably a bit of a detailed example, but I wanted to clear up what I'm asking as I see that it could be a bit of a complicated concept for some. In short:

Do you design things based upon what looks or sounds cool?

Or do you design things based upon a particular need or gameplay encouragement?

Or maybe some mix that I've yet to think of or cover in this post.

Discuss.
Back to top
View user's profile Send private message
Author Message
Kelson



Joined: 18 May 2005
Posts: 71
Location: SC

PostPosted: Sat Sep 22, 2007 2:24 am    Post subject: Reply with quote

Your poll is significantly lacking...

That said; it depends on what I'm working on to be completely honest. One design hurdle I've still not completely cleared is that of player designed, real-time spell casting. I have figured out bits and pieces that I find essential, but the final implementation / foundation is still a bit unknown.

How does one run a simulation atop a stage show?

Most often, design comes from both perspectives; there is a need - usually related to increasing entertainment. Some designs come about from a desire to test a particular approach as well (for example, event passage and execution between objects) instead of any distinct requirement.


Last edited by Kelson on Sat Sep 22, 2007 1:32 pm; edited 1 time in total
Back to top
View user's profile Send private message Send e-mail AIM Address
Author Message
shasarak



Joined: 29 Jun 2005
Posts: 134
Location: Emily's Shop

PostPosted: Sat Sep 22, 2007 11:36 am    Post subject: Re: Design Methodology Reply with quote

Zephen_Descartes wrote:
Do you design things based upon what looks or sounds cool?

Or do you design things based upon a particular need or gameplay encouragement?

Surely most people do both? You add entirely new features because "they're cool" and you also tweak what's already there to cover gaps and improve game balance "because it's needed".
Back to top
View user's profile Send private message
Author Message
Zephen_Descartes



Joined: 21 Sep 2007
Posts: 20

PostPosted: Sat Sep 22, 2007 6:20 pm    Post subject: Re: Design Methodology Reply with quote

shasarak wrote:
Surely most people do both? You add entirely new features because "they're cool" and you also tweak what's already there to cover gaps and improve game balance "because it's needed".



I suppose I should clarify as to how many start that way? The reason I posed the question is I've worked with a number of implementors on MUD projects, and a vast majority of them seem to come up with something "cool sounding", without thinking of gameplay implications, balance, or even whether they need it. They just focus on the fluff, without thinking of the structure of the gameplay effects to the game.

My own designing is generally done by focusing on the type of gameplay that is needed, any social encouragements, etc, and then retrofitting a "skin" onto it.

Horse Breeding, Monster Arenas, Gladiator Pits are all different skins for a system of NPC maintenance, nurture and genetic optimization which utilize a limited resource of specialty foods and medicines found rarely in other parts of the world and sold through player trading networks.

The skin can be added and polished as the need arises, but I generally see Horse/Monster/Gladiator as fluff until you figure out the mechanisms and gameplay you want to run with your system. I think the methodology with Multiplayer game design requires a bit more thought on the mechanisms within a feature and how they relate to gameplay.
Back to top
View user's profile Send private message
Author Message
shasarak



Joined: 29 Jun 2005
Posts: 134
Location: Emily's Shop

PostPosted: Sat Sep 22, 2007 6:45 pm    Post subject: Re: Design Methodology Reply with quote

Zephen_Descartes wrote:
The reason I posed the question is I've worked with a number of implementors on MUD projects, and a vast majority of them seem to come up with something "cool sounding", without thinking of gameplay implications, balance, or even whether they need it. They just focus on the fluff, without thinking of the structure of the gameplay effects to the game.

Such people are stupid and evil and should be subject to compulsory euthenasia, or, at the very least, a court order banning them from coding anything for the rest of their natural lives; but that goes without saying, surely? Twisted Evil

Zephen_Descartes wrote:
My own designing is generally done by focusing on the type of gameplay that is needed, any social encouragements, etc, and then retrofitting a "skin" onto it.

That's often a good strategy, but I think it is sometimes necessary to take a risk, otherwise you'll never encounter any emergent gameplay - that is, things that are, serendipitously, a positive influence on the game even though you hadn't realised in advance that they were going to be.

To take a random example, suppose you start with town guards that just stand around outside the local bank not doing anything unless someone tries to break in, or unless they spot a known outlaw (in which case they will attack). Any players wishing to rob the bank therefore have to kill the guards to do it.

Now suppose you introduce a system whereby the guards placed throughout the town can shout to other guards for help if they are in a fight, and guards in neighbouring rooms will come running to their aid. A clever player might be able to make robbing the bank easier by arranging for a known outlaw to show his face close to the bank, thus causing a guard there to shout for assistance, which causes the guards outside the bank to leave their posts and run off to see what the trouble is; that allows the player to rob the bank with impunity.

Now, it's conceivable that the coder who introduced the calling for help feature might not anticipate that players would use it in that way; he might simply think "wouldn't it be cool if a guard could shout for help and his buddies in the next room would come running?" So you've got a whole new combat tactic introduced as an unexpected side-effect of this mechanism. But in this instance, I don't think that's a problem. Smile On the contrary: I think it's highly desirable to give players a way to achieve their goals that does not always involve committing murder.

It is often precisely the consequences that you don't anticipate that are actually the most interesting ones in terms of improving the gameplay. The fact that something is "cool" is not a good enough reason to do it without thinking it through; but, equally well, its being cool is certainly not a reason not to do it either.
Back to top
View user's profile Send private message
Author Message
Zephen_Descartes



Joined: 21 Sep 2007
Posts: 20

PostPosted: Sun Sep 23, 2007 5:15 am    Post subject: Re: Design Methodology Reply with quote

Although that was a good post, I'm not necessarily advocating knowing every single effect of your code before planning it. I'm more advocating planning your code for inducement of effects.

Also, I believe a seasoned developer would probably consider exactly how such a system as that would be used and implement it exactly for that reason (among others). Essentially you're just giving players tools to create their own gameplay with such a system which is pretty ideal in a multiplayer game where endgame is not so well defined.

Also, I think you misinterpretted my previous post's tone. I don't have anything really against designing based on what sounds cool. I'm just looking to see how many people design at the base level rather than the thematic level. The theme/skin of the code to me is completely secondary to the functionality of it.

I'm trying to verify whether other designers take the ideal functionality and develop from there and then add a skin onto it which fits the functionality, or whether they take the skin and develop functionality which fits within the limits of the skin.

I assumed it might be a bit of a tricky topic for me to properly explain, but there've been interesting responses nonetheless.
Back to top
View user's profile Send private message
Author Message
chaos



Joined: 24 Aug 2007
Posts: 35
Location: New Jersey

PostPosted: Mon Sep 24, 2007 2:19 am    Post subject: Reply with quote

I am always working to beat into my developers' heads that they should, if not completely ignore game mechanics, at least start with theme and work from there.

Designing from mechanics often makes for a cheapened experience, in my opinion, and, at least in my little world, mechanics change. An area that's designed solely to provide a moderately undemanding killing ground for level 15-20 warriors loses all its relevance with such minor changes as, say, tearing out the H&S death economy and XP/level paradigm. An area designed around an interesting, engaging thematic basis, on the other hand, stays relevant no matter how the mechanics evolve.

But, as I've said before, I'm really a simulator at heart. I want a fun simulation, don't get me wrong, but I loathe arbitrary "gamey" mechanics that make no sense in-theme. WoW's bonding mechanics, physical impossibility of attacking friendly NPCs, and physical impossibility of ninjaing loot leap to mind.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Zephen_Descartes



Joined: 21 Sep 2007
Posts: 20

PostPosted: Mon Sep 24, 2007 4:06 am    Post subject: Reply with quote

chaos wrote:
An area that's designed solely to provide a moderately undemanding killing ground for level 15-20 warriors loses all its relevance with such minor changes as, say, tearing out the H&S death economy and XP/level paradigm. An area designed around an interesting, engaging thematic basis, on the other hand, stays relevant no matter how the mechanics evolve.


Found it mildly humorous that you find tearing out H&S death economy and the level paradigm as a minor change, but other than that it's an insightful post. For a game that focuses more on roleplay and story, I'd definitely agree that story and theme can be a lot more important.

However for a game that focuses on the game element, I think theme should be a bit secondary to the gameplay. Your example with the area, if the guy is designing mechanically for an area that's just an undemanding killing ground for level 15-20 warriors he will quickly learn just how shallow that is for gameplay and realize that it may be of prudence to increase the utility and purpose of his zone.

However, if he's designing a "Ogre Battlefield" zone as a theme it's a bit more natural to just focus on the killing grounds. Replying to this I think I've realized part of my point is that at times the theme of a system or area can limit you as to the possibilities contained within it. I think stripping away the theme can give you a bit more clarity at times, however I do see the value in designing for a theme.
Back to top
View user's profile Send private message
Author Message
Zephen_Descartes



Joined: 21 Sep 2007
Posts: 20

PostPosted: Mon Sep 24, 2007 4:14 am    Post subject: Reply with quote

Something interesting related to this concept happened on my MUD just yesterday. We've got a random drops system where random drop pieces for an item load and each have base stats, which when combined have a finished item.

One of our Immortals when thinking of ideas to add to the system came up with the idea of some of these pieces being able to be put in a special room and to slowly grow in power over time. The idea was after a bit of time you could improve the quality of a random item even while offline, and help to improve your finished product.

This idea turned me off quite a bit for balance and other reasons at first, until I stripped away the theme and realized the true purpose he was getting at. He mentioned how he loved how he gained skills passively and offline in EVE, and the real heart of the system that he was liking was an idea of passive offline game which draws players back in weeks or even months later.

The problem was, such a system didn't fit in with the theme and system that he was trying to attach it to, but I felt it was still a very valuable concept. As such, we started brainstorming other themes we could engineer it into and came up with Houses, and Horse Breeding both of which could easily work in the concept a lot better.


By stripping away the theme I took what felt like a bad idea, and realized just what sort of utility it had. Doing so let me see that it could actually fit in a wide range of other systems in ways that wouldn't unbalance or seem off or odd. Debate the concept of offline/passive gain all you want, but the stripping of the theme was extremely helpful in figuring out and developing the concept in a new and unique way.
Back to top
View user's profile Send private message
Author Message
KaVir



Joined: 11 May 2005
Posts: 565
Location: Munich

PostPosted: Mon Sep 24, 2007 9:08 am    Post subject: Reply with quote

Zephen_Descartes wrote:
Do you design things based upon what looks or sounds cool?

Or do you design things based upon a particular need or gameplay encouragement?

Or maybe some mix that I've yet to think of or cover in this post.


In my opinion, features should be designed with both of the above in mind. A cool feature that nobody uses is a waste of development time, while bland and boring features give the impression of a bland and boring mud.

Sometimes this can require combining multiple ideas - finding an in-game excuse to justify a cool-looking feature (eg wet armour adjusting your protection vs heat and shock damage because you want rain to make your equipment wet), or creating some cosmetic fluff to wrap around a much-needed addition to the game mechanics (eg customisable messages for an essential teleportation power). But in my opinion the best features are those which seemless blend together both approaches.

(Note: I've added an 'other' option to the poll)

chaos wrote:
I want a fun simulation, don't get me wrong, but I loathe arbitrary "gamey" mechanics that make no sense in-theme.


It's possible to justify most things in-theme.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Tyche



Joined: 13 May 2005
Posts: 176
Location: Ohio, USA

PostPosted: Tue Sep 25, 2007 11:30 pm    Post subject: Reply with quote

Zephen_Descartes wrote:

Found it mildly humorous that you find tearing out H&S death economy and the level paradigm as a minor change, but other than that it's an insightful post.


Are you talking about designing a game or changing someone else's design?
Back to top
View user's profile Send private message Visit poster's website
Author Message
Zephen_Descartes



Joined: 21 Sep 2007
Posts: 20

PostPosted: Wed Sep 26, 2007 12:42 am    Post subject: Reply with quote

Tyche wrote:
Zephen_Descartes wrote:

Found it mildly humorous that you find tearing out H&S death economy and the level paradigm as a minor change, but other than that it's an insightful post.


Are you talking about designing a game or changing someone else's design?


I'm talking about the parent context, which seemed to be changing the design by "tearing out". If you have an H&S death economy and level system to begin with I doubt such a thing would be a minor change to tear out, and it would probably also fall into changing someone else's design to answer the question.
Back to top
View user's profile Send private message
Author Message
shasarak



Joined: 29 Jun 2005
Posts: 134
Location: Emily's Shop

PostPosted: Wed Sep 26, 2007 10:22 am    Post subject: Reply with quote

Zephen_Descartes wrote:
By stripping away the theme I took what felt like a bad idea, and realized just what sort of utility it had.

I'm with KaVir on this one: I don't really see how the two different sorts of impact (a feature being cool/thematic and its effect in gameplay terms) can ever be entirely divorced from one another; any given feature should always be evaluated according to both sets of criteria.

I think what this experience should teach you is not "strip away the theme" but simply "consider both thematic and gameplay implications, but consider them independently". That will certainly prevent you from throwing away gameplay benefits for thematic reasons, but it will also help you to avoid throwing away thematic benefits for gameplay reasons: if a feature makes sense in thematic terms there may well be a way of tweaking it so that it has a positive impact on gameplay.
Back to top
View user's profile Send private message
Author Message
Zephen_Descartes



Joined: 21 Sep 2007
Posts: 20

PostPosted: Wed Sep 26, 2007 11:14 am    Post subject: Reply with quote

I think I bollocksed the explanation of this concept from the beginning. No matter though. I'm not for completely rejecting themes. I'm more for having the ability to strip away the theme and look at the idea independently of it.

Themes are great, they can help you develop an idea a lot further than you might on just gameplay alone. However, in a lot of cases they can also get in the way, such as with the random drops example above. I could have just as easily rejected the idea since it didn't tie in so well with the theme, however analyzing it seperate from the theme lead to some interesting ideas and let us tie it in in other ways. Right now I'm namely looking at houses because I'd like to give them more flare, and I think it would pretty tightly fit the style and theme.

Anyway, it seems we're in consensus here that analyzing the gameplay and theme independently can be of benefit to a designer. The utility of a theme for further developing a concept can't be denied, but in my experience a lot of developers neglected to look at the system proposed underneath the theme. I wanted to address that, and I think I have.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    mudlab.org Forum Index -> Design All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2001, 2002 phpBB Group
BBTech Template by © 2003-04 MDesign