Page 4 of 5 FirstFirst ... 2345 LastLast
Results 31 to 40 of 45
  1. #31
    Join Date
    Jul 2002
    Location
    In space
    Posts
    5,428
    Trying to keep it simple - and yes, I realize short posts can be out of character for me - we're just developing the architecture that will support the world at this stage. Not the world itself. Plus, we're only in the research phase of such development.

    In a perfect world (one that I imagine cannot exist under the constraints of a game studio with investors and publishers, etc., etc.) it seems to me that you'd want to design the infrastructure of the system such that it could support as big of a world as you could ever hope to support in your wildest dreams. Then, when the design phase comes through, you design what you can, knowing full well that when expansion time rolls in, you'll be more than ready.

    I realize all of this has been said before in not so many words, but I wanted to distill the aspect that seemed most critical to our situation.

  2. #32
    Join Date
    Nov 2009
    Location
    Dallas, Texas
    Posts
    170
    Before I start, i just want to clear one thing up in case it's not clear. I am not arguing for a small world. I'm arguing for a compelling, story driven game for which a world is built. To me, that means something the size of WoW or smaller. I don't consider WoW small.

    80% is a number that I pulled from your posts JJ.
    You're right, I thought you were agreeing with me in terms of what unexplored meant but zak cleared that up. My numbers were more to make a point than exact math.

    The only reason I would imagine an area would never be visited by anyone is if it was either unreachable or there was no reason to go there which is why procedural generate content interest me so much.
    The first thing people do in WoW when they hit 20 is get a mount and then at 70 they get a flying mount. Why? Because walking everywhere sucks! If I didn't have a mount in WoW I would gouge my eyeballs out with a pencil and feed them to my dog. Now you're talking about a zone that's 2500sq miles? Most players don't want to have to log in to play a game and then spend the next several hours traveling. They want to play the game and exploring is only a small part of that. That's why I say most of the world will be unexplored. The procedural content I experience for taveling 30 minutes outside a city will offer the same experience as the procedural content 30 hours outside the city. If procedural content worked, all games would use it because it's super easy to do. The reason they don't is because the fun factor for procedural content has a very short lifespan. Procedural content is another one of those exciting problems for programmers to solve but has very little meaing for players in the long run.

    So there's really no reason for me to spend all that time and effort walking somewhere for procedural content. Too much dependence on procedural content is predictable and boring in the long run no matter how creative you try to get with it. So my assertion is that quite a bit of the world will be unexplored because the experience players have with procedural content is going to be the same whether I travel 1 hour out or whether I travel 30 hours outside a city. Sure the mobs might look different, etc, however, like darkfall, it's just boring grinding on the same predictable procedural content for hours on end with mobs that have different skins and predictable AI. I remember playing EQ1 and sitting in dreadlands for 12 hours pulling mobs over and over and over again trying to level past 45. Procedural content is necessary but too much of it doesn't work.

    Now your answer for long distances might be fast travel, however, in a world the size we're talking about, even with teleporters I will still have to walk for hours to meet my friends, unless you put a teleporter in every spot around the world there is one every 30 minutes or so. Then again, you have to ask yourself, why make the world so big? Most designers will tell you that a huge emphasis on fast travel communicates to your players that there is a flaw in your design. So the best option is to make the world smaller, in my opinion.

    My main concern is that 90% of the tech is going to be built to support features that represent 10% of the actual game play experience. Most games start out focused on the core game loop. An example of a simple loop would be I fight monsters, I get loot, I level up, I fight harder monsters, I get better loot, I level up. That's a small boring loop where the only goal is to level up. However, all games have some kind of core game loop and most of the development time is spent fleshing out that game loop with RnD going in the background. However, terrain is only a prop for the game, not the game itself.

    Large massive terrains are all about programmers making cool tech and really have nothing to do with a fun game at all. I just don't want to fall into the trap that says this tech is really cool so lets try to figure out a way to stuff a game into it. I'm not saying we're there yet, I'm just raising the warning flag.

    This is still very early in the R&D process so nothing is a for sure yet at best we may have a couple very soft maybes. A balance will definitely have to be found at some point but it is still too early to worry about it until we know how far we can push it.
    I totally agree. You should RnD everything you can and yes, my concerns are probably a little premature. I'm just trying to make sure you have plenty to think about when it comes down to deciding how to scale things for the real game

    In a perfect world (one that I imagine cannot exist under the constraints of a game studio with investors and publishers, etc., etc.) it seems to me that you'd want to design the infrastructure of the system such that it could support as big of a world as you could ever hope to support in your wildest dreams. Then, when the design phase comes through, you design what you can, knowing full well that when expansion time rolls in, you'll be more than ready.
    I think it depends. If your goal is to ship a game, than your design and game dictate how large the world should be so there's no reason to RnD something the size of earth if the game design doesn't need that. This is because the amount of work required to support a massive world is way more extensive than what's required to support a large world the size of WoW or smaller. So that extra RnD time is better spent working on other tasks that support the design of your game. That's typically what a studio would do. Not because of financial pressure but because we just don't need to go places that aren't in our design. Every studio works differently, but this is how things have worked in the studios i've been involved with and the same goes for my friends in the industry.

    All that said, I totally get the desire to want to try things out and see how they work. I also know raising this is a bit premature. I'm just trying to make my point early so that when the time comes you have plenty to think about . Again, whatever you decide to do i'll be here to help any way i can.

    For that reason I would RnD around the design specs so that I have more time to spend on things relevant to what I know the game needs. So rather than spending time on huge worlds, I might try to work on things like vector field displacement, texturing techiques, or other things that might improve the richness of the world.

    Well look to what happend to twitter. They didn't thought well enough the DB system and had a lot of issues some years ago. This happend because they though in a "smallish manageable" DB.
    Actually it woulnd't 1000x more fun to group a couple of WoW servers in one ? well one thing why they can't do that is because of the map size (and other reasons of curse).
    Even look at the asp.net series... Nelson is putting together a Uber complex framework for the management system that could be solved much more simpler than what he is pulling off.
    The fact that one company had issues with their database doesn't change how documented, industry standard, best practices work. Your assumptions about the issues with Twitter are not exactly right. Twitters problem was not an error in the size of the release. Twitters problem was an error in their design which resulted in a problem with the release. Documented software development processes are what they are so I implore you to go do some research on them so you know what they are and how they work before being so quick to argue against them. Then you will see why suggesting that we release every feature we can in the first release is a bad idea.

    In terms of Nelson, his release may seem complex to you but that complexity is what's required for the minimum funtionality of a first release. Minium functionality for a first release is not related to how complex something is in any way shape or form. Again, the best practice for writing software is to release the minium functionality required for version 1 and then come up with a release plan that results in new releases every 2 to 4 weeks. A great example of this is Epic Games who has a new release of their engine every month and follows the SCRUM process.

    Additionally, it's very bad decision making practice to take an exception to the rule and try to make it the rule. Just because one guy in the NBA is 5'3" doesn't now mean every short guy on the planet can drop out of school and go try out for the NBA. The rule is that you still need to be tall to play basketball. So I'm sure there's a few examples of companies that tried to use something like SCRUM or XP and failed. However, that does not mean agile doesn't work and we should ignore it. The vast majority of companies that adopt some form of a development or agile process are extremely successful.
    Last edited by fatgav; 05-04-2011 at 06:48 PM.

  3. #33
    Join Date
    Jan 2010
    Location
    Buenos Aires, Argentina
    Posts
    148
    Hey JJ you are getting a little syntactic with me.
    My twitter example was about how they missed the point of their release. They designed theirs DB for 100 users and they had 100.000 (this are just example numbers) and they had very little time to respond to that demand and had all sort of issues. Other companies had similar problems some of them had the time to keep up to the demand others didn't. And this happens to a lot of internet Companies.

    The App Nelson is doing in the class I'm sure that theres no need for autafac or a console or his almost obsessive search for the ultimate abstraction of each class. For the first release of this app wich will handle this class only for now is way way over what's needed for this 200 members class, it's an enterprise class app with thousands of users.

    There's nothing wrong in trying to think a highly scalable terrain system. They can launch the game even with a fraction of zone and scale as needed ... And thats hit for me since like in every successful mmo out there can't scale their world and instead they only ad servers and migrate players as requested forcing them to adapt a character to the reality of each of the servers.
    Yes this is more manageable and profitable for the developer but maybe just maybe if blizzard had the tip that they will have 11 million + players they'll had a bigger world.
    Last edited by xavierk; 05-04-2011 at 04:23 PM.

  4. #34
    Join Date
    Nov 2009
    Location
    Dallas, Texas
    Posts
    170
    There's nothing wrong in trying to think a highly scalable terrain system. They can launch the game even with a fraction of zone and scale as needed ...
    Finally! Yes, that's what i've been trying to say! Start with something managable and then see if you even need to spend all that time and resources to support something bigger. Also, I'm not suggesting there is anything wrong with doing RnD for a huge terrain engine if that's what you want to do and you have the time and resources to do it. I just think the whole idea of huge massive terrains are not practical and opens up a huge can of worms from a technology, development, and game play point of view. The same thing goes for players modifying the terrain while other people are trying to play, interesting in theory, bad idea in terms of implementation. The last thing you want to have to deal with is players mucking with terrain and then having to bring the server down because something stupid happened.

    Bottom line for me is that when I log into a game I want to immediately play. I don't want to have to spend hours walking places. If that was fun than no one would buy mounts in WoW. People hate long travel times in games.

  5. #35
    Join Date
    Nov 2009
    Location
    Dallas, Texas
    Posts
    170
    I was just thinking about huge worlds and players editing terrain and minecraft came to mind. Is there some minecraft influence going on here? If so, this would explains alot

  6. #36
    Join Date
    Oct 2006
    Posts
    45
    JJ, what do you think about an swg style shuttle service, combined with mounts to traverse smaller distances. What if the max distance between "stuff to do" was an hours run? It's probably important to view this in terms of time as well as distance. If I can jump on a shuttle to go between major centers, that departs at 10min intervals, and a mount that goes 2x running speed, I'm set.

  7. #37
    Join Date
    Jan 2010
    Location
    Buenos Aires, Argentina
    Posts
    148
    Quote Originally Posted by jjguzzardo View Post
    Finally! Yes, that's what i've been trying to say! Start with something managable and then see if you even need to spend all that time and resources to support something bigger. Also, I'm not suggesting there is anything wrong with doing RnD for a huge terrain engine if that's what you want to do and you have the time and resources to do it. I just think the whole idea of huge massive terrains are not practical and opens up a huge can of worms from a technology, development, and game play point of view. The same thing goes for players modifying the terrain while other people are trying to play, interesting in theory, bad idea in terms of implementation. The last thing you want to have to deal with is players mucking with terrain and then having to bring the server down because something stupid happened.

    Bottom line for me is that when I log into a game I want to immediately play. I don't want to have to spend hours walking places. If that was fun than no one would buy mounts in WoW. People hate long travel times in games.
    Well then I have misunderstood you.
    I though that you didn't want the terrain system to be built around the patches being streamed by the server and that you were looking for a standard fixed heightmap on the client solution.

    If that is the case forgive me. English is not my first language and sometimes I misinterpret stuff because of this.

    And JJ again thanks for the field experience you are sharing with us!

  8. #38
    Join Date
    Nov 2009
    Location
    Dallas, Texas
    Posts
    170
    system to be built around the patches being streamed by the server and that you were looking for a standard fixed heightmap on the client solution.
    Well I still don't agree with this part. Most zones in WoW are hundreds of megabytes so you could feasibly have a game 2 maybe 3 times the size of wow and still stream in fbx files off of disk. The only reason you would need to stream in verts from a server is if you wanted players editing terrain in realtime while the game is live, which I think is a terrible idea and just opens up all kinds of security holes, maintenance, and game play issues. It feels like there might be some minecraft inspiration going on here. Minecraft is an anomoly or an exception to the rule and there is no game play in minecraft at all. Minecraft is more of an online activity than anything else. You make stuff and dig, etc but there's no core game loop anywhere. So when I say start out small and grow, I mean using traditional methods, because even with traditional methods you could still get a world 2x or 3x the size of wow and that is more than you will ever need.

    The reason games start with a core game loop and build from there to a final release is because one of the most important things in a game is to get the core game loop in a play testable state so you can iterate on it until you get it right. You don't want to spend years building all this tech and then start play testing only to find out your game isn't fun and you need to throw out or rework years of tech. That's why the designers are so important because they keep programmers focused on the core game loop instead of cool tech. Don't get me wrong there's a place for cool tech but it should be realisticly viable and fit in with the core design. When I'm given a task, like a combat system. Something like that might take months to get right but I'm usually only given a week or less to get some out that's a horrible hack but at least playable so the designers can determine if it's fun. If it is fun then i'm given more time to "polish" it. If it's not fun then they tweak the design or throw the whole thing out and start over. So honestly, you only need Unity terrain or a flat plane to figure that part out.

    So I guess we finally agree on starting small and scaling out but still disagree on approach. A world 3x the size of wow or less is more terrain than you will ever need for a game.

    JJ, what do you think about an swg style shuttle service, combined with mounts to traverse smaller distances. What if the max distance between "stuff to do" was an hours run? It's probably important to view this in terms of time as well as distance. If I can jump on a shuttle to go between major centers, that departs at 10min intervals, and a mount that goes 2x running speed, I'm set.
    Ya, I love that idea. An hour is of running is fine as long as there are some fast travel options you can earn later to make things shorter. The bottom line is that when I'm on the ground questing or running around, do I need terrabytes of terrain around me? No. So making the playable world smaller and then using smoke and mirrors to make the world look huge when you get into a spaceship makes the most sense. People that say they don't like smoke and mirrors being used in games must not like games at all because that's all games are. Jumping in the air doesn't use real physics, lighting doesn't use real ray tracing, and scales larger than the planet earth are usually faked as well. Everything about games is faked and the most well respected game developers are those who creating masterful illusions using smoke and mirrors.

    Anyway, I think what you're suggesting makes the most sense. Again, i'm not saying make the world small. I'm just saying the size of terrain we're discussing as a potential option falls way outside the scope of what's practical in terms of game play and becomes more of an excercise in how cool can we make our tech.
    Last edited by jjguzzardo; 05-05-2011 at 12:30 PM.

  9. #39
    Join Date
    Jul 2002
    Location
    In space
    Posts
    5,428
    Quote Originally Posted by jjguzzardo View Post
    The reason games start with a core game loop and build from there to a final release is because one of the most important things in a game is to get the core game loop in a play testable state so you can iterate on it until you get it right. You don't want to spend years building all this tech and then start play testing only to find out your game isn't fun and you need to throw out or rework years of tech. That's why the designers are so important because they keep programmers focused on the core game loop instead of cool tech. Don't get me wrong there's a place for cool tech but it should be realisticly viable and fit in with the core design. When I'm given a task, like a combat system. Something like that might take months to get right but I'm usually only given a week or less to get some out that's a horrible hack but at least playable so the designers can determine if it's fun. If it is fun then i'm given more time to "polish" it. If it's not fun then they tweak the design or throw the whole thing out and start over. So honestly, you only need Unity terrain or a flat plane to figure that part out.
    Unity terrain was failing us for a variety of reasons. We needed something of our own and we decided to push it to see if we could make it support a large world. Something in which if we wanted to populate the playing world with relatively fast forms of air travel, it would feel a large enough to remain interesting. And yes, we - as a group (yes, the folks over here at 3D Buzz) - are excited about the idea of developing a terrain system that has the power and potential to smoothly be bigger than you'd ever need to it be while offering real-time group based editing power.

    So that's what we decided to do. Why? Because it's interesting, there's a lot to be learned from it, and most importantly, because we can. We're an education firm, so we can get away with it.

    I could have sworn we went on record from the very start saying that we were not a production studio. We said from Day 1 in the intro video (you did watch this?) and said that we were not looking for folks to start comparing this to a professional production line. It's pointless; plus if you look at the resources, the key one being human resources, the comparison is silly to the point of delirium.

    Let me break it down: If we were looking for a production schedule, we would:
    1. Certainly not be making training videos. It just slows production and if the end result is to ship a game, then slowing down to this degree for the sake a of a few hundred curious fans versus potentially thousands of eager gamers would be insane.

    2. Shut down 3D Buzz. You guys are great, but it takes too much time to keep you all happy and re-explain things multiple times.

    3. Start up a new company with a business model and some investors. We'd probably use our string of contacts in the games industry to put us in touch with the right people. This would also very likely require a design doc for the game. A real one.

    4. Hire a team. Lee's great. So's Jason. I'm just all right, but I'm not
    doing the code just now. And Nelson... he's Nelson. So yeah, we'd need more hands.

    5. Draft up an agile development schedule with regular releases. We'd have to break the team up into groups working on different things.

    6. Develop a string of in-house releases that could be tested out on a regular basis.

    We're not doing any of this. We said from the get go that we wanted to create a massive world, and that we were going to be handling this in a way that suited our desires. We also said (I know we said this) that we really did not want folks to start scrutinizing this from a, "Well, in my studio we would never blah blah blah" perspective.

    Of course you wouldn't. If you ran a business that was trying to ship a game in a reasonable studio-level time frame while trying to maintain a company like 3D Buzz with only 3 people, I would hope that your shareholders had the sanity and foresight to either fire you or sue you to the far side of oblivion for throwing due diligence to the wind and being careless with their money.

    And no, I can't imagine it being a smart idea to let folks edit terrain whilst the game is running and everyone's playing. This would be something done with a standalone toolset off-server. Your little zone would get submitted for approval (yes, we want to make sure you didn't model a giant vagina with a castle located at the clitoris) and then your content would get pushed based on some kind of established server update schedule. I'm not even key to the development and even I can see that this is one of the only sane ways to do this.

    Okay, I know you're trying to help, but here' the bottom line, and I'm going to print this big so you understand my emphasis:

    We know (Scout's honor) that the way we are doing things in this class will not coincide very well with an honest-to-goodness game studio. If you are somehow surprised by this, then you either were not paying very good attention too what we said at the beginning of this class (or it slipped your mind), or you have completely forgotten what 3D Buzz is.

    Anywho, I hope that settles a thing or two. Trust me, we're well aware of how things "should" be done, but we're also aware that there are certain challenges we have the freedom to overcome that a regular studio would just have to shrug, accepting the "status quo" answer that Problem-X cannot be solved because it does not fit well with a production environment.

    It works out great with our production environment. Way to go 3D Buzz! One of the many reasons why it's good to be us!

    So, please, enough of the "you'd never do this in a real studio" or similar comparisons, suggestions, themed posts, etc. It is already well known that a real studio wouldn't be doing 90% of the stuff we're doing.

    But seriously, thanks (and I mean it). I know your heart's in the right place, but I have to bring your head back around to where we needed it when we got started in this class. I realize I got pretty passionate here (I do this), but a lot of these arguments contain the underlying theme of exactly what we wanted to avoid.

    Love,

    Zak



    PS - And speaking purely as a gamer, I'd hate to think that the sweeping mindset of the industry is that we're just never going to see truly massive worlds. I do understand production bandwidth the problem of assets, etc. Really, I do. But it's another thing I'd like to see get overcome. WoW's world feels small by the time you can travel at 350 speed on your mount. Even more so now that you can fly in the classic lands. And 350 in WoW is still slow for flying. They keep it that slow to compensate for the (relatively) tiny world.

    And since we're on the topic, if you want to talk about what players want, players don't want to travel at all. Look at WoW. Really. Go play it. Right now. The world is pretty much empty, outside of the major cities where people mill around waiting to get into a dungeon queue. People log in, jump into a raid or dungeon, and log out. I used to live on a very violent PvP server and now I practically never get ganked. So if we were really just focused on what players seem to want, the game would consist of a lobby that allowed you to choose a dungeon with some friends and just go from there. It'd be about as "massively multiplayer" as Unreal Tournament.

    Actually, that game would probably be wildly successful.

  10. #40
    Join Date
    Jan 2010
    Location
    Buenos Aires, Argentina
    Posts
    148
    Quote Originally Posted by Zak View Post
    So if we were really just focused on what players seem to want, the game would consist of a lobby that allowed you to choose a dungeon with some friends and just go from there. It'd be about as "massively multiplayer" as Unreal Tournament.

    Actually, that game would probably be wildly successful.
    Well we could make a whole planet or moon a dungeon and still make them walk :P but they will probably need a clan size party and some months to pull it off

Page 4 of 5 FirstFirst ... 2345 LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •