Welcome, Guest. Please login or register.
March 28, 2024, 03:56:36 AM

Login with username, password and session length

Search:     Advanced search
we're back, baby
*
Home Help Search Login Register
f13.net  |  f13.net General Forums  |  The Gaming Graveyard  |  Game Design/Development  |  Topic: Time vs Money Management. Question Regarding Game Engines. 0 Members and 1 Guest are viewing this topic.
Pages: [1] Go Down Print
Author Topic: Time vs Money Management. Question Regarding Game Engines.  (Read 13745 times)
mutantmagnet
Guest


Email
on: July 14, 2008, 12:17:54 AM

I've been thinking of what takes to make an mmo again and I'm starting to get more serious about crunching the man hours and capitol investment involved to get a decent project going.

My biggest beef right now is that for the people I would think about hiring as a core group and handle the following tasks:

world builder engine, AI engine, network infrastructure, compiler/virtual machine design, 3d interpretation of 2d art assets, physics engine, animation applications, bug/reporting and data testing framework.

I'm left thinking with all these tasks needed to be done, the core group could make the game engine on their own since they already have to make the individual pieces and with the cooridination of competent and knowledgebale lead could follow a guideline that allows the pieces to fit together.


From your own experiences at what point should one be able to realize their team is cohesize and capable enough in creating their own engine and are better off continueing with doing that instead of sinking 3/4 of a million dollars just to try out a premade engine?


How much time can reasonably go by without sinking money that type of money into a powerful engine just to see if the core team is good enough at making one on their own?
« Last Edit: July 14, 2008, 03:39:56 AM by schild »
Morat20
Terracotta Army
Posts: 18529


Reply #1 on: July 14, 2008, 12:12:03 PM

I don't see DBA/DB designer under there, although possibly you have it mentally filed under something else.

You're also not factoring in various other costs -- if you want to futz around with a "build your own", you still have to invest in things like hardware, development enviroments, and things like high-end databases.
Salamok
Terracotta Army
Posts: 2803


Reply #2 on: July 14, 2008, 12:40:12 PM

Margalis
Terracotta Army
Posts: 12335


Reply #3 on: July 14, 2008, 03:02:50 PM

If you have to ask whether your team can do it then they can't.

vampirehipi23: I would enjoy a book written by a monkey and turned into a movie rather than this.
mutantmagnet
Guest


Email
Reply #4 on: July 14, 2008, 04:01:02 PM

I wasn't really asking so much about whether your team can do it but rather more like when does it appear like the work you are doing makes the purchase of an engine redundant.

Though, Salamok's link gave me the reminder I needed in ensuring how a project needs to be developed, so further advice isn't as neccessary.
MahrinSkel
Terracotta Army
Posts: 10857

When she crossed over, she was just a ship. But when she came back... she was bullshit!


Reply #5 on: July 14, 2008, 05:39:41 PM

If you roll your own engine, it might suck.  If you license it, you can be sure that it will suck, but in predictable ways you can design around from the beginning.  If you build it, you can specify what capabilities you want, but you can't be sure you'll get them.  If you buy it, you may be able to extend it (or leverage someone else's extension with an add-on, ala SpeedTree).

The problem is that there are a lot of things that are expected as standards in graphics that are tangential or even irrelevant to making a game.  The days when whiz-bang graphics technology can carry a game by itself are long gone, and the chances that you can hire talent that can beat Carmack and company at their own specialty are low.  It may cost a lot of money to license a top-quality engine, but just in sheer man-hours the cost of building your own that can meet the same standard isn't much lower, and it adds a whole bunch of "unknowable unknowns" to your project.  How will your texturing work?  With a licensed engine you know, with a home-grown you're guessing.  If you guess wrong, significant parts of your art manhours are going to have been wasted, alternatively you could wind up with mis-matched assets because a "maybe" capability was added midway through and there wasn't time to retrofit old assets.

If you are okay with a "pre-production" phase of a couple of years while the designers work with boxes labelled "monster" and "gun", your engine programmers fill out the capabilities of their code, and you don't hire artists until you have a fixed plan for what they will build and how, it could work.  Or if you already have a code-base for a respectable engine that just needs extension.  But if you're building from scratch, bite the bullet and buy the graphics engine.

--Dave

--Signature Unclear
Stephen Zepp
Developers
Posts: 1635

InstantAction


WWW
Reply #6 on: July 14, 2008, 11:33:09 PM

I've been thinking of what takes to make an mmo again and I'm starting to get more serious about crunching the man hours and capitol investment involved to get a decent project going.

My biggest beef right now is that for the people I would think about hiring as a core group and handle the following tasks:

world builder engine, AI engine, network infrastructure, compiler/virtual machine design, 3d interpretation of 2d art assets, physics engine, animation applications, bug/reporting and data testing framework.

I'm left thinking with all these tasks needed to be done, the core group could make the game engine on their own since they already have to make the individual pieces and with the cooridination of competent and knowledgebale lead could follow a guideline that allows the pieces to fit together.


From your own experiences at what point should one be able to realize their team is cohesize and capable enough in creating their own engine and are better off continueing with doing that instead of sinking 3/4 of a million dollars just to try out a premade engine?


How much time can reasonably go by without sinking money that type of money into a powerful engine just to see if the core team is good enough at making one on their own?

Some fundamental design/concept flaws here, mostly related to the true purpose of an engine, as opposed to a "make my game product". You're on the right track with some things (unlike many others at your stage), but only a few of the things you mention in your list are what an engine should be selected for.

Here's what's in your list that shouldn't even be considered when selecting an engine (as opposed to a make my game product):

--world builder engine

--Without you being very specific it's hard to outline much, but the "better" (more feature filled, more finely grained, etc) a world builder is, the more restrictive it is. You are guaranteed your tools team will have to make custom tools for your project--so instead of spending millions of dollars for an engine that does everything you want, simply plan on and budget for tools development on your framework of choice.

What that implies is that you don't care what current feature set a given engine has--you care about how extensible and maintainable it is.

--AI engine

Worst possible thing you can use to determine the quality of your game engine. Again, falls into that area of "what should a game engine do for me" confusion, but AI is not something that should be used to determine the value of an engine when you already know you will need to perform custom development.

If you need complex, performant, and extensible AI, then you will either be writing it yourself (commonly a wise choice), or integrating 3rd party AI solutions--AI Implant rings a bell, as well as many other AI focused libs and frameworks.

--network infrastructure

Definitely something a game engine should provide for you, and good that it's on you list (it commonly isn't). However, you need to realize that unless you are purchasing a total MMO solution (which are few and far in between), game engines commonly deal with world state data from a server to a client, not back end server architecture designed for CS, scalability, load balancing, account management, and hundreds of other tasks a back end architecture requires. There are solutions out there for this side of the architecture equation, but they also should be considered separately from your engine selection.

--compiler/virtual machine design

Yes--critical design choice for a game engine, although you aren't particularly specific on what you mean. What's critical here is the ability to have some form of implementation mechanism for design that doesn't require C++ and recompiling your entire project to change a typo in a text string--in other words, some form of a scripting language.

--3d interpretation of 2d art assets

This has nothing to do with a game engine's selection criteria--and in fact, I have no real idea what you mean--but I can just about guarantee there won't be a previously implemented solution "out of the box" in any engine. In any case, certainly not something to use as a selection criteria, although the ability to implement this would of course be an important selection criteria.

Postus Interruptus: Just realized this post is already way to long, so let me list briefly what should be on your engine criteria list:

--source code access : obviously biased here, but you absolutely do not want to tie your team to waiting for the engine developers to fix things for you. If the engine doesn't do something you need, you absolutely need to be able to fix it.

--cross platform/platform portability: again, critical unless you can guarantee from the beginning you will only ever support one platform. For example, even though GG's current top end engine doesn't have a Mac platform layer publicly available, the entire engine, from networking to rendering, is built from the ground up to allow one. Even if GG never produces a Mac platform layer (totally hypothetical scenario there), if you needed to, you could.

--abstracted systems: you mention "physics engine" as well as "AI engine"--but instead of trying to find a game engine with everything you need, you should instead focus on finding one that allows you to integrate what you need--and that implies abstracted systems.

Trying to keep this "marketing negative", but this is one of the areas Torque has failed in in the past, and one we are absolutely fixing in our current R&D. Physics, Rendering, Networking, AI, Platform, Scripting Language(s), the works--all systems are abstracted, and user configurable so you can select the systems solutions you need for your project, instead of being tied in to a design/implementation choice made be someone else.

There are many more selection criteria that should be used for selecting an engine, but that's a good start. What's important to understand here is that no engine will ever meet all your needs...and since you can assume from the start that you will have to be developing your own systems and adjusting existing ones, your engine selection choice must be made with custom implementation in mind.

Rumors of War
Margalis
Terracotta Army
Posts: 12335


Reply #7 on: July 15, 2008, 06:48:40 AM

To echo Zepp a bit the number 1 thing I'm looking for in a engine is overall code quality, because I know I'm going to be making major changes.

Right now if you are looking for something off-the-shelf you can either get an engine very specialized to FPS games, which means a lot of changes if you want to do anything else, or you can get a more general engine and then have to implement your own tools, culling schemes, AI, etc etc.

vampirehipi23: I would enjoy a book written by a monkey and turned into a movie rather than this.
MahrinSkel
Terracotta Army
Posts: 10857

When she crossed over, she was just a ship. But when she came back... she was bullshit!


Reply #8 on: July 15, 2008, 10:20:45 AM

Since Stephen doesn't want to pimp his engine, I'll do it for him: Torque is not a bad engine at all, and the cost of it is pretty low, comparatively.  I had some issues with it, but nothing that couldn't have been fixed with more manpower (one or two graphics specialists would have done it).  The network layer, especially, was much better than I've typically seen in licensed engines.  It's also better at interior/exterior portaling than just about anything else on the market.

The built-in content tools, not so great.  But from the way you're talking, you plan on rolling your own anyway (and you would need to almost regardless).  An MMO environment would require some major changes to the terrain system, anyway.  The only "MMO in a box" toolset I'd give even a conditional nod to is Big World.

--Dave

--Signature Unclear
Lantyssa
Terracotta Army
Posts: 20848


Reply #9 on: July 15, 2008, 10:51:38 AM

The built-in content tools, not so great.  But from the way you're talking, you plan on rolling your own anyway (and you would need to almost regardless).  An MMO environment would require some major changes to the terrain system, anyway.  The only "MMO in a box" toolset I'd give even a conditional nod to is Big World.

--Dave
Out of pure curiosity, have you seen enough of the HeroEngine to exclude it from your conditional nod?

Hahahaha!  I'm really good at this!
MahrinSkel
Terracotta Army
Posts: 10857

When she crossed over, she was just a ship. But when she came back... she was bullshit!


Reply #10 on: July 15, 2008, 11:12:44 AM

Out of pure curiosity, have you seen enough of the HeroEngine to exclude it from your conditional nod?
I haven't seen enough of it, or talked to anyone who has worked with it.  On paper, it looks comparable to Big World, but I'd want to talk to a programmer who had wrestled with it before I had a firm opinion.

--Dave

--Signature Unclear
Lantyssa
Terracotta Army
Posts: 20848


Reply #11 on: July 15, 2008, 01:14:53 PM

'kay, thank you.

Hahahaha!  I'm really good at this!
mutantmagnet
Guest


Email
Reply #12 on: July 15, 2008, 01:48:45 PM

  But from the way you're talking, you plan on rolling your own anyway (and you would need to almost regardless).  An MMO environment would require some major changes to the terrain system, anyway. 
--Dave

Well I have some ideas about what I don't need from a prebuilt engine but it doesn't hurt to shop around and posssibly save time in place of money. Everyone here has offered valuable information and I thank you for it.
Stephen Zepp
Developers
Posts: 1635

InstantAction


WWW
Reply #13 on: July 15, 2008, 02:05:36 PM

Thanks for the props...I really do try to stay agnostic when talking about engines in a general sense.

Interesting however that Mahrin (as a programmer iirc) sees strengths in Torque that others (designers/artists) see as weaknesses :)

--interior/exterior portalization: I agree with you, when used properly, Torque's portalization is outstanding. Unfortunately, it comes at a great sacrifice to artist flexibility--you must use CSG (brush based) art techniques for it to work, which can cause many frustrations for all involved. We're actually moving away from the .dif file format (very similar to .map geometries) to a full poly soup format for future tech.

--networking: yep, again, when taken with the design requirements it's built around, it's outstanding. However, the reverse side of the equation is the severely intensive physics requirements per object--every class must implement it's own physics, and there is no general world solution for anything. Trading power for flexibility of course.

--world building (and gui building): no arguments there at all--Torque's hasn't been touched really in 5 years. Next generation tech (in R&D atm) is however getting a ground up re-write :)

Some areas that rarely get mentioned when selecting engines, but are actually some of the most critical in my opinion:

Object management: how does the engine instantiate, manage, facilitate communication between, and housekeep objects? These can be huge bottlenecks in any game, but are critical in MMO's.

Event management: does the engine provide for easily extensible events, from cross platform OS events, to networked events, to external application events?

Resource (asset) management: how does the engine instantiate and replicate (when necessary) resources loaded from disk? If you have 100 orcs in your scene, and each one has an exact copy of the same texture and geometry data, you've already lost. Most engines do this well by now, but it's not a guarantee.

I admit I have a semi-rare point of view, but in my eyes, a game engine should be responsible for the things you don't care about when designing your game--your implementation on top of a game engine should be able to build upon a 100% solid and reliable foundation the game engine provides. Anything your selected engine happens to do well that's related to your game mechanics/game play is gravy--and is going to need a lot of salt and pepper to taste anyway.

Rumors of War
MahrinSkel
Terracotta Army
Posts: 10857

When she crossed over, she was just a ship. But when she came back... she was bullshit!


Reply #14 on: July 15, 2008, 04:52:31 PM

I'm actually a former programmer (of business systems, not games) turned game designer.  I'm a *competent* programmer, and I've done it in the last few years for experiments and datamining, but I'm not nearly disciplined enough in my coding practices to be allowed near production code.  It helps me understand what the programmers are telling me about tech limitations and design around it.

--Dave

--Signature Unclear
Mrbloodworth
Terracotta Army
Posts: 15148


Reply #15 on: July 16, 2008, 10:14:27 AM

Hero engine is the bees knees.

Today's How-To: Scrambling a Thread to the Point of Incoherence in Only One Post with MrBloodworth . - schild
www.mrbloodworthproductions.com  www.amuletsbymerlin.com
Zhiroc
Terracotta Army
Posts: 16


Reply #16 on: July 16, 2008, 08:09:29 PM

I hardly ever post here, and I have zero experience in designing a game.... but it seems to me what most games lack is a serious answer to the question: What makes playing this game fun?

The rest to me is just engineering. Have a game in search of a engine, rather than an engine in search of a game....
photek
Terracotta Army
Posts: 618


Reply #17 on: July 18, 2008, 01:24:40 PM

Been checking out the Hero Engine and the biggest issue is the pricing models they offer. Unless you are KnownDevTeam with sponsors and publisher I think you can safely look away from it. As somebody up there said, TGEA is a decent engine. I've worked with it the last year and we have made tons of gameplay prototypes and systems in short time. Torsion is very efficient once your programmer gets used to it, which should be done in no time for a competent one.

Regarding its strengths vs weaknesses, me as mostly artist agree on Stephen Zepps weakness comment, there are many things I wish Torque did better and some of them are hardcoded. Polysoup in last patch definitely helped a little on what I'm talking about. Also I'm assuming that you are an indie game dev, my question out there is why everyone wants to do MMOs nowadays. It's not like the quantity of delivered MMOs the last years is so high that nothing else is even remotely attractive. It's rather the contradictory. You have probably heard this before one thousand times, and don't be narcissistic when I say it, I'm saying it for you to save time, headaches and preserve mentality : Don't start an MMO. Particularly one with an internal engine from scratch. One reason for it you will most likely never finish it and as the article up there showed so perfectly (the one building a framework), it will take months or years before seeing results. I'd daresay 97% of indie devs get hugely demotivated and lose their track far before shinies appear.

Rather start something that is completeable, a smallER project where results are within reach. This is a massive boost factor to any dev team, seeing completed stuff will motivate your entire force further to keep moving forward. Also, make games, don't make engines. If you insist on making an MMO, I wish you luck.
« Last Edit: July 18, 2008, 01:27:05 PM by photek »

"I recently went to a new doctor and noticed he was located in something called the Professional Building. I felt better right away"
photek
Terracotta Army
Posts: 618


Reply #18 on: July 18, 2008, 01:26:32 PM

I hardly ever post here, and I have zero experience in designing a game.... but it seems to me what most games lack is a serious answer to the question: What makes playing this game fun?

The rest to me is just engineering. Have a game in search of a engine, rather than an engine in search of a game....

As zero experience as you think you might have, I'll say to you : You have the basic knowledge many devs and designers lack nowadays (bolded parts in quote). These are fundamentals people seem to avoid, forget or completely lack.

"I recently went to a new doctor and noticed he was located in something called the Professional Building. I felt better right away"
mutantmagnet
Guest


Email
Reply #19 on: July 18, 2008, 07:32:59 PM

I'm just posting a link to an insightful article on time management and a link to the blog that made me aware of the first link and offers some extra insight.


Quote
One reason for it you will most likely never finish it and as the article up there showed so perfectly (the one building a framework), it will take months or years before seeing results. I'd daresay 97% of indie devs get hugely demotivated and lose their track far before shinies appear.

Rather start something that is completeable, a smallER project where results are within reach. This is a massive boost factor to any dev team, seeing completed stuff will motivate your entire force further to keep moving forward. Also, make games, don't make engines. If you insist on making an MMO, I wish you luck.

A conservative style of advice but one I couldn't endorse entirely. You have to know the details of a project before offering that type of advice because it might already take a very conservative approach to game design, even if it is going to be a large project.
« Last Edit: July 18, 2008, 08:01:43 PM by mutantmagnet »
photek
Terracotta Army
Posts: 618


Reply #20 on: July 18, 2008, 09:26:34 PM

To your original, once more :

Quote
How much time can reasonably go by without sinking money that type of money into a powerful engine just to see if the core team is good enough at making one on their own?

There is little I need to know after you're telling me you wish to build a game engine, it will take months or twelve to see results, depending on dev team, and the first results you will see will be a bunch of text. The dev team you have chosen lacks several key features, some mentioned above, also some important are tool builders, which is a biggie in an MMO. If you are a designer with little knowledge of programming and this is one of your first projects, you are ultimately going to feel like you are stalling throughout this process and money are going down the sink. Ow and yeah, with results I don't mean and spinning lighted cube with checker map, I'm talking about working and functionable features.

Also it has nothing to do with conservative game design. Your game design could be extraordinary and spectacular and still doable with a limited budget, its more about the amount of content and depth you plan to implement and where your results are oriented. Do you do this to make profit ? Free to play, but advertisements ? Just to show you what I'm talking about, right now, at least, half this board won't pay for Age of Conan monthly due to it's current nature. On the other hand this board is not the perfect representation of the average MMO gamer, but it should give you a perfect insight why MMO games fail to deliver. We have become one needy and greedy bunch, for perfect reasons if you ask me. "When it comes to MMO's, the glass might be half full, but its full of urine" I believe someone has in their sig, which is spot on. Noone is paying for "meh" and low-budget MMO's aren't bags of gold. Only way you could make it work was directing it at a special audience, like kids. However regarding bags of gold, a very good and innovative low-budget game can be just that.

EDIT : Regarding Game Design, I'm wondering how you are going to prototype your stuff. I hope you dont expect everything you have written to be perfect in nature and prototyping should be a requirement for key assets. What I like to do is build a playable version of something like the combat system and test it to death and iterate it to perfection. If my combat system sucks, back to drawing board. This is where picking a game engine is far better, it allows you to try before green-lighting big financial choices.
« Last Edit: July 18, 2008, 09:31:23 PM by photek »

"I recently went to a new doctor and noticed he was located in something called the Professional Building. I felt better right away"
MikeRozak
Terracotta Army
Posts: 23


WWW
Reply #21 on: July 19, 2008, 01:11:28 AM

From your own experiences at what point should one be able to realize their team is cohesize and capable enough in creating their own engine and are better off continueing with doing that instead of sinking 3/4 of a million dollars just to try out a premade engine?


How much time can reasonably go by without sinking money that type of money into a powerful engine just to see if the core team is good enough at making one on their own?

I'm working on my own engine now... but it's half way between a MUD/IF and a MMORPG. It's a LOT of work, even with the minimal eye candy. Creating a full MMO engine is even more work. As is typical with any software project, take your guestimated amount of work and double that. And, assuming that you haven't written an engine before, double that again. And since your engine will take 4 years to write (I'm only exaggerating slightly, or maybe not at all...), and technology will have advanced since you started, you'll need to add another year to update your engine to new technology once you think you've finished it.

Team is cohesive/capable - You might try the following strategy. Spend (approx) $100 and get something like NWN2 or RealmCrafter and put a small world togther (10-20 hours of content). Think of it as a prototype. Once you've done that, then decide if you want to pay for a real engine, or give up the project.


mutantmagnet
Guest


Email
Reply #22 on: July 19, 2008, 08:38:38 AM

To your original, once more :

Quote
How much time can reasonably go by without sinking money that type of money into a powerful engine just to see if the core team is good enough at making one on their own?

There is little I need to know after you're telling me you wish to build a game engine,

I have to try again at killing this misperception. I don't want to make a game engine if I don't have to. When I was planning out what needs to be done I was left with the question of where the line exists between making an engine and making so many custom pieces because whatever I buy can't meet my specifications.

That is why the title is partially phrased time management vs money management. I want to avoid any mistakes early on in buying an engine and then doing a bunch of work that amounts to making an engine from scratch.

I'm already beginning to draw where the line has to exist.

FYI it is important to know a plan in full before critcizing it. Remeber how I never adressed why I didn't mention a DBA manager? I never mentioned that because I'm breaking down the team into the most essential components with the least amount of money needed. DBA manager would have to come in as part of the second team that has to be hired if I can get more capitol afterwards.

My plan has weaknesses but I have to think about things in a budgeted manner or else why bother planning at all? One can shoot for the stars but they should minimize the chances of shooting themselves in the face to do it.

Quote
Team is cohesive/capable - You might try the following strategy. Spend (approx) $100 and get something like NWN2 or RealmCrafter and put a small world togther (10-20 hours of content). Think of it as a prototype. Once you've done that, then decide if you want to pay for a real engine, or give up the project.

I would still have to look at what these specific engines do but the general advice is sound on prototyping on something cheaper. It would help people figure out if they can work as a team on the short term.
« Last Edit: July 19, 2008, 08:50:52 AM by mutantmagnet »
Lantyssa
Terracotta Army
Posts: 20848


Reply #23 on: July 19, 2008, 09:11:20 AM

FYI it is important to know a plan in full before critcizing it. Remeber how I never adressed why I didn't mention a DBA manager? I never mentioned that because I'm breaking down the team into the most essential components with the least amount of money needed. DBA manager would have to come in as part of the second team that has to be hired if I can get more capitol afterwards.
I would recommend against making this second string.  If your database isn't top-notch, your entire product is annoying, if not worthless, due to delays in seconds with every transaction.  You may be able to consolidate positions based on the experience of your people and just how much database access you need, but don't skimp here.

Hahahaha!  I'm really good at this!
mutantmagnet
Guest


Email
Reply #24 on: July 19, 2008, 12:20:03 PM

I'm not skimping on DB because I don't see it as important, I'm skimping on it because I see it as something that can be put off for a few months. Everyone who has taken programming courses has had to learn the fundamentals of databases at one point or another and what I'm thinking of doing should have database requirments more like Planetside less like WoW.

In fact the most important reason I even decided I needed a DB expert eventually is that I don't know everything and it would be best to have some who really knows what they're doing and fix any misconceptions the team had in the first few months.
MahrinSkel
Terracotta Army
Posts: 10857

When she crossed over, she was just a ship. But when she came back... she was bullshit!


Reply #25 on: July 19, 2008, 12:27:32 PM

Make sure your programmers have some RDBMS experience, then, and encapsulate their read/writes so that even if they're using flatfiles or something equally quick and dirty, they can integrate with a DB system later.  Probably it would be best to use a database system from the beginning, simply because it will force them to write code that deals with those realities (collisions, hangs, delays, etc.).  They'll be *really* tempted to use the disk when they start running out of RAM, you need to make sure they don't.

--Dave

--Signature Unclear
Morat20
Terracotta Army
Posts: 18529


Reply #26 on: July 23, 2008, 08:17:37 AM

I'm not skimping on DB because I don't see it as important, I'm skimping on it because I see it as something that can be put off for a few months. Everyone who has taken programming courses has had to learn the fundamentals of databases at one point or another and what I'm thinking of doing should have database requirments more like Planetside less like WoW.
Hi, and welcome to "Big Mistakes You just Made". Joining us is Morat, whose DB experience is just sufficient for him to gape at the statement you just made and possibly want to die a bit inside.

First and foremost, you're running an MMORPG -- Planetside or not, you'll simply lack the cash to have a dedicated DB server for each "game" server -- meaning even if you have relatively low population realms (say, 500 or 600 max simuls) you'll be running upwards of 3k+ simulteanous users per DB server.

Surely, you say, any modern DB and decently powerful server can handle this -- especially given you're not trying to run EVE but something like Planetside.

Yes, you're absolutely right. It can! But only if your design schema is done by someone with more experience than "Databases 101" in college.

Fundamentals of databases teaches you shit. Oh goodie, you have programmers that have learned that Databases are slightly more powerful than Excel spreadsheets, can properly format a SQL call on the first (or maybe second try) and probably have some vague notions about 2nd and 3rd normal forms. That's NOT going to cut it. Not even remotely.

I will tell you the God's honest truth -- if you skimp on the DB design, or push it off until deeper into the development cycle, you have just shitcanned your project. You will, for as long as this thing sees the light of day, fight godawful lag and constant problems.

You're running an MMORPG -- your DB needs are going to be closer to "financial transactions" than "two-bit shit put together for a website". "Fundamentals of DB design" is "web-site" level. Worse yet, if your DB design isn't done from the git-go by someone skilled and involved in the process, then your programemrs -- whose knowledge of DB design is "I can make SQL call?" will do really stupid shit with it -- like, I dunno, tons of unneccesary full joins and other stupid mistakes that'll bring your DB to it's knees everytime someone loads into the world.

I'm nowhere NEAR skilled enough to do the kind of DB work you're speccing, and I've had a hell of lot more formal education and practical experience with DB design than "Shit you learn getting a BS in Computer Science". Admittedly, this particular issue is a bit of a hobby-horse for me -- mostly because I've seen the end result of exactly this attitude.

In short: Lag, lag, lag, lag, lag, lag, EXPLOIT, lag, EXPLOIT, lag......
mutantmagnet
Guest


Email
Reply #27 on: July 23, 2008, 09:55:36 AM

Fair enough. As I said before I don't know everything and try to plan with the best knowledge I have.
Salamok
Terracotta Army
Posts: 2803


Reply #28 on: July 23, 2008, 09:57:13 AM

I'd kind of aggree, seems like one of the last things to get developed should be the client siide stuff.  I don't think it is as overwhelmingly difficult to get it right as Morat is making it out to be but it is certainly very easy to get it wrong.  I also do have some experience with realtime data collection in the other gaming industry (ie vegas/player tracking/real time accounting stuff).

For example look at something like ACT, it's a database driven form based app designed for 1 to 20 users to network locally and yet somehow with the 15-20 year maturity of the product, the numerous rewrites and the semideep dev pockets they manage to produce something that takes hours to fart out a simple report covering a few thousand records.  The programmers writing their shit probably have the same basic understanding of databases that most programmers have.  They should release their code (feel free to pick any of the last 4 versions) to schools accross the US for use in Database 102 "how to fuck up your data scheme".  
Morat20
Terracotta Army
Posts: 18529


Reply #29 on: July 23, 2008, 10:21:14 AM

I'd kind of aggree, seems like one of the last things to get developed should be the client siide stuff.  I don't think it is as overwhelmingly difficult to get it right as Morat is making it out to be but it is certainly very easy to get it wrong.  I also do have some experience with realtime data collection in the other gaming industry (ie vegas/player tracking/real time accounting stuff).
I did overstate it a little, I admit.

But the thing with database design is...it's pretty easy to do the simple stuff, and that fools a lot of people into thinking the simple stuff is all it is and that it's all simple. But scaling it up to that level is a lot harder.

You can, with what a programmer who took an elective or two extra in database design, put together something that'll work for 40 or 50 users the way MMORPG users do it. But as you scale up, problems will start to snowball -- and they will be difficult to impossible to fix, because the problems are built into your very design.

In my experience, the last person you want designing your DB is one of your programmers. He or she will design the DB according to what's easist for them to use, which isn't what you need. "What's best from the coding perspective" isn't going to be best from the database or performance perspective.

There's several critical layers to any MMORPG, and the two that are shortchanged the most are netcode and database and information storage -- they're not sexy, they're not what gets eyeballs on the game. But get either of them wrong, and your gameplay goes out the window.
Salamok
Terracotta Army
Posts: 2803


Reply #30 on: July 23, 2008, 10:39:51 AM

Been 20 years since my last programming class, at that time database 101 was done from the most effecient way to store data perspective (as opposed to the most efficient way to retrieve or write data).  Not sure what they teach now but if I tried to code even a web database using those techniques I'd be screwed and my shit would perform like ACT.  From what I have seen, when speed is priority number 1 then normalized tables is the 1st thing to get the boot and normalized tables is basically database 101. 
Morat20
Terracotta Army
Posts: 18529


Reply #31 on: July 23, 2008, 12:09:23 PM

Been 20 years since my last programming class, at that time database 101 was done from the most effecient way to store data perspective (as opposed to the most efficient way to retrieve or write data).  Not sure what they teach now but if I tried to code even a web database using those techniques I'd be screwed and my shit would perform like ACT.  From what I have seen, when speed is priority number 1 then normalized tables is the 1st thing to get the boot and normalized tables is basically database 101. 
DB 101 --- the generally required DB class for computer science majors -- covers the bare bones of database design. It's quick and dirty. You learn the basics of key choice, the first three normal forms, and touch on relational algebra and calculus. Effectively, by the time you are done (assuming you paid attention to the class and digested the information correctly) you should be able to construct a 2nd or 3rd normal form DB, construct SQL queries to do practically anything possible, and have a semi-decent idea of how to construct an efficient query.

In the master's level equivilant -- or what you'd take if you had a solid DB focus and wanted more -- you learn the theory behind normal forms, how they relate to database and query efficiency, you learn a lot more about the math behind it, and start digging into details about how to do things like ensure table changes are lossless, deal with (and unwind) complicated SQL transactions, and learn about the other forms of DBs (like, say, OODBs). That's basic advanced DB class -- DB 201, so to speak. Most CS majors don't take it, and I don't even think it's generally required for a Master's (although I understand it's a common choice).

You also learn the basics of being a DBA -- like the various sorts of lockings and stuff that databases can apply (table locks, row locks, etc), how they unwind failed transactions, how they store data, and what the main players are good at -- and bad at.

For an MMORPG, the upfront design needs are far beyond what's covered in DB 101. You can't just pick a normal form -- you'll be creating a schema that's a hodgepodge of 2nd and 3rd, depending on whether you need to optimize a given area for speed or density. You have to be able to work with coders up front to determine what parts of your DB will be under constant load, which will be called less often -- and you need to be able to work out whether it's more efficient (speed wise) to drop down a normal form and bloat your DB or suffer through the joins. Not to mention coaching programmers into making effective calls, and the real DBA work of optimizing your setup so that data is precached effeciently and all that jazz.

I've seen how programmers work with DB 101 -- it's bloody awful. Not on the "it's not a pretty and elegant design" -- I mean performance, ease of use, the works. Half of them have forgotten all of DB 101 and basically create one giant spreadsheet (and swear it's faster, since they don't know a goddamn thing about how a DB accesses and caches it's own data) instead of proper tables, and the other half of the time it's a million damn tables with a million damn joins every freakin' call. And don't get me started on bloated columns because they couldn't recognize a proper key if they saw it, and their utter inability to properly handle foreign keys.

And to a real DBA, I'm a freakin' amateur who barely has more than DB 101. I run a piddling web front end an a DB with maybe a terabyte of data, and  peak of no more than 200 concurrent users. Which runs a lot better than it did, thank you very much, because I convinced a bunch of programmers to let me redesign their schema into something that actually fit their needs and was -- shocker -- extensible.
Salamok
Terracotta Army
Posts: 2803


Reply #32 on: July 23, 2008, 01:42:29 PM

well at peak we had 10's of thousands of writes per second going on (over 19200 speed proprietary network) and 1 place I worked solved it with custom hardware - scaled down boxes prepping data from small network segments (31 nodes) and feeding it to a btrieve database.  The other place dumped to flat file and had some apps running on OS2 that quickly converted the flat files to foxpro.  Of course this was back when database servers were mostly minicomputers or mainframes and neither solution was really geared towards the rapid 2 way flow of data as there wasn't near as much info flowing back to the nodes as there was coming from them. 

I'd say a MMOG is the exact opposite of what we did, you have more data flowing out in real time to each client than you have coming back in.
Morat20
Terracotta Army
Posts: 18529


Reply #33 on: July 24, 2008, 07:30:53 AM

I'd say a MMOG is the exact opposite of what we did, you have more data flowing out in real time to each client than you have coming back in.
I would think that with an MMORPG (well, EVE aside -- it has unique needs) is that if your DB folks and your coders work together from the beginning, you can squeeze a LOT of efficiency out of the whole process. I've seen how MMORPGs have tried to handle DB lag by staggering queries and trying to maximize efficiency after-the-fact.

It'd work a lot better if they designed their tables and SQL calls in concert, around projected lag points. You could very easily do pre-caching and stuff a lot more dynamically -- there's a great deal of predictability in DB loading for an MMORPG.
Krakrok
Terracotta Army
Posts: 2189


Reply #34 on: August 08, 2008, 09:04:10 PM

Pages: [1] Go Up Print 
f13.net  |  f13.net General Forums  |  The Gaming Graveyard  |  Game Design/Development  |  Topic: Time vs Money Management. Question Regarding Game Engines.  
Jump to:  

Powered by SMF 1.1.10 | SMF © 2006-2009, Simple Machines LLC