Coding an MMO

A place to discuss the implementation and style of computer programs.

Moderators: phlip, Moderators General, Prelates

Tyndmyr
Posts: 10170
Joined: Wed Jul 25, 2012 8:38 pm UTC

Coding an MMO

Postby Tyndmyr » Fri Oct 24, 2014 6:06 pm UTC

Now, a disclaimer...this is solely a ludicrous project for my personal entertainment. I am not making WoW here. God no. However, MMO architecture and design is interesting and not a little complex, and the design of it is an area with particularly little solid info. So, it's something I putter with now and again. Mostly, I learn from it, and realize that what I've done is all wrong, and I scrap it and start again. At that point now, and figured it might be interesting to chat about it with others. Or at least organize my thoughts more coherently than scribbles on notepaper, anyway.

I believe this time, I'm going to use a basic pattern of three databases, one that's user centric, one that's chat centric, and one that's char centric(ie, the important one for making most stuff actually tick). Not sure yet if I want to use some sort of messenging middleware or socket middleware, but if not, both of those are fairly straightforward areas to write, if tedious. Front end...ugh. Unity, I guess. I dislike the scripting language, but I can't find a java based engine I'm really happy with. jMonkey isn't real good about supporting things like holes in terrain. I *could* hack it, but then I get to deal with interactions with mipmapping, etc, and I suspect it would be really easy to get derailed on engine tweaks(as happened with Torque), and never really get around to building the thing I want to use the engine for. Kind of still undecided here, but in theory, I could use a really minimal test front-end while I design the back-end, and put this off significantly.

Server wise, in addition to the actual game server, I'll want a seperate chat server and login server(this is from an app perspective, databases may or may not be hosted on webservers for performance reasons). That's minimal, I think. I can justify splitting apart functionality all day, but pre-emptive optimization can cause massive scope creep, so that's probably enough. I spose I should start building linux boxes for a proper testbed instead of testing locally. That seems reasonable, and I do have tons of old machines in a pile.

I've already run through a number of the existing freebie/open source systems out there, and frankly, they all seem...halfassed is probably the best way to put it. Like, a really basic RPG server, but without significant thought put into scalability.

Anyway, that's enough rambling for now, I'll continue later, and I welcome the thoughts of others.

korona
Posts: 495
Joined: Sun Jul 04, 2010 8:40 pm UTC

Re: Coding an MMO

Postby korona » Sat Oct 25, 2014 11:13 am UTC

I would start with just one server for everything. That's easier to implement and it should not be too hard to transition to multiple servers if you have to. For scalability you probably want one server per zone with some central character management that is updated on each zone change (or every few minutes in case the zone server crashes).

Java and other garbage collected languages are not a great choice for games or other real-time applications. Their performance (= throughput) is quite good and comparable to that of C/C++ but the garbage collector can introduce long pauses. If your game runs at 30 FPS server-side you really cannot afford any pause longer than 33ms. I strongly suggest C++ for real-time applications.

I don't think that MMO programming is more difficult than programming other games. MMOs have obviously have to scale better than other games but they can avoid some very difficult problems other games face, e.g. physics simulation and interaction with the environment. But you probably should not start writing an MMO before having some experience in game programming because rewriting code every few weeks is very frustrating. I'd start with a simple single player RTS, RPG or FPS before moving to such a large project.

User avatar
You, sir, name?
Posts: 6974
Joined: Sun Apr 22, 2007 10:07 am UTC
Location: Chako Paul City
Contact:

Re: Coding an MMO

Postby You, sir, name? » Sat Oct 25, 2014 5:13 pm UTC

korona wrote:Java and other garbage collected languages are not a great choice for games or other real-time applications. Their performance (= throughput) is quite good and comparable to that of C/C++ but the garbage collector can introduce long pauses. If your game runs at 30 FPS server-side you really cannot afford any pause longer than 33ms. I strongly suggest C++ for real-time applications.


Well, it's certainly doable (I work for a company that develops just such deterministic-latency high-throughput Java applications). Although it does require writing somewhat non-idiomatic Java as well as fiddling with the JVM flags to get it right. Not that I disagree with your assessment that Java probably isn't ideal. When the choice is made to go with Java in these types of applications, the decision is usually driven by exceptionally high demands on fault tolerance.

Also, I don't think any MMO actually pushes full state synchronization at 30 FPS. Position tracking seems often to be a hidden best effort deal with heavy extrapolation (with the client in most cases telling the server where he is, rather than the other way around, rubberbanding occurs when the discrepancy gets unreasonably large), and actions/combat is anything but real-time. It's not uncommon to have input delay in the 500ms-range in MMOs.
I edit my posts a lot and sometimes the words wrong order words appear in sentences get messed up.

Tyndmyr
Posts: 10170
Joined: Wed Jul 25, 2012 8:38 pm UTC

Re: Coding an MMO

Postby Tyndmyr » Tue Oct 28, 2014 4:08 am UTC

korona wrote:I would start with just one server for everything. That's easier to implement and it should not be too hard to transition to multiple servers if you have to. For scalability you probably want one server per zone with some central character management that is updated on each zone change (or every few minutes in case the zone server crashes).


Oh, one server is fairly easy, to be sure...but the hard parts of MMOs mostly stem from the massive bit. Gotta break out login server because it provides a filter for noobs to spam, a way to filter unexpected load, all that jazz without impacting play. Anti-cheat concerns become a big deal. It's bad enough if cheating provides an advantage in a match, but if say, items can be duped...well, merely fixing the bug won't necessarily fix all the aftereffects.

And really, that's why it's a fun problem to consider. You actually have to care about a bunch of mostly theoretical stuff that doesn't come up in the vast majority of apps.

Java and other garbage collected languages are not a great choice for games or other real-time applications. Their performance (= throughput) is quite good and comparable to that of C/C++ but the garbage collector can introduce long pauses. If your game runs at 30 FPS server-side you really cannot afford any pause longer than 33ms. I strongly suggest C++ for real-time applications.


Well, client side, I'm not overly stressed about that. Even Jmonkey is easy enough to configure to run without any visual lag client side...any dedicated graphics engine should mostly be fine for MMO purposes as far as GC and so forth goes. The client shouldn't really be intense in that regard, generally MMOs are much less crazy than say, the new shooter or what not. The big thing is maturity. Jmonkey's lack of terrain features ends up being killer because, while you CAN work around it, there are either massive coding challenges to add the functionality or you make performance tradeoffs to work around them. Front end is really among the toughest decisions because there's just a ton of options, and graphics engines are usually the sort of thing you have to mess with a bit to get a feel for.

I don't think that MMO programming is more difficult than programming other games. MMOs have obviously have to scale better than other games but they can avoid some very difficult problems other games face, e.g. physics simulation and interaction with the environment. But you probably should not start writing an MMO before having some experience in game programming because rewriting code every few weeks is very frustrating. I'd start with a simple single player RTS, RPG or FPS before moving to such a large project.


Yes and no. Sure, you handle some stuff differently, but seriously, physics simulation is usually mostly a function of the engine unless you're doing something particularly wonky in most games. You still need to handle environmental interactions...just in a different way. The bits that are removed(player/player collision detection, for instance), generally are done so at least in part as a concession to efficiency. I do agree that, generally speaking, someone should write several games before moving onto such a large project, but I think that's BECAUSE in difficulty to code, MMOs tend to generally be particularly nuts.

As for languages, I'm not going to stress about that overly much. It's unlikely the whole ball of wax will be written in a single language anyway. I tend to pick java when I have no good reason not to go with something else, but meh. Each component has different constraints. A chat server, whatever. GC isn't a big deal there. But...that may not be an area worth coding custom. Could probably eke out some performance gains, but performance gains on world/zone chat are probably fairly trivial in the grand scheme of things, and localized comms probably needs to be handled as a zone action anyways.

Overall, I suspect that it basically has to start with a system diagram, a good definition of what each bit does, followed by database selection. Sheer volume of content and data is a significant aspect of MMOs, and determining exactly how to best handle that seems fairly critical. One would THINK that there'd be some good clues here in the database world, but seriously, almost every database system, no matter how obscure, seems to have been used. EVE runs on a bastardized MySQL(which seems...perhaps unwise). Everquest ran on flat files(which seems DEFINITELY unwise). My usual preference is postgres, but the only DB I've run on this scale is Oracle. I *think* it's safe to eliminate MySQL based on high locking requirements, but comparing databases is...complicated. Probably best to start with postgres on the basis of Oracle being generally expensive, if indecisive between the two, I guess, but I still feel like there's research to be done here.

Next, after that, I need at least a rough breakout of any database segregation happening. I feel like a separate db for global chat is fairly easy(it's also a remarkably common optimization step taken by existing MMOs). There's really not a lot of interaction with other saved properties besides username, so it shouldn't cause ACID issues the way some db splitting could. The whole chat thing is really the easiest component. Not a lot of concern about a bit of lag or what not...delays would have to get fairly significant to even be noticeable, and even then, shouldn't present a problem unless it gets truly extreme. I might just use Rabbitmq for the messaging element, and hack out logging, antispam, all that jazz manually. Seems fairly serviceable.

Login server should also be pretty easy. Not really a lot going on there. Check versioning, check hashes for hacks, check credentials, forward client the appropriate connections. I suppose one could consider a patch server as an additional element, but again, that's not that crazy. As long as it's a separate component so it's easily split off to be hosted on it's own server, and thus, not kill everything on patch days, shouldn't be a huge deal.

Now, on to the fun stuff. The zone server(s) get to handle all the interesting bits, and are most subject to getting straight up bogged down for entirely good reasons. Most of the other components exist solely to somewhat reduce the complexity and workload of these servers. Figuring out which socket middleware is best optimized for this task is probably on the to-do list. Additionally, some fun decisions have to be made about what all information gets cached in memory, and when it gets persisted to the Db...location probably only needs to hit the Db occasionally, for instance, while item trades are probably pretty critical to persist immediately.

It isn't till here that the actual RPG itself starts to matter. I believe that automatically generated content is likely a dead end, here. With the sole exception of minecraft, I cannot think of a massive multiplayer world that does automatic content generation well...and minecraft doesn't scale well to MMO levels as a result. So, there's a fork here between user generated content and more a theme park model. The former requires some special consideration in terms of saved data and communication.

I suddenly realize how long this is, and how much I've rambled while thinking aloud...perhaps this is enough random thoughts for tonight.

User avatar
You, sir, name?
Posts: 6974
Joined: Sun Apr 22, 2007 10:07 am UTC
Location: Chako Paul City
Contact:

Re: Coding an MMO

Postby You, sir, name? » Tue Oct 28, 2014 11:23 am UTC

Tyndmyr wrote:It isn't till here that the actual RPG itself starts to matter. I believe that automatically generated content is likely a dead end, here. With the sole exception of minecraft, I cannot think of a massive multiplayer world that does automatic content generation well...and minecraft doesn't scale well to MMO levels as a result. So, there's a fork here between user generated content and more a theme park model. The former requires some special consideration in terms of saved data and communication.


You should look into Wurm, Minecraft's sandbox craft-'em-up MMO cousin. I think with better assets and some other smaller design improvements, that game would have made it big time.
I edit my posts a lot and sometimes the words wrong order words appear in sentences get messed up.

korona
Posts: 495
Joined: Sun Jul 04, 2010 8:40 pm UTC

Re: Coding an MMO

Postby korona » Tue Oct 28, 2014 12:58 pm UTC

You, sir, name? wrote:
korona wrote:Java and other garbage collected languages are not a great choice for games or other real-time applications. Their performance (= throughput) is quite good and comparable to that of C/C++ but the garbage collector can introduce long pauses. If your game runs at 30 FPS server-side you really cannot afford any pause longer than 33ms. I strongly suggest C++ for real-time applications.


Well, it's certainly doable (I work for a company that develops just such deterministic-latency high-throughput Java applications). Although it does require writing somewhat non-idiomatic Java as well as fiddling with the JVM flags to get it right. Not that I disagree with your assessment that Java probably isn't ideal. When the choice is made to go with Java in these types of applications, the decision is usually driven by exceptionally high demands on fault tolerance.

That is interesting. Could you comment on what non-idiomatic Java you use in order to get deterministic GC-latency?

You, sir, name? wrote:Also, I don't think any MMO actually pushes full state synchronization at 30 FPS. Position tracking seems often to be a hidden best effort deal with heavy extrapolation (with the client in most cases telling the server where he is, rather than the other way around, rubberbanding occurs when the discrepancy gets unreasonably large), and actions/combat is anything but real-time. It's not uncommon to have input delay in the 500ms-range in MMOs.

You don't have to synchronize the full game state at 30 FPS but you really cannot afford large pauses and non-deterministic server frame rates. I've written a small MOBA using WebGL/node.js and GC latency on the server was definitely something I had to worry about. Modern online games tend to incorporate mechanics that require the player to react with sub-second delay. A 100ms garbage collection pause would be very noticeable.

@Tyndmyr I think you're really over-engineering the architecture here. Start with a simple zone server that handles everything. If you have to scale to a larger number of users you can still separate the server into multiple components. Starting with a complex architecture often leads to code bloat and unnecessarily complex interfaces.

I also think that proper caching is much more important than a choice of database. Character data is small. You probably want to store all logged in characters in memory, mark modified bits as "dirty" and synchronize with the database in regular intervals. I'd probably use a document oriented database; I guess it is more natural to represent things like characters and items as documents than to store them in a fixed table schema.

User avatar
You, sir, name?
Posts: 6974
Joined: Sun Apr 22, 2007 10:07 am UTC
Location: Chako Paul City
Contact:

Re: Coding an MMO

Postby You, sir, name? » Tue Oct 28, 2014 3:17 pm UTC

korona wrote:
You, sir, name? wrote:
korona wrote:Java and other garbage collected languages are not a great choice for games or other real-time applications. Their performance (= throughput) is quite good and comparable to that of C/C++ but the garbage collector can introduce long pauses. If your game runs at 30 FPS server-side you really cannot afford any pause longer than 33ms. I strongly suggest C++ for real-time applications.


Well, it's certainly doable (I work for a company that develops just such deterministic-latency high-throughput Java applications). Although it does require writing somewhat non-idiomatic Java as well as fiddling with the JVM flags to get it right. Not that I disagree with your assessment that Java probably isn't ideal. When the choice is made to go with Java in these types of applications, the decision is usually driven by exceptionally high demands on fault tolerance.

That is interesting. Could you comment on what non-idiomatic Java you use in order to get deterministic GC-latency?


A large part of the GC pausing is avoidable if you restrict the amount of objects that expire after living for a longer time. Object churn in general is discouraged, but acceptable as long as it's mainly Eden-space. There's a lot of avoidable but hidden object creation that goes on in idiomatic Java, so the code takes on a slight C-vibe. Object pooling and other re-use patterns are used quite extensively in areas you need to allocate long-lived objects.

A lot of idiomatic Java object-allocation patterns are really sort of a bad habit. They're used the way they are because you can get away with it, except you pay with GC pausing while the JVM is cleaning up your mess. If you were to allocate heap objects in C++ like you do in Java, your program would also degrade (arguably even worse so) because of rampant memory fragmentation. I mean, fuck, for-each iteration in Java allocates an object on the heap. That's pretty messed up.

But as I said, a lot of the magic is in the JVM tuning. It's the difference between smooth 20-30ms GC pausing and OutOfMemoryError: GC overhead limit exceeded.
I edit my posts a lot and sometimes the words wrong order words appear in sentences get messed up.

Tyndmyr
Posts: 10170
Joined: Wed Jul 25, 2012 8:38 pm UTC

Re: Coding an MMO

Postby Tyndmyr » Tue Oct 28, 2014 8:23 pm UTC

You, sir, name? wrote:
Tyndmyr wrote:It isn't till here that the actual RPG itself starts to matter. I believe that automatically generated content is likely a dead end, here. With the sole exception of minecraft, I cannot think of a massive multiplayer world that does automatic content generation well...and minecraft doesn't scale well to MMO levels as a result. So, there's a fork here between user generated content and more a theme park model. The former requires some special consideration in terms of saved data and communication.


You should look into Wurm, Minecraft's sandbox craft-'em-up MMO cousin. I think with better assets and some other smaller design improvements, that game would have made it big time.


That actually does seem quite promising, more so than the vast majority of indie MMO attempts. The giant pile of assets needed for commercial success is of course a huge practical obstacle...and I dare say that the interface looks a bit rough too(as is also common for indie MMOs).

I note that the sandbox model is particularly common among indie attempts, yet the theme park model is much better represented among games enjoying commercial success. The big exception is EVE...which sort of represents the nexus of the two.

I suspect that this is, at least in part, due to avoidance of the horrifying complexities of the AI/combat engine/performance tradeoffs necessary in the more traditional combat-centric theme park model. It's not so much that the AI itself is particularly groundbreaking, of course, as it is a matter of scope. Plus, obviously, adding all sorts of enemies, combat animations, etc further compound the number of assets required. WoW, in 2009, claimed to have over 1.5m art assets being managed. That's...a little nuts.

I'm hoping to have the time to move a spare server to the basement tonight and get started actually setting stuff up, we'll see if life is kind to my schedule.

User avatar
eviloatmeal
Posts: 552
Joined: Thu Dec 11, 2008 9:39 am UTC
Location: Upside down in space!
Contact:

Re: Coding an MMO

Postby eviloatmeal » Wed Oct 29, 2014 8:57 am UTC

You guys might want to have a look at ArcheAge some time. It seems to incorporate a few of those luxuries mentioned (a bit of physics simulation, character-character collision, sandbox elements, etc.). Of course, EVE does those things as well, but this is a bit more traditional than the crazy, 6DOF, scalable "grid"*, tick-based type stuff that CCP is working with.

Granted, ArcheAge's "innovations" don't come without their own set of quirks and problems - sailboats on top of mountains, lack of adequate server-side position tracking leading to teleport hacking, and so on.

*A (non-programming) technical manual on EVE Online grids (from a tactical perspective).
*** FREE SHIPPING ENABLED ***
Image
Riddles are abound tonightImage

User avatar
You, sir, name?
Posts: 6974
Joined: Sun Apr 22, 2007 10:07 am UTC
Location: Chako Paul City
Contact:

Re: Coding an MMO

Postby You, sir, name? » Wed Oct 29, 2014 11:04 am UTC

I think, with regard to sandbox vs theme park, the problem isn't merely assets, but also content. MMO players want 1023 hours of content with a killer endgame that lasts forever. Even big-budget MMO launches struggle to compete with existing ones in that regard. Indie MMOs don't stand a snowball's chance in hell to compete unless they can use software to generate the content. Hence, you end up with sandboxes, procedural generation, emergent game-play, and those types of things.
I edit my posts a lot and sometimes the words wrong order words appear in sentences get messed up.

Tyndmyr
Posts: 10170
Joined: Wed Jul 25, 2012 8:38 pm UTC

Re: Coding an MMO

Postby Tyndmyr » Wed Oct 29, 2014 5:05 pm UTC

You, sir, name? wrote:I think, with regard to sandbox vs theme park, the problem isn't merely assets, but also content. MMO players want 1023 hours of content with a killer endgame that lasts forever. Even big-budget MMO launches struggle to compete with existing ones in that regard. Indie MMOs don't stand a snowball's chance in hell to compete unless they can use software to generate the content. Hence, you end up with sandboxes, procedural generation, emergent game-play, and those types of things.


Right. It's an attempt to fill that content with fewer assets. This ends up getting surprisingly philosophical, as you quickly have to answer questions about what your grand goals for the game are, and questions about what an MMO should provide, in the process of hashing out what the basic game structure looks like.

I have a theory that...in all the content of big budget launches, they often have rather a lot of it going to waste. Consider WoW, yeah, it's got ludicrous content, but you have some areas where people essentially never go. Not because they're awesome, or super difficult and hard to get to, but because other content straight up supercedes it, or game changes have rendered it irrelevant. That seems like a design problem that complicates the asset problem.

In more mundane things, got Unity redownloaded(version had changed since last time I missed with it), mucked about with setting up Photon, drug a machine out of the basement to act as zone server, got that all set up and working again. Nothing particularly awesome or innovative, just the necessary drudge work.

User avatar
Quizatzhaderac
Posts: 1510
Joined: Sun Oct 19, 2008 5:28 pm UTC
Location: Space Florida

Re: Coding an MMO

Postby Quizatzhaderac » Fri Oct 31, 2014 2:52 pm UTC

Tyndmyr wrote: WoW, in 2009, claimed to have over 1.5m art assets being managed. That's...a little nuts.
Gamespot wrote:The team of 51 artists has created 1.5 million unique assets for the game
I'd consider the 51 artists to be the interesting number. With the 1.5 million it becomes an issue of how you're counting; most of the NPC are probably generated the same way you'd create a character of randomized appearance, manually checked for quality, then sorted as unique assets ever after. Likewise, they probably have some tool for generating trees, or at least they make most tree assets by slightly modifying existing assets.

Obviously an enormous effort is put in, a large number of truly unique assets are present, and a lot of effort goes into combining those assets. However (assuming all 51 artists worked on nothing but assets, for 80 hours a week, since development began) that's only a little over an hour per asset. More realistic project management assumptions puts it at about 25 minutes per asset, a little longer than a typical Bell South programmer takes to write a line of C code.
Last edited by Quizatzhaderac on Wed Apr 20, 2016 9:19 pm UTC, edited 1 time in total.
The thing about recursion problems is that they tend to contain other recursion problems.

korona
Posts: 495
Joined: Sun Jul 04, 2010 8:40 pm UTC

Re: Coding an MMO

Postby korona » Fri Oct 31, 2014 3:13 pm UTC

Assets are certainly a problem for independent MMOs. While coding an MMO engine can be done by a single programmer (for an independent MMO; let's say 1-3 for a major title) in one year things like 3D modelling and animation, texture drawing and map/content design require much more work hours.

Tyndmyr
Posts: 10170
Joined: Wed Jul 25, 2012 8:38 pm UTC

Re: Coding an MMO

Postby Tyndmyr » Fri Oct 31, 2014 4:15 pm UTC

Quizatzhaderac wrote:
Tyndmyr wrote: WoW, in 2009, claimed to have over 1.5m art assets being managed. That's...a little nuts.
Gamespot wrote:The team of 51 artists has created 1.5 million unique assets for the game
I'd consider the 51 artist to be the interesting number. With the 1.5 million it becomes an issue of how you're counting; most of the NPC are probably generated the same way you'd create a character of randomized appearance, manually checked for quality, then sorted as unique assets ever after. Likewise, they probably have some tool for generating trees, or at least they make most tree assets by slightly modifying existing assets.

Obviously an enormous effort is put in, a large number of truly unique assets are present, and a lot of effort goes into combining those assets. However (assuming all 51 artists worked on nothing but assets, for 80 hours a week, since development began) that's only a little over an hour per asset. More realistic project management assumptions puts it at about 25 minutes per asset, a little longer than a typical Bell South programmer takes to write a line of C code.


Game design is a particularly crazy field. I'm sure some are little more than "same model with a new skin", but even so, they're workin' pretty hard. This doesn't include audio assets, either...so...yeah. This is a HUGE stumbling block for anyone wishing to make an MMO.

korona wrote:Assets are certainly a problem for independent MMOs. While coding an MMO engine can be done by a single programmer (for an independent MMO; let's say 1-3 for a major title) in one year things like 3D modelling and animation, texture drawing and map/content design require much more work hours.


There are a few cheats you can employ to somewhat reduce this. Some can be purchased, instead of created. The difficulty here is that keeping a coherent style and feel can be threatened by this. That doesn't kill EVERY buyable/free resource, but it does mean it's not an easy answer, as plenty of time still needs to be spent shopping, format shifting, reskinning, tinkering, and generally making stuff work.

You can make some yourself...though I admit that every asset I've ever created combined would be far short of the above total. User contributions are an option...but user generated content OFTEN sucks. So, there's a gatekeeper issue there.

You can also organize the game so as to use existing assets better. This is...not a small thing. Existing MMOs employ reuse and stuff fairly well. I think there's room for improvement here, but it's not necessarily easy.

User avatar
Quizatzhaderac
Posts: 1510
Joined: Sun Oct 19, 2008 5:28 pm UTC
Location: Space Florida

Re: Coding an MMO

Postby Quizatzhaderac » Fri Oct 31, 2014 5:03 pm UTC

Tyndmyr wrote:[they're workin' pretty hard.
I never mean to suggest they weren't or that a small potatoes studio could do what they did; I was just commenting on how they did the assets: much more permutative and less theme-park-ish than the final presentation suggests.
The thing about recursion problems is that they tend to contain other recursion problems.

Tyndmyr
Posts: 10170
Joined: Wed Jul 25, 2012 8:38 pm UTC

Re: Coding an MMO

Postby Tyndmyr » Mon Nov 03, 2014 3:35 pm UTC

It usually comes down to tool development. Big MMOs usually have a suite of specialized tools(and often, dedicated tool programmers) that improve the workflow of content generation and addition.

Including these coders will somewhat skew the numbers(though they are still very efficient), but...this is a very scale dependent thing. You probably can't acheive the same efficiencies at a smaller scale, regardless of methodology.

Tyndmyr
Posts: 10170
Joined: Wed Jul 25, 2012 8:38 pm UTC

Re: Coding an MMO

Postby Tyndmyr » Fri Feb 27, 2015 9:06 pm UTC

'nother update.

Took a break from Unity, and grabbed a copy of Realmcraft. Not 100% sure which is better in the long term, but honestly, I'm doing a crapton of content generation these days, and models are models, I can import those anywhere. In fact, this is true for most content. So, I'm not all that fussed about how much backbone I end up licensing, reusing, or coding personally. It's all pretty modular, so it's fairly adjustable on the fly. Scripting language will be less so, but honestly, even that's not so unique. So, I'm mostly just building, and will make the final call on Unity/Photon/Custom, or Realmcraft/Custom down the road as far as possible, when I have a better idea of the tradeoffs of each option. Realm-craft does have a lot of the tedium baked into it already, but I'll have to customize at least some of that regardless, and Unity does seem the more mature graphics engine, and has a *ton* more documentation available.

Anyway, I'm something like a hundred models in so far, but most are basic objects and such, not requiring animation or anything particularly weird. Do have a set of basic character models skinned and a few basic animations, but nothing like enough quite yet. Alpha release is going to require at least a half dozen NPC models with animations and skinning and all that jazz. I've gotten my modeling workflow pretty snappy, though, and the resulting models are pretty functional, and I can usually crank them out very swiftly. I need to do something similar for skinning. I can kinda halfass it via groups and materials, but that does involve multiple textures, sometimes a fair number of them, and that will probably have significant performance implications as compared to a combined single texture.

I can't help but contemplate some sort of automated cell shading for making textures, since I'm fine with avoiding "realism", but that *might* prove to be another distraction away from the project itself. So tempting to drag in endless features. For now though, I'm focusing on the boring stuff that I *know* I need rather than the sexy architecture decisions. Weeee. Pragmatically, skinning is just something I have less experience in, so I'm probably not anything like at an optimized workflow for it yet. If I can get it down to 20-30 minute creation times that work, I won't really need automation.


Return to “Coding”

Who is online

Users browsing this forum: No registered users and 12 guests