Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 18 Apr 2012
Offline Last Active Nov 19 2013 06:38 PM

#5052082 What would you design if you had UNLIMTED funding?

Posted by PyroDragn on 11 April 2013 - 06:23 AM

I thought I did answer it (at least the one in the post). I was rather clear in saying: Don't do that. (... or so I thought?)


There were two different questions to hand:


"what would you design if you had funding?"




"what do you suggest I do with my cousin's offer?"


You answered the second by saying "don't do it" but the first question, and the one in the title of the post, you didn't answer at all, so I guess that Mratthew is technically correct in that respect.


I have to sort of disagree with your answer of "don't do it" though. I'm sure everyone would agree that you shouldn't waste the money, but that would hold true whether it came from family, or another funder. He doesn't seem to have experience, so he needs to be careful, he needs to do a lot of planning, but no-one goes in to any investment planning to fail.


Millionaires aren't millionaires because they just throw away their money, sure. But not all families are entirely unforgiving, or entirely capitalist in their intentions. The idea that a rich family member may be offering a small cash injection in order to get a family member on their way in a venture they enjoy isn't exactly an impossibility.


The important thing is to find out what is being offered, and the terms for the offer. How much is it? Is it a loan, gift, or investment? What does your cousin want in return? I don't know anything about the parties involved, so there's no basis for judgements. The sentiment to be careful with your family's money, makes sense. To say "don't do it because if you don't make any money then your family will be angry with you forever" is entirely speculative. 

#5052041 What would you design if you had UNLIMTED funding?

Posted by PyroDragn on 11 April 2013 - 01:26 AM

Are the artists on board friends of yours, or are they people you have met online/recruited?


Who is going to be in charge of the design?


If the artists are your friends, then they probably expect some say in what project you go forward with. Even if they're not, you'll want to try and make something that they would be interested in (and therefore more motivated to complete). The most annoying thing that can happen is to start developing a game, and then have the team fall apart because of lack of interest.


You've never programmed AI before, are you therefore expecting to start with something with simple AI to learn? or to jump right in to learning complex AI programming? Get someone else in to help? or to make a game with no AI at all?


If this is your first project (it seems like it is) then you want to aim small. A lot of people jump right in with 'their ultimate team' to create 'the ultimate ultra-super MMO that will revolutionize the industry.' That's just not going to happen if you've never made a game before. A simple puzzle game is your best bet if making something without any AI, or some kind of directly competitive multiplayer game (so you only play versus other people, rather than any AI).


Designing a brand new puzzle game is not easy, and another rehash of a Chain Reaction or Bubble Pop game isn't going to net you much in the way of value or getting on steam - it might be a consideration if you're more interested in the experience at this point, which is a viable route to be taking. A competitive multiplayer game is probably easier to come up with a concept for, but going to be harder to program (in terms of networking and sending/receiving data, although local only multiplayer would be easier).


The questions right now would be, what do you (and your other team members) like to play? What sort of artwork are your artists used to working with? (if they work with 2D sprites, then designing a full 3D modeled game may be out of their league for example). Having possible funding is great. Wasting it is not.


Give some more information on what would you like to build, and maybe we can help brainstorm things through with you.

#5034135 [Problem] The game is being 'fed' to the player

Posted by PyroDragn on 19 February 2013 - 07:02 AM

As Sporniket said above, one possibility is to have multiple outcomes - ie, the choices of the player affect the outcome.


This would increase the workload quite a bit in determining plot. Multiple outcomes/choices means multiple paths and more writing. This does also have the benefit of increasing replayability however, since the player can play again and make a different choice.


Alternative to this is to consider multiple paths to the same outcome. This would mean less writing in terms of storyline, but still a greater portrayed freedom to the player. As a very basic example; In order to progress the player needs to cross a river, get through a locked door, and past a troll. He has a rope, a golden key, and an axe.


1. He uses the rope to cross the river, unlocks the door with the key, kills the troll with the axe

2. He uses the rope to cross the river, smashes his way through the door with the axe, bribes his way past the troll with the key

3. He fells a tree across the river with the axe, unlocks the door with the key, sets up a snare to trap the troll with the rope

4. He fells a tree across the river, ties the rope to the door - and a boulder - then pushes the boulder off a cliff to yank the door open, he bribes his way past the troll with the golden key.

5. He uses the key to pay for a ferry to take him across the river, smashes his way through the door with the axe, sets up a snare to trap the troll with the rope

6. He uses the key to pay for a ferry to take him across the river, ties the rope to the door - and a boulder - then pushes the boulder off a cliff to yank the door open, kills the troll with the axe.


This shows the same three items, in the same three scenes, used in a multitude of options. The key to not feeding the player the story is to allow the player the essence of choice, even if those choices prove essentially meaningless. If the player has a choice between climbing a wall, or going through a gate, then it seems better to the player even if they both (eventually) lead to the same point inside the castle.

#5024503 Comments on level design?

Posted by PyroDragn on 22 January 2013 - 05:38 PM

what part seems inconsistant?


Around the 14-15 second mark in the video, when you're jumping to hit the second ! box, it doesn't seem to detect the hit each time. You end up jumping once when it appears you're still inside the box (3rd jump) and the fourth jump looks like it should register, but you don't get the last coin until you pause a moment for your fifth jump. Looks mostly like you're able to repeat a jump while inside the box and therefore the collision doesn't register since the last collision is still valid.

#4988517 [SFML] Special Collision Detection

Posted by PyroDragn on 09 October 2012 - 04:48 PM

As promised in my previous post, these are my musings on the subject:

I think I've come up with a reasonable solution, that would work to determine collisions for a ball moving at any speed without skipping through any objects.
This does rely on bounding box checks, so if you want to use something more accurate then this isn't going to be it. As FloatRects were mentioned I'm working on the assumption that using bounding boxes for collision checking is going to be good enough.
I haven't written the code because I don't know enough C++ to do so, hopefully my description is easy enough to follow. Some of the later math and theory is perhaps a bit abstract and I hope it's not too complicated (and I hope I didn't get my theory mixed up somewhere).

Posted Image

I use the above illustration as an example for various points. The ball starts at the position in the lower right, and travels to the top left.
Noteable Variables are:
Ball Height = 10
Ball Width = 10
Ball starting X = 100
Ball starting Y = 200
Ball finish X = 50
Ball finish Y = 100

Block Height = 10
Block Width = 20
Red Block X = 60
Red Block Y = 120
Blue Block X = 80
Blue Block Y = 130
Draw a bounding box around the extremes of the movement. Check if this box intersects with any other boxes. This is a very rough check to see if there's any chance of collision. There's no need to do a pixel perfect check if there's no blocks nearby.
If there are boxes, take note of their variables.
Red Box: Top = Y = 120, Left = X = 60, Bottom = Y + Height = 130, Right = X + Width = 80
Blue Box: Top = Y = 130, Left = X = 80, Bottom = Y + Height = 140, Right = X + Width = 100

Find the distance the ball moved horizontally and vertically:
Sqroot((BallBefore.X - BallAfter.X)^2) = Moved.X
sqroot((BallBefore.Y - BallAfter.Y)^2) = Moved.Y

From our example:

100 - 50 = 50
50^2 = 2500
Sqroot(2500) = 50

200 - 100 = 100
100^2 = 10000
Sqroot(10000) = 100

Moved.X = 50
Moved.Y = 100

The reason for Squaring, and then Square Rooting the variable is so that you end up with a positive result at the end. We want to find the distance moved horizontally, it doesn't matter if it's left to right or right to left.
Now determine which of these is larger:

if Moved.X > Moved.Y Then
HorizontalMovement = True
HorizontalMovement = False
End if

If Both variables happen to be the same size it doesn't matter which variable we use for comparison later, so a simple if/else is fine so that one or the other gets priority.

From our example:
Moved.Y > Moved.X so HorizontalMovement = False (the ball is travelling more vertically than it is horizontally)

Now comes some of the more awkward parts:

Take the difference between the movement in the non-primary direction of travel, and divide it by the distance moved in the primary direction of travel.

if HorizontalMovement = False then
MoveRatio = (BallBefore.X - BallAfter.X) / Moved.Y
MoveRatio = (BallBefore.Y - BallAfter.Y) / Moved.X
End If

This gives you the ratio for the smaller increment of travel. For each pixel moved in the primary direction (in our case, vertically) you move this amount horizontally (in our case -0.5)

Now find the actual direction of travel in the primary movement.

If HorizontalMovement = False then
if BallBefore.Y > BallAfter.Y then
Direction = MovingUp
BlockImpact = Bottom
BallImpact = Top
Direction = MovingDown
BlockImpact = Top
BallImpact = Bottom
End If
if BallBefore.X > BallAfter.X then
Direction = MovingLeft
BlockImpact = Right
BallImpact = Left
Direction = MovingRight
BlockImpact = Left
BallImpact = Right
End If
End If

Now according to the direction of travel we want to sort the blocks in the list.

In our Case the ball is moving upwards, and so we want to start with the bottom most block and sort through the blocks going upwards as we check for collisions. This is the actual collision check you will want to repeat for each block in the list:

Now for each block in the list we want to loop through in order and check for collisions:

Find the difference between the starting BallImpact position and the BlockImpact position. In our example this means the difference between the top of the ball, and the bottom of the block.

DistanceMoved = Sqroot((Ball.Impact - Block.Impact)^2)

According to our example, for the first block (the blue block),

Ball.Impact = Top of the Ball start position = BallBefore.Y = 200
Block.Impact = Bottom of the Blue Block = 130 + Height = 140
200 - 140 = 60
sqroot(60^2) = 60

DistanceMoved = 60

Multiply this by the MoveRatio
RatioMoved = DistanceMoved x MoveRatio
DistanceMoved = 60
MoveRatio = -0.5

RatioMoved = -30

Now we use the ratio moved along with the primary direction of movement to see if a collision is true
If HorizontalMovement = False then
if (Ball.X + RatioMoved < Block.X + Block.Width) and (Ball.X + Ball.Width + RatioMoved > Block.X) Then
Collision = True
Collision.X = Ball.X + RatioMoved
Collision.Y = Block.Impact
Collision = False
End if
if (Ball.Y + RatioMoved < Block.Y + Block.Height) and (Ball.Y + Ball.Height + RatioMoved > Block.Y) then
Collision = True
Collision.X = Block.Impact
Collision.Y = Ball.Y + RatioMoved
Collision = False
End If
End If

From our example HorizontalMovement = False

Ball.X + RatioMoved = 100 + -30 = 70
Block.X + Block.Width = 80 + 20 = 100
70 < 100 = True

Ball.X + Ball.Width + RatioMoved = 100 + 10 + -30 = 80
Block.X = 80
80 > 80 = False

Therefore, Collision = False

If Collision is false then you want to loop and check the next block in the list.

If Collision is true, then Collision.X and Collision.Y will give you the position the ball would be at, at the point of collision. What you do from there is up to you. The easiest (though technically inaccurate again) is to redraw the ball at the point of collision, and react accordingly.

Looping through the example for the Red Block:

DistanceMoved = Sqroot((Ball.Impact - Block.Impact)^2)
Ball.Impact = Top of the Ball start position = BallBefore.Y = 200
Block.Impact = Bottom of the Red Block = 120 + Height = 130
200 - 130 = 70
sqroot(60^2) = 70

DistanceMoved = 70

RatioMoved = DistanceMoved x MoveRatio
DistanceMoved = 70
MoveRatio = -0.5

RatioMoved = -35

If HorizontalMovement = False then
if (Ball.X + RatioMoved < Block.X + Block.Width) and (Ball.X + Ball.Width + RatioMoved > Block.X) Then
Collision = True
Collision.X = Ball.X + RatioMoved
Collision.Y = Block.Impact
Collision = False
End if
if (Ball.Y + RatioMoved < Block.Y + Block.Height) and (Ball.Y + Ball.Height + RatioMoved > Block.Y) then
Collision = True
Collision.X = Block.Impact
Collision.Y = Ball.Y + RatioMoved
Collision = False
End If
End If

From our example HorizontalMovement = False

Ball.X + RatioMoved = 100 + -35 = 65
Block.X + Block.Width = 60 + 20 = 80
65 < 80 = True

Ball.X + Ball.Width + RatioMoved = 100 + 10 + -35 = 75
Block.X = 60
75 > 60 = True

Therefore, Collision = True

Collision.X = Ball.X + RatioMoved = 100 + -35 = 65
Collision.Y = Block.Impact = Bottom of Red Block = Block.Y + Block.Height = 130

The Ball collides with the Red Block when the ball is at position: 65, 130

#4987946 [SFML] Special Collision Detection

Posted by PyroDragn on 08 October 2012 - 05:14 AM

He should be refreshing the balls position each frame which makes it impossible to miss a collision check.

This isn't true. In a lot of 2D games it is probably 'Good Enough.' But unless you can guarantee a limited speed there is a chance of missing a collision detection. Even with a limited speed there's still a chance of missing collision in certain circumstances.

If we assume a game of pong running at 60FPS. The paddles are 20 pixels wide. The ball is 30 x 30 pixels. The ball takes two seconds to cross between the paddles (moving purely horizontally). There's 1000 pixels between the two paddles.

Each update the ball moves 17(ish) pixels. At this rate, it's never going to pass straight through a paddle.

If the ball is moving faster. One second between paddles, it'll move at 34 pixels per redraw. 1/2 a second and the ball moves 68 pixels, skipping straight through the paddle becomes quite likely.

If we take the smaller speed. Moving 17 pixels per redraw, but also include now a vertical motion too at the same speed, 17 pixels per redraw, there's still a chance at missing a collision detection:

Posted Image

The image above is drawn to scale. The two black boxes are the before and after position of the ball (moving either diagonally up left, or down right, doesn't matter), the blue box is a paddle. Now, clearly between these two positions it should collide with the top, or right of the paddle (depending on direction of movement), but based on intersect checking it won't.

Moving on to the problem of determining which side the ball hit:

"Edit: Just to explain how you would do this encase you ask. You would make four "collision boxes", one for left, right, top, bottom in your block class. This is very easy to setup based on your blocks X and Y values. Then you would just make a line pretty much that outlines the block for collision checking. You can even have the ball hit the corner of the block - meaning it hit the left and bottom lines then move the in proper direction."

If the ball hits the right or left, you want it to bounce back right or left, so you reverse the X motion.
If the ball hits the top or bottom, you want it to bounce back up or down, so you reverse the Y motion.
If the ball hits a corner, you want it to bounce back diagonally, so you reverse both the X and Y motion.

This is going to be another case whereby having intersect checking in the way you described may be 'Good Enough' but isn't going to be perfect.

Posted Image

Considering the above image. This ball is moving upwards and left, and on the update it hits the paddle. According to intersect checking with different bounding boxes per side, this is a perfect corner hit (it hit both the top and right sides) and so it reverses direction in both X & Y, and moves back down and right.

If you did a per-pixel check on the motion of the ball, then the ball actually hits the right side of the paddle and continues to bounce up and right.

You could define each action based on each corner individually, ie, "if the ball hits the top right corner make the ball travel up and right" "if the ball hits the top left corner make the ball travel up and left" to minimise this. Although this is rather cumbersome way of doing it. There is also still the problem of missing the paddle, or of hitting an incorrect side (ie, if the update is partially inside the paddle but hitting the bounding box for a different side then the direction of travel)

The way to get it to behave perfectly is either to redraw upon every pixel of movement (an obscenely intensive thing to do in most circumstances), or using vector math to determine if the path of the ball passed through an object, calculate point of impact, and react accordingly.

Now, I do agree that having bounding boxes for different sides can be good enough. It depends on the game, how often you're redrawing, how fast the ball will move. It'll depend on how the OP wants to handle it, but if he does want perfect behaviour I don't think this would be the way to do it.

Considering that this is for a breakout style game, even though the path based collision may seem more complicated, it would be simpler in the long run I think because it also reduces the need for consideration of how to react to multiple collisions. If you use intersect checking against two blocks together, then there's a high likelihood that the ball is going to intersect with (for example) the bottom left corner of one block, and the bottom right corner of another, or even intersecting with 3 (or more) blocks.

If you calculate the path and react according to point of impact, if it hits two blocks then you still know that it has hit the bottom of two blocks together, or the right, etc, and can react accordingly.

#4987207 Code Help - Pong

Posted by PyroDragn on 05 October 2012 - 12:43 PM

When you're checking for collision with X variables (the sides of the box) you should reverse the X motion, currently you're reversing the Y motion. This means that if the ball hits either side all that will happen is that the ball bounces back and forth up and down as it continues to move off screen to the left or right.

You haven't changed the velocity of the ball for collision with the top or bottom of the screen at all, so there won't be any effect there.

Based on your code I'm thinking the solution should look something like this:

public void CheckForCollisonWithWall()
    if (position.X < 0)
	    position.X = 0;
	    motion.X *= -1;
    if (position.X + texture.Width > screenBounds.Width)
	    position.X = screenBounds.Width - texture.Width;
	    motion.X *= -1;
    if (position.Y < 0)
	    position.Y = 0;
	    motion.Y *= -1;
    if (position.Y + texture.Height > screenBounds.Height)
	    position.Y = screenBounds.Height - texture.Height;
	    motion.Y *= -1;

Assuming that the paddles are on the top and bottom of the screen, then you're correctly reversing the Y speed. If the paddles are on the left and right then you need to reverse the X speed. Looking at it I presume the paddles are on the top and bottom and you didn't include collision with the top and bottom of the screen since that would mean someone has scored a point. Though I don't know why you are resetting the position of the ball in that case.

I'm unclear on how you're determining how the ball moves through the game world. Are you simply adding to position every update tick or are you doing proper movement with distance = velocity * time (assuming constant velocity since this is pong)?

When the ball collides with a surface, you will need to reflect the velocity vector. Merely changing the sign from negative to positive or vice versa will give you weird results.

I don't think he's using a constant speed vector. I'm assuming that he's using two variables for X and Y speed and incrementing them onto the ball for each tick to move the ball. If that's true then just reversing the sign of the appropriate variable would produce correct motion.

Hopefully the assumptions I've made are close to true and something here helps. Let us know how you get on.

#4986349 Why games should be challenging?

Posted by PyroDragn on 03 October 2012 - 05:53 AM

You are right, I presumed that if I start by stating personal opinions people would understand that everything else is based on those opinions.

This wouldn't be a problem if the correlation was more obvious between the two.

"My opinion is RTS games are too hard" therefore "they should make RTS games more intuitive" would come across more clearly.

in your blog you've said:

"My opinion is games must be challenging" therefore "modern games lack originality."

There isn't a proper flow of thought between these two statements. The fact that modern games lack originality is something you've introduced as a fact from elsewhere. Essentially; Because modern games lack originality they're less challenging, and that's a bad thing based on my opinion.

To be clear I actually do think that originality in games is a problem, I'm just trying to help you see where things have gone awry in your writing.

#4986343 Why games should be challenging?

Posted by PyroDragn on 03 October 2012 - 05:07 AM

Of course you're entitled to your opinion, though I'm going to say that I didn't get that it was a personal opinion on your blog. This is more of a critique of your writing than about your opinions on the game design. You started with a personal opinion and view about what game design is, that is clear. But after the third paragraph you outline everything else as fact:

Most modern games suffer from lack of originality,
Players will refuse to play shooters after playing a few because they're all the same,
Most indie games are clones,

That's how it reads to me anyway. Essentially you give your opinion at the start, then state your view thereafter as being concrete. In particular when you talk about during the beta test of your game:

The non-gamer testers would continuously complaining about the difficulty of the game and the fact that they are forced to learn and perform certain actions within the game. Accumulated, these actions ARE the game, if you take those out there is no game to be played at all. By complaining, they only prove why they aren’t gamers in the first place, because they have no satisfaction from playing games at all and every artificial challenge imposed by the game is immediately rejected.

It doesn't read as an opinion here, it just requires more careful phrasing and layout to show that the post is based off of your thoughts and opinions. Trying to find the balance between saying that "Everyone who plays shooters for a while will get bored" and "I've played a lot of shooters, and I'm bored because they're all the same - this will happen to other players."

#4986325 Why games should be challenging?

Posted by PyroDragn on 03 October 2012 - 03:24 AM

I'm going to disagree with a few of the points you stated too. The most obvious point is that apparently because I've played a lot of shooters, I'll find any other shooters boring because they're the same. Even if we exclude the fact that Halo is a very different kind of shooter to Sniper Elite, I have played Modern Warfare 1, 2 and 3, and enjoyed them all, and I'm looking forward to the next iteration.

I'm going to say that I don't think games have to be challenging. I like some games to be, but it's not a prerequisite as you seem to state. A game has to be fun. Challenging and fun can be as good as simple and fun. I like spending hours of time building houses in the Sims (on empty plots so there's no money worries). I could do anything I want, there's no way to 'fail,' it's not challenging, but it's engaging and that's the important part.

I dunno, in short I disagreed with most of what you said, although I think I agree with the sentiment. If a game is supposed to be challenging it should be challenging. Not dumbed down to cater to those that don't want a challenge. I just think you should realise that not every game needs to be challenging to be fun. Sometimes it's nice to just play.

#4985013 Pong Hit Detection

Posted by PyroDragn on 29 September 2012 - 05:50 AM

EDIT: I have solved my problem. All I needed was to change the send and third ifs to if elses. If anyone could tell me why this is, I'd love to know.

A possible explanation (hard to say without testing it out myself) but with the three statements as individual if statements it would execute more than one. This could mean at times you were essentially reversing direction more than once and making it appear as if you didn't change direction.

#4982317 pong in java

Posted by PyroDragn on 21 September 2012 - 04:52 AM

Also, just something I noticed. the collision looks okay for when the ball bits the players panel. but when it hits the computer panel, it looks like it is not bouncing back until
ballx + ballWidth <= computerPaddleX + computerPaddleWidth
if you get what I mean

The computer paddle collision detection isn't added yet (that I can see). The collision detection only involves play paddle variables. Although, granted, this wouldn't correlate exactly to the computer paddle.

Some notes: (trying not to give too much detail)
I would adjust your AI slightly. I think you'll see what's wrong once you fix the missing semi-colon !Null pointed out, and you see the paddle moving.

Your paddle collision detection is slightly off:

// top-left of ball is to the right of top-left of paddle

This bit just needs a bit of thought.

#4982304 PvP Timezone Problem

Posted by PyroDragn on 21 September 2012 - 04:18 AM

Is there any specific reason that you're making this for real-world countries?

One obvious way to ease the problem is to disassociate the game world with the real world. If every player simply chooses their factions from made up associations, then you should (hopefully) end up with a spread of players through all timezones within each faction and you don't end up with the problem of one timezone being represented at one time.

Oh, and secondly (does such a word exist?)

Secondly, thirdly, fourthly, fifthly, sixthly, seventhly, etc are all correct. Technically one hundred and twenty-seventhly would be correct, but when you get that high the point becomes kind of moot.

#4982303 Guide to bad game design

Posted by PyroDragn on 21 September 2012 - 04:07 AM

Give the player a powerful super weapon right at the start of the game, but you have to collect all 10 pieces of ammo in the game to be able to use it. Put 1 piece of ammo in a super ultra secret hidden area that is impossible to find.

#4980064 A few interesting system designs I've been throwing around...

Posted by PyroDragn on 14 September 2012 - 08:19 AM

I'm going to second Ashaman's opinion in that, while Designers may dream about these idyllic scenarios, they're just not realistic to implement.

Persistent & Dynamic Economy

Okay, now the title pretty much says it all, however, let's go in to more detail! Basically, you have NPCs, now, what if, wait for it, they ACTUALLY DID SOMETHING.... Yes! NPCs functioning as something else other than the wonderful conversation (heh..)! Enough of the jokes...

Gatherer NPC finds seeds, sells the seeds to the Farmer NPC, Farmer NPC plants and harvests them then sells them to Vendor NPC. Vendor NPC then sells to players or OTHER NPCs.

This idea is more geared towards a multiplayer environment, so as the player's actions can actually affect the economy. (Steal crops from the farmer, the farmer can't sell the crops, the farmer can't buy seeds from the gatherer, the farmer can't plant anymore seeds, and finally, the farmer can't sell the crops to the vendor for the vendor to sell, and so on...)

You could have a persistent simulated economy if it's the focus of the game - some sort of world simulation, but integrating it into an MMO for example isn't going to work because there isn't the scope for it to be a main feature. The economy of a farm is dependent on much more than a few crops.

If you have a field with the farmer's crops, a few lootable items to represent this and a player comes along and steals one, the farmer is losing a significant portion of his crop. In a couple of minutes of theft the farmer would be completely ruined.

If you have a large area, with dozens and dozens of items it'll encourage groups of players to come along and help themselves to free food, and the farmer is ruined simply because it's easier to take from the source.

Either, the effect a player has on the economy needs to be reduced (in which case, why not just simulate the economy without player interaction?) or the scale of the economy needs to be greatly scaled up: an example would be that Elwynn Forest in WoW would need to be just farmland in order to support an area the size of the original Stormwind.

You could add some simple price fluctuations into the market, but having a working economy would require an inordinate amount of work, for no real benefit.

Unified Massive Multiplayer Experience

This means that everyone is working towards the same MAIN goal, and are affected by changes in the world that one player causes. For example, I was just recently thinking of how awesome it would be to develop a Diablo fan-game. In this rendition, it would be a multiplayer 3D third-person hack-and-slash game with a dark gothic feel. Well, it would follow the story of Diablo II, but everyone would be involved, new and veteran players; however, this would be different from most MMOGs, as in the bosses are the only bosses and will not respawn magically from the pits of hell... The only thing to respawn would be your common enemies and the occasional unique mob, etc.. In effect, you would really be fighting to save Sanctuary from the three Prime Evils, which would be EXTREMELY difficult. By difficult, I mean several dozen level 99 characters still trying to struggle against their immense power. I mean, it would only make sense that the three Lords of Hell might be a little epic? Anyway, this is just an example (unless someone wants to help me develop it XD jk)

Anyone who's thought about making an MMO at any point, has dreamed about the Mythical "Real World" where what you do matters. But even something relatively simple - Large Bosses that do not respawn - is not realistic. Supposing you have these three primevals. Dozens of players work together over months, manage to kill one of them, it's a great accomplishment.

What happens to the players that missed out on the kill? People that were offline? What about players just joining the game now?

Someone joins the game a few weeks later, the second boss is already dead, everyone is working towards killing the third boss. They still have to level up to a position where they can help, by which point the last boss could be dead. When the last boss is dead, then what? Are you going to release an update with a new boss, and a new calamity? If you are, and will continue to do so whenever the next boss dies, then maybe you could get this to work.

Essentially, just by limiting the bosses you're limiting the endgame of your MMO, and that is always a bad thing.