|
1241
|
Developer / Design / Re: Grinding mechanics.
|
on: September 20, 2010, 07:11:46 AM
|
Here's a thing that somebody told me in a different forum - that the primary trait of an MMO is and should be time-sink based challenges. Perhaps there's some merit to that? I feel like most people consider grind to be universally bad, at the best it's just a substitute for variety of content. But there are people who like to grind, who jump into online games and relish the thought that their patience will be tested.
Is Grind a legitimate style of gameplay, or is it really something terrible that should be phased out of game design completely?
I'm against deliberately designing games to be an addictive time sink. It pushes games from being casual entertainment into the realm of alcohol and recreational drugs. It's fine to sit on a computer and play your whole weekend off if you've got nothing to do. But grind-heavy MMOs are encouraging you to sit there all day. If they want to test patience, at least design the concept so that you log in every day, not literally every 5 minutes. It's possible to design a grind that isn't boring. I didn't really feel the grind when playing Guild Wars or City of Villains, even though it's there. Grinding can be a legitimate style of gameplay, but a poor designer would make it boring.
|
|
|
|
|
1242
|
Developer / Design / Re: People you'd like to see make games.
|
on: September 16, 2010, 04:17:30 AM
|
|
Robert E Howard. His Conan books have the kind of gory detail I wish games had. I hate games where you shoot someone in the arm and it flies off, with blood spraying everywhere. Howard goes into fine detail on combat, and keeps it smooth flowing. He knows how to make sorcery fricking scary too. Combined with Lovecraft's imagination, those two could make some epic RPGs.
|
|
|
|
|
1243
|
Developer / Design / Re: Grinding mechanics.
|
on: September 16, 2010, 04:11:10 AM
|
I'm on the anti-grinding side of the fence. I don't have enough time in my life to do what I want and click the same button repetitively in a game. I certainly wouldn't pay to skip the grind, though, because IMO, any game that relies solely on grinding as a game mechanic can't be a good one. There are plenty of people who do love grinding though. Grinding isn't always boring. The whole idea is that it's an "A for effort" thing, in that the people who put the most effort into the game win. They don't even put heavy effort, just easy, laid back effort, sometimes with a friend. My favorite form of grinding is what Cyber Nations does. Every day, you log in once for 5 mins, pay bills, then log off. You have to do this once every 25 days to not get deleted. It's very simple, it strongly appeals to casual players, and the hardcore ones can and do find other ways of getting ahead. No surprise that it's got a large player base. Anyone who's ever created a CN nation would immediately see the other form of grinding - recruitment. Hundreds of alliances send out lots of private messages in the game every day, trying to recruit.. that's another form of grinding. Another form, more obvious in their tournament version, is trades. An individual has to dig into the game mechanics, find suitable trades for their nation, and spam dozens of others to try to get ideal trades. It's still a lot of mindless effort, but it becomes a bit interesting because you're always doing the effort with other people. Since heavy grinding games are almost always social... it might be a good idea to try to force them to mass interact with others. But that introduces social power, and some people who look for simple grinding games don't want to deal with that.
|
|
|
|
|
1244
|
Developer / Design / Re: Looking for blogs or sites about good game design
|
on: September 08, 2010, 02:32:49 PM
|
I feel that game design's a bit like philosophy. There's plenty of books on the stuff, but you've really got to sit around and discuss things through to get better. Or even better, find a tough problem and try to find a solution. That said, this is my favorite blog: http://jonathansfox.wordpress.com/I don't always agree with him, but he makes some good points, writes them in a fun to read manner, and gives me something to think about.
|
|
|
|
|
1245
|
Developer / Design / Re: Reference of game design concepts
|
on: September 08, 2010, 02:24:44 PM
|
|
Yeah, I think these are rather common sense. Most people have all these concepts firmly in their head and can analyze when a game is becoming tedious and boring. It comes with experience to anyone who does it often enough, just like a mathematician should be able to figure out 8*22-cos(0) without a calculator.
The tough parts of game design is when you have a situation where there's no correct approach to it. When I write down a reference document, it says "A is not fun and B is not fun, but I chose A because... (how it suits this game concept)"
For example, a common problem is grinding in RPGs. You have something that is unchallenging to most people, but provides satisfaction. But if you make it more challenging, it adds frustration to a few, more satisfaction to others. How would you approach that?
|
|
|
|
|
1246
|
Developer / Design / Re: What makes pure management game good?
|
on: September 08, 2010, 02:10:25 PM
|
Most of my favorite games are management games  I'd go with SirNiko's definition for this one. Management games seem to blur between strategy game (because of long term planning & limited resources) and simulation (because management games copy/model real life thingies). The ultimate management game is Football Manager 2010. I don't know if you play it, but it has all the aspects of a perfect game... it's a game that generates tons of revenue yearly, it's highly addictive, it has a large fan base that discusses how to approach the game. I'd say it's a good benchmark to compare most management games to. The goals are simple - to score goals. But there's so many ways to do this. You appear to have a only two resources.. money/fans and players. And maybe you can count staff. Yet, each player has dozens of skills, his own personality, fame. All of those are more subtle resources which everyone will be fighting for. There's also managing your set of resources against the opponent's set of resources, different formations, different teams. Since I love management games so much, I've tried working on a few. And I'd say that they're some of the toughest to design. Making a management game is pretty much like engineering something. There's just so many ways to unbalance something. A feedback system is a good way to balance it, perhaps.. like if the player was building lots of gold mines (e.g. most profit), the price of gold would lower. Or if the player's buying a lot of big trains (e.g. most efficient), the big trains become rarer and more expensive. Or a competitor might deliberately attack the focal points of the player. So, personally, what I think every management game should have is: - Something to simulate. There's a game, Rags to Riches which simulates stocks. This is boring because you don't get to see that you're winning. You need to simulate something for the player to evaluate their success - Sports, space empires, companies, cities, etc. - Feedback economy. It balances itself. - Different valued resources. It's not a fun game if all the player only needs to collect one kind of resource, like residential areas. The player needs to achieve some kind of balance. Some kind of Rock-Paper-Scissors effect would be useful if the player is competing against someone. - Risk. The player wouldn't be able to devise a "perfect plan". A small element of risk would be involved in many decisions. This could most simply be done by just adding making some random effects. Good managers will have plans that hit upon bad times, requiring tough decisions, but should perform well in the long term.
|
|
|
|
|
1247
|
Developer / Design / Re: Morality mechanics
|
on: September 08, 2010, 01:47:57 PM
|
|
Great points, Squiggly_P. I hadn't really thought of it that way. If you want to have morality mechanics, they have to merge very well with the game's objectives. I think Iji did the best implementations of morals so far. It tells you early on that killing is bad, suggests that you can win the game without hurting anyone, and in the end, it actually makes you feel bad about killing people. The bad feeling comes not simply because you were labeled a bad guy, but because you could've played a different way and gotten a different ending.
On the other hand, Lose/Lose practically yells "If you kill aliens, you are retarded and immoral!" It doesn't come out as very clever or philosophical, because it gives you an objective and taunts you for not achieving it. The morality doesn't shine so well because it goes against what you're asked to achieve.
I think basically the whole reason to put morality in a game is for the game to react to your actions. It shouldn't be that the game is judging you for being good or evil. Instead, it should be used as a tool for depth to reflect what you're doing. If you do some very bad things, but the game doesn't recognize them, then you feel a little left out. If you do some very bad things, but the game treats you like some hero because you donated a pile of gold and killed some villain, then the result is even worse than with no morality system at all.
If you can directly have actions without involving some kind of morality counter, I think that's clearly the best way to approach it. The factions idea is a nice middle ground too, because it solves the other problem with deciding how the storyline goes when you give the player a million choices.
Hmm... looks like the real question is not morality mechanics, but having the game react to the player's actions.
|
|
|
|
|
1248
|
Developer / Technical / Re: Programming is hard. How did you learn?
|
on: September 08, 2010, 12:36:05 PM
|
|
Heh, I got a BASIC book when I was 5 as a birthday gift. It didn't really help much. Learned VB, HTML, and those game maker products just from the Internet.
I learned C and C++ from uni.. though it was a horrible class that didn't teach me things like memory management. Actually learned to use it properly after transferring schools and (nearly) failing a few programming classes.
IMO, once you pick up the basics, the best intermediate level way to learn is open source. Open up a game, try to understand it, and hack it to do something you think would be cool. You'll learn why the program is designed in certain ways and you'll learn better coding techniques and why they work.
Honestly, the easiest way to start learn a programming language is the same way as learning a normal language. You stop thinking if you could, which is the best, and just go and learn one that you like. I've seen teenagers sit around for years wondering which language is the best to learn. Yet a baby learns his native language and many others in just a few years, no matter how complex it is. It's not that babies are smarter than adults, it's just that they just do it. You've grasped more advanced concepts and it's easier to learn a programming language in less time.
Programming languages are not much harder than normal languages. It just takes a lot of starting effort and a lot of practice to get them.
|
|
|
|
|
1250
|
Developer / Design / Re: Morality mechanics
|
on: August 29, 2010, 03:32:49 AM
|
This video provides some interesting thoughts on morality. One of the suggestions is to use a 'morality wheel' to judge your actions on several different axes.
That video poses a very good argument. The morality wheel was what I was going for, illustrated more clearly. Also, one thing I haven't thought about is that doing something good matters much more depending on what it's worth to the player. Giving $1 to an orphan is worth a whole lot more good to a starving lvl 1 character, compared to a multimillionaire lvl 30 character. Yeah, it shows why you can't always simulate the consequences of the player's actions. It takes too much effort for a lot of games. But it is a good point in that every RPG character could be evil. I think Iji made a good point of this.. you have the choice to not kill anyone at all, it's more satisfying, but it's a lot harder than winning the game with violence.
|
|
|
|
|
1251
|
Developer / Design / Morality mechanics
|
on: August 28, 2010, 05:02:31 AM
|
So there's a lot of talk that games aren't very good judges of morality and we should abandon the whole good and evil theme. It's often a binary slider. You can kill random people and eat baby chickens to become evil or you can donate money to orphans and turn down rewards from homeless people to become good. It often just leads to players making illogical decisions to get to a certain alignment. Morality is more complex than that. What's the alignment of a man who kills civilians to end a war against his country faster? What about an elf who massacres an orcish community to free his brethen from slavery and save the trees? Where do you put a devout paladin who regularly helps do good but also kills evil people (and a few innocents) because he believes that evil is a cancer? What about stealing from the rich and giving to the poor? So, what's a good way to judge good and evil in a game, but still rate them as morally gray? My idea would be to give their actions certain points but based on different moral scales. For example, someone who kills a good person because he was told to gains 20 evil points in life preservation and +5 good points in loyalty. Someone who rescues a villain who plans to destroy the world gains +40 good points in life preservation but 20 evil points in utilitarianism. It needs a lot of tweaking, but that's basically the idea. Anyone else have better ideas?
|
|
|
|
|
1252
|
Developer / Design / Re: Non-standard roguelike settings
|
on: August 27, 2010, 06:50:47 AM
|
Everything can and should be made into a roguelike.
Heh, funny thing about that. Just about every game setting idea I've ever proposed had at least one person suggesting that it should start as a roguelike.
|
|
|
|
|
1253
|
Developer / Technical / Re: Language with good data management (or a better way to manage data)
|
on: August 27, 2010, 06:30:37 AM
|
Hmm... good points. I'll look into those. Making a map seems a bit easier since the concept fits in my head right now  Wait, now that I think of it, a body map doesn't be a good idea because I'm prototyping it. I don't yet know whether or not I need all those parts. I'd end up spending more time building the map than the time it'd save. I'll go and look at different data structures for a few days.
|
|
|
|
|
1254
|
Developer / Design / Re: adding Strategy to Rock Paper Scissors
|
on: August 25, 2010, 02:06:19 PM
|
|
IMO, RPS isn't really a good system to play against the AI. Ask any professional RPS player, it's mostly either psychological (how people 'normally' act) or statistical (whether they're playing the same things evenly or whether they bias towards one type). Computers only do statistical, and not that well since there's already another psychological aspect to it.
|
|
|
|
|
1255
|
Community / Creative / Re: Longest time spent fixing a bug?
|
on: August 25, 2010, 01:55:43 PM
|
Days?
Multi-threaded, multi-process, real-time system with more than 500,000 lines of code. All sorts of bad stuff can happen.
Lol, what is that? Some kind of smartphone operating system? I've never really spent much time on an individual bug. Maybe around 8 hours at worst, which is about 3 days. Not counting the bugs I've never fixed. My games are pretty straight to the point, none of that multithreading crud, so they're not so hard to debug. Figuring out what to code is another matter. Spent about 4 months straight (barely leaving the house and all) on pitch detection code.
|
|
|
|
|
1256
|
Developer / Technical / Re: Language with good data management
|
on: August 25, 2010, 01:48:19 PM
|
I'm not really sure how to describe it, lol. I want to do something with combat details. Taking an example of how it would be in Lua... Let's say that I have a character. It would be something like chr[n].. chr[0], chr[1] so on. For combat stuff, I want to divide that character's body parts into different parts so it looks like chr[0]["head"], chr[1]["leftArm"]. Now I want to put more info inside that info. Maybe divide the skull into 10 different points and track damage for each.. it'd end up like chr[n]["head"]["skull"][9]["bluntHP"] = 3 This gets pretty tedious to type the more I start nesting it. And to recover the stored data, it'd be x = chr[n][bodyPart][bodyDiv][loc][var], where you have lots of different variables to set, and long functions looking like ChrStrength = GetChrStrength(armMass, physicalStrength, age, ...) WpnDamage = CalcWpnDamage(GetWeaponInHand(*chrB), GetWeaponInHandMaterial(*chrB), ...) GetDamageOnChr(chrA, bodyPart, bodyDiv, loc, chrB, weapon, angle, WpnDamage, ChrStrength, ...). Actual situation might not be so silly, but this gets long and illegible the more I do it. So, is there some language designed to handle something like this? Or maybe I'm taking the wrong approach with an typical language. If so, point out what I'm doing wrong 
|
|
|
|
|
1258
|
Developer / Design / Re: Evaluating a Game Idea
|
on: August 16, 2010, 12:36:23 PM
|
|
IMO, design document does it. Just have a little preamble about why the game is going to be fun. I find that with good concepts I gain more and more momentum. I've managed to kill off the bad ideas because I just can't explain what makes those games fun.
But I mostly focus on RPGs and strategy games... this might not apply so well with platformers and shooters, where the focus is on reflexes. With those, prototypes work much better.
|
|
|
|
|
1259
|
Developer / Design / Re: Genres that don't get enough attention
|
on: August 12, 2010, 06:26:36 AM
|
Those are both complicated, by the looks of it.
Neptune's pride is nice because the rule are so simple. It's a lot less complex than a lot of board games actually, so it ends up feeling like one.
Cyber Nations is not complicated at all... it takes only about 5 hours to truly master the game mechanics, and a bit of experience to know how to war well. But because of its simplicity, anyone can pick it up and most of the game is focused entirely around inter-alliance affairs. I can't think of any MMO economy games. The only one I can think of is EVE with it's player based market. That would be a good genre.
I've seen a few on Facebook, and a few other player based markets, but most of them are poor. I'd love to see a proper economy game. True interactive fiction would let you do whatever you feel like doing and tell you how the world responds. In an adventure game, you can't pick up the background stuff or do other things that aren't relevant. In a real IF one, you should be able to.
I'm just wondering, what makes you say this? I don't see why you should be able to pick up every item in an IF game any more than you should be able to do so in any other genre. It's not really being able to pick up every item... it's more of a game where you get to interact with the world. I'm sure we've all come with situations like: "There is a glass of hot water. You are thirsty. There is a fridge here." "> Drink water" "The water is too hot." "> Open fridge" "The fridge is not a container!" "> Take ice from fridge" "What ice?" "> Put glass in fridge" "You cool down the drink and drink it. You do not die! +1 score!" A good IF game would let you blow the glass, get ice, etc. It's not so much about finding the right solution to win, but exploring and interacting with the world. You sacrifice the length of the game for some depth. And it's more fun to find out that you could've completed the puzzle in many other different, but logical ways. You may not really have to pick up everything, but the game shouldn't toss you a "syntax not found".
|
|
|
|
|
1260
|
Developer / Design / Re: The value of a design document and other motivational woes
|
on: August 12, 2010, 06:08:11 AM
|
|
I only make ambitious projects. IMO, I can't work on game ideas that's been done before, so every game I make tends to be unique enough to need at least 20% design, including designing code.
So, to me, a design document is essential. Programming seems to be a little counter-intuitive to the design. When I want a character to jump, it's not just jump() straight away, there's a bunch of code that has to written that tells the character to jump. When I'm coding the amount of damage an attack does, I don't want to open up MATLAB to find the balanced amount of damage, I just want to toss in the numbers into the game and focus on the code.
I find that switching between design and programming gives me a headache. It breaks my train of thought, and I don't like having lots of trains running through my head. So, yeah, in my case, the ideal is to write a nice design document, or at least some basic plans.
If you can make a game without needing a design document, I'd say go for it. I think it should be kept as simple as possible. If it starts to feel bureaucratic, you're spending a bit too much time on it. Yeah, I think to-do lists work just as well in some cases. When you expand a to-do list, it turns into a sort of design document.
|
|
|
|
|