Below are the 20 most recent journal entries recorded in sirgolan's LiveJournal:

[ << Previous 20 ]

Saturday, January 21st, 2012
11:29 pm	Signing off! I'm moving this blog over to http://blog.mv3d.com. Head on over there to pick up where this leaves off! (Comment on this)
Monday, September 19th, 2011
5:22 pm	Dev Environment Installer Available! Probably the biggest barrier people have to helping out with MV3D is getting a development environment set up. It's pretty easy (on Windows) to run from the prebuilt binaries, but those don't allow you to edit the source code. As of today, a Windows install package for the development environment is now available! This includes: Python Panda3D Ogre3D All of the prerequisite Python libs. Combinator - a tool used to manage development with MV3D's dev process. Directx and vc redistributables. There are a few caveats though. You must pick either Panda or Ogre3D. Although it will install both, one of them won't be fully configured since there's only one active Python install. Also, there will be many sub-installers that come up. Make sure to choose the default options on everything with those. Finally, and most important. Do not use this if you have an existing Python installation other than Python 2.6 in C:\Python26! It will mess up your current install otherwise. Thanks, Mike (Comment on this)
Sunday, August 7th, 2011
3:12 pm	MV3D 0.60 Released! We are pleased to announce the release of MV3D version 0.60! This release focused on scalability of worlds and includes support for splitting a single area across multiple server processes with automatic load balancing and redundancy. Areas can now be connected together using gateways to build worlds limited in size only by the amount of available hardware. The Overseer Cluster Management tool was upgraded in order to better handle many processes across multiple physical servers. Camera controls across all content tools have been unified. Better support for Panda3D clients was added as well. MV3D is an open source virtual world and multiplayer game framework written in Python. It was designed with scalability in mind and is able to distribute a world across as many servers as needed while dynamically balancing the load. The simulation framework is not specifically slanted towards any one genre of online game, and can just as easily be used for a space game as a fantasy setting. Objects on an MV3D server are simulated using the ODE physics engine. A single server can host thousands of simulated objects. MV3D can use either Python-Ogre or Panda3D on the client for visuals. For more information on MV3D and this or future releases, please visit the website. The full release notes for version 0.6 are available online as well. For further inquiries, feel free to stop by our IRC channel on irc.freenode.net #MV3D. Video and screenshots of our new Demo World, the Town of Wellston: Retrospective: What Went Well: Last minute shader and dynamic light support! The client is now authoritative for its movement which means things are much smoother. Fixed some crazy bugs including a few with the persist code which were pretty serious. The persist upgrade system works as designed! The old demo world's databases were automatically updated with no intervention or errors! New Ogre .scene import functionality in Builder is pretty awesome and saved hours of work on the demo world. New triangle mesh colliders including automatic converter from Ogre/Panda meshes makes indoor world building much easier. The new representation file format is a definite win! Official support for Panda3D client and tools on Linux. What Went Less Well: Client movement is still jerky (but at least we know it's a client only problem). The release took 2 months longer than expected. Panda3D support is still not 100% there. Missing: sky, animation, and terrain texture splatting. The tool workflow needs to be simplified. Linux support for Ogre3D is still lacking due to inability to successfully build Python-Ogre. Release 0.70 Planning: The next release will be 0.70 and is focused on tightening up the toolchain as well as adding new client side features. The current list of tickets planned is available here. We will be meeting on #MV3D to go over the plans for 0.70. I'll post a comment here when we decide on the time and date. (1 Comment |Comment on this)
Monday, July 18th, 2011
9:25 pm	Testing MV3D v0.60 The next release is nearly ready. We're looking to get some people to help with testing before officially giving it the thumbs up. You can grab the latest binaries and check it out. The demo server will be updated over the next week, and expect to see a new and improved demo world. Here's a little preview: One exciting thing you'll notice with the binaries is that there are now Panda client and tool binaries for Windows. You'll need the Panda3D runtime installed to use those. Look for the new release in the next week or so if all goes well! (2 Comments |Comment on this)
Saturday, February 19th, 2011
3:25 pm	MV3D Goes Beta! MV3D 0.50 has just been released! This release took quite a bit longer than intended and ended up being 2 months late. On the flip side, there's a lot of new functionality such as support for the Panda3D rendering engine and a path-finding system for NPCs. In addition, many bugs were squashed and the performance problems of the last release are pretty much gone. What Went Right: Panda3D support is great! The NavMesh + A* path-finding system is pretty much industry standard and includes automatic NavMesh generation. A client Patching System is available complete with patch building tool. Documentation. There is now a User Manual. 50 bug tickets closed! This is the most stable release to date. What Went Wrong: Underestimated the time it would take to write a fully functional NavMesh generator, which extended the release by 2 months. Started documentation too late in the project (this isn't specific to this release). It is still pretty hard to configure a whole cluster. This will be addressed in the next release. MV3D's tools could use a polish pass and more documentation. I'm very excited about the next version as well. One of the planned features is splitting up of areas across multiple servers. Another big push is for making MV3D more accessible to new users. Part of that is expanding the user manual as well as simplifying configuration. For more information on MV3D, see the website at www.mv3d.com, or the release notes. There is also a #MV3D chat room on irc.freenode.net which has been getting more use lately. If you don't have an IRC client such as mIRC, Pidgin, or Trillian, you can use the web interface. (Comment on this)
Monday, September 27th, 2010
11:03 pm	MV3D 0.44, 0.50, and beyond. MV3D 0.44 is ready, and 2 days ahead of schedule! The release was focused around building an asset tool-chain to facilitate adding content to MV3D worlds. In that respect, it was an outstanding success. The sprint only lasted about 3 months, which is a lot shorter than most MV3D releases. I'd like to keep up that pace moving forward. The most amazing thing to me for this release is that for the first time, you can spin up an server and populate it completely using tools! The Good: Solid asset tool-chain! Much more stable than 0.42. Guide (the GUI data-binding library) is awesome! Overseer cluster manager really speeds up iteration time and should really help managing servers. MV3D's Client now works on Linux! Users can download server, client, and tool binaries for Windows which makes it incredibly easy to try out MV3D. The Bad: Performance is pretty horrible on the client and server. More tools still needed. Plus, the new tools are just at a bare minimum state. Even though there were many bugs fixed, quite a few big ones remain. Not enough work was done on guidece and guideweb, the CEGUI (in game) and web versions of guide respectively. Even with the GUI, it's still really hard to set up a cluster of MV3D servers. Partly due to bugs but mostly due to all the settings that have to line up exactly. Still some bugs that can cause datastore corruption on upgrades. All in all, it was a solid release and a lot was done in a short time. For next release, which will be 0.50, the current plan is bugfixing, performance, and properly functioning areas with gateways. Including the plans for next release, there are a few major features missing which are required for a 1.0 release. The ones I am currently aware of are load balancing an area across multiple servers and pathfinding AI. I'm starting to put together a roadmap for these. It will be updated more soon. Head on over to MV3D and get the new version! Binaries will be up there tonight. If you are in a hurry, you can grab them hot off the press from the Hudson builder. (Comment on this)
Friday, June 18th, 2010
11:21 pm	New Release and Moar Content MV3D 0.42 released today! Check out the release notes or download the MV3D Windows Client! In this release, the core systems were made ready for tool building and content creation. This included a redesigned persistence mechanism and a cross system GUI layout. The Good: New persistence system is pretty awesome. For the first time ever, you can export or import sections of the game world! Pretty cool start to a new way to build UIs which should save tons of time and allow for quicker iteration as well as reusability. Made an unreleased play in browser app for MV3D. The Bad: New persistence system may have some performance issues. Tons of bugs still need to be squashed. Didn't get to any tools which was the original focus of the release. No visual features added-- nothing cool to show off really. What's next? Well, the next release will focus on the content pipeline. This means upgrading Ogre (since it's long overdue) and tools, tools, and more tools. The one major unknown is how the content pipeline will actually work. Ogre has a lot of half functional or very basic exporters for various 3D modeling packages, which is an unfortunate start to the pipeline. That's not so much something that MV3D can or should solve, but it's fairly disappointing. After exporting the raw files, they have to be added as assets in MV3D. Currently, RED can do this in a very basic way. It does include the ability to SFTP the asset files to the server that will be distributing them which is handy. This will need to be extended and made smarter and easier to use. RED should definitely get in app previewing of assets. It'd also be nice to add a preview image to assets in general. This could be displayed in RED, in the IGE, or on the web editor. Speaking of the web editor, it's completely busted more or less. That'll need fixing, which may come in the way of guide (the GUI framework which also supports web GUIs). What's awesome about fixing it with guide is that the same GUI can be used in IGE or RED without any modifications. With the assets imported, the real fun begins. RED will need a plugin that lets you add and arrange objects in a vacuum (i.e. not anywhere live in the game). Then you can use Freeze (the importer/exporter built in 0.42) to save off pieces of the game world. An additional RED plugin should be able to connect to a server and edit existing areas. Here you could import the stuff you created before and place it in game. This should also have the same functionality of the other plugin so that you can edit anything you want. One other missing piece is the collision volumes. These need to be manually placed (or generated from static geometry in some cases). This means the other required tool will be something which is able to position colliders for models. But wait, there's more! There needs to be a way to edit bodies of water, and in fact, the current ocean object should probably be made into a water volume since right now it's just an infinite plane. Similar to water, the sky should be editable, and if you are editing the sky, physics properties of the realm need some love too. Finally, it'd be nice to be able to have more than one area in the game at some point. Part of the RED area editor should include connecting areas together. At this point, it's been so long since this was tested, that it may not even work any more. Sounds like I have quite a few tools to write. Any volunteers to help? (Comment on this)
Sunday, January 31st, 2010
3:04 pm	Storage Space I've been trying to come up with a better way to persist MV3D state info. Basically, I need a solution that meets the following: Synchronous when saving data Transactional Extremely Fast when saving data Maintains data consistency Supports queries Externally available (i.e. you can view/modify/query the data outside of MV3D) Low CPU overhead The current solution does support most of those. The four it's probably worst about are queries, data consistency, CPU overhead, and external availability. It's also just kind of wacky. You define a list of properties in your class that should be stored along with which of those properties you'd like to generate a search index for. When it's time to save an object, it generates a uuid for it, then it stuffs all the properties you defined into a special object, pickles it, and then uses Axiom to persist it to sqlite. It uses index objects stored in Axiom which match the uuid with the value of the property in the object. Querying is also a little odd since you use magical properties on a query object (q.a == 12). Unfortunately, the object type you are querying for may not have an a attribute since the query object doesn't really care. Another interesting part of the system is that it requires all servers to store their data locally. I'm not sure how I feel about this since some MV3D data really isn't useful to other servers-- at least as the design stands now. However, it does require that there be two servers for every item stored in order to recover from a catastrophic failure of a single server. I've tried in the past to go with a completely Axiom based solution, but that didn't work well because of the restrictions Axiom puts on any classes you mark up as Items that can be persisted. One thing I'd been thinking about was a dual object approach where you have the in memory object, and when it needs to persist, it stores all its persistable attributes into a specific Axiom class. This system could even use powerUps. This had a couple of downsides, one of which being that you had to define twice as many classes. It also ends up that you'd have to define your datastructure twice as well. The other option is to have a utility to generate that extra code, but I'm not a big fan of code generation, so I'd like to avoid that. What I'm currently thinking of is adding a new service type to MV3D that would generally act like a data access layer (DAL). You'd mark up classes in Python with which attributes should be stored-- and I'm thinking of combining this with the attributes that are sent over the network. In order to persist an object that had this mark up, you'd hand it over to this service. It'd then store the marked up attributes and return a unique ID you can use to retrieve the object later. While technically at this point, it really doesn't matter where or how the data is stored, I'm going to go into that a bit. There would be several low level functions: register schema, upgrade schema, add object, update object, get object, and query. Basically, schema in this sense is the markup of a particular class which defines attributes to store and what type they are. For SQL based stores, this will be directly associated with a table. Schemas will be versioned so that when a newer version is registered, all data is upgraded. I see this happening by renaming the existing table, creating a new one with the new schema, and running code on each element to upgrade it. After the schema is created, adding an object would just be a SQL insert and updating would be similar. Both of those could return the primary key of the row as an ID. Adding the primary key to the object's class and the service's location would give you a method of retrieving that object from anywhere. Querying for the user could make use of the class markup objects to give them the ability to do something like: store.query(Person, Person.name == "mike"). Looking at the requirements I mentioned, the major ones that it fails are being synchronous and maintaining data consistency. I put synchronous when saving up there because I like to be able to wrap methods that modify data in a @autoStore decorator which stores the object after the method runs. If this were async, either that function would have to return a deferred, or you'd lose data consistency if there was a failure. It would also be sweet to be able to define the markup classes as descriptors which would a) store the object and b) update any network clients of the changes. A possible solution to this would be to strategically limit the remotely available functionality of the service to the low level operations I mentioned previously. Then to make them have nothing to do with converting objects into persistable data. This would require a local object/service to interact with the remote store. The local code could build a queue of transactions to send to the master store, and this queue could be persisted via sqlite. This way, the data would be synchronously stored to disk locally and then sent off to the remote store whenever. One other issue here is that theoretically multiple servers could access the same object in the store at the same time. Yes, that sounds like a feature, but the aforementioned queue causes some issues with doing this. The data in the master store may not be 100% up to date. What might be interesting is to create a locking mechanism whereby when loading an object from the store, you acquire a lock on it. The hard part will be making sure that the lock goes away whenever you stop using the object and that failure conditions (such as your server crashing while holding locks on multiple objects) are properly handled. Another issue is what to do if the store rejects a change that seemed like it would succeed locally. If we go with writes that return immediately and don't wait for success, it would already be too late to tell the original caller that something went wrong. What are some of the reasons this would happen? Remote storage server is down. Ok, just keep it in the queue until it's back up. Remote storage server is out of space. Keep it in the queue is probably best. Schema mismatch or invalid data. This seems like the worst failure mode. What do we do with a schema mismatch or invalid data? This indicates a fairly serious problem, so maybe it deserves a serious resolution-- revert the object and all other objects related to the transaction that failed both on the remote store and in memory. That still doesn't seem like a great way to resolve the issue, but it would maintain data consistency. All in all, this seems like it'd be pretty challenging to implement, and it'd mean that I'd be maintaining a DAL/ORM as opposed to using a pre-existing one. I'm generally against re-inventing the wheel like that, but all the Python ORMs I know about are designed for webapps and don't translate well to MMOGs. Really at this point, I'm looking for someone to talk me out of this and tell me why it's a horrible idea. Otherwise, I might just be crazy enough to try it out. One thing that's bugging me is that the current mechanism works. I haven't had any lost data issues or anything; however, I've found that sometimes it's just easier to blow away the whole store than to say revert a change I made. At the very least, I like how the new system abstracts out the DAL to a service that can optionally be on a remote server. This makes it so the underlying persistence technology can be pretty much anything. Another major benefit would be the ability to freeze objects by storing them and stopping simulation of them. Then you could unfreeze them later on a different server. What's this good for? Well, making it so your character leaves the world when you log out for one. This isn't currently possible without a load of hacks. (1 Comment |Comment on this)
Sunday, January 24th, 2010
3:09 pm	Ship it! MV3D Version 0.40 will be officially released today. I'm building the Windows binaries and source release now. I'm happy with the release, but visually, it's a bit of a step backwards. I don't have any good screenshots to show, or a movie detailing the new features. There are new features though. They just aren't visible, and if they are working properly, you should never need to worry about them. The main theme of this release was completely refactoring the scalability and redundancy of MV3D at the core. This was a very big success. I now feel comfortable saying that MV3D is ready to scale. In a properly configured cluster, items will be both spread across the servers and have redundancy in the case of a failure. Items can be transferred from server to server based load balancing needs. Looking at MV3D as a whole, there are still a few elements that need major work. The most obvious right now are tools, the client, and possibly data storage (sadly). It seems to me that tools to generate content are less useful if the data storage mechanism changes significantly (since either I'll have to write a converter or you'll have to lose all your stuff). On top of that, making the client look good and perform well is hard to do and mostly pointless without any content. With that said, the logical order is to work on data storage first, then tools, and finally fix up the client. I'm hoping to not spend too much time on data storage. I have some ideas, and generally want to make whatever I come up with retain the same API. For tools, RED needs to be extended and generally made useful. There also needs to be a way to more or less export and import whole areas (or even whole realms) at a time. Any project bigger than a single person messing around will want to have this ability so that they can version control their world. While fixing a recent bug, I came to realize that a tool for managing MV3D clusters is desperately needed. My repro steps for that bug involved checking in to SVN, updating two servers, restarting them, and then connecting to their SSH console. It would have been nice to be able to run 2 or more servers on my desktop for testing. So, this is another tool that should be forthcoming. While I'm talking about that, the reason I had to repro the bug on the servers as opposed to in unit tests is because while there are unit test facilities for testing a full server against a real-ish client, there isn't much in the way of full integration tests between multiple servers. Some of the problems I was tracking down ended up being issues that came up only when you started two servers, created some stuff, shut them down, restarted them, and tried to create more stuff. Integration test helpers for scenarios like this would be pretty awesome. Another headache I ran into while rebuilding the demo servers was that since the starter world initialization code is written to work on a single server that provides all services, it doesn't work well when you have a separate directory or account server. This made it so that I was basically typing the code on the console to create the world. No one should be expected to have to do that-- a tool is needed that can bootstrap a set of servers to get them to the point where other tools like RED can be used to create a world. There are plenty more things that need tools, but so I don't bore people more than usual, I'll move on to the client. The client seems slow. In reality, it gets 150-160 FPS, but it still feels sluggish for some reason. This is probably physics related, but it makes things look bad. The other big issue on the client is that since the server sends position corrections to the client's avatar instead of the other way around, moving around can be a little clunky (even with the smoothing that's done now if there's a discrepancy). The UI on the client is very clunky and ugly. I'd really like to get that looking better. There's tons of stuff really that needs help. Sounds like a lot of work, doesn't it? It definitely is. If you've gotten this far, you must be interested in MV3D, so why not contribute? There are a ton of open tickets now that would be excellent for someone looking to get started. That's all for now! If you try out the new release, just be warned that it's visually the same as the last release. I'm hoping that as tools come online, I'll be able to add more content to the demo world, but that depends on what code changes I have to make on the server to support the tools. (Comment on this)
Sunday, December 13th, 2009
10:02 pm	No news is.. Well, no news. It's been quite some time since I've posted anything here about MV3D. Things have definitely been going slowly recently in that regard, though they are picking up again now. I work on an MMO all day, so when I get home, I generally want to do something else for a while. However, now that I'm more settled in, I've been able to start putting in the time again after work and on weekends. Mostly, I've been trying to put together some content editing tools since the in game editor isn't really the place where you'll want to put all your content together. It's good for terrain sculpting and adding foliage and such, but I think I'd pull my hair out trying to use it to make a town. One of the major methods of building complex things in MV3D is the modular object system (demo'd in a few of the videos I think). I'm working on a tool so that complex modular object systems can be designed without having to write code. It's coming along really well. At this point, I'm not sure it really fits in with MV3D, so I've been keeping it on the side. My goal is to get content creation and some semblance of an art pipeline up to a point where I can create a passable looking game world. I'm not expecting anything too wonderful because I have no talent making 3D models (and am therefore limited to GPL or CC licensed ones that I can find), but I should be able to come up with something. Then after that, I'm going to start working on putting together a demo game. At this point in the development of MV3D, I've often been unsure what the next most important thing for me to work on is. If I start putting a game together, I'll be able to quickly see what areas need help and work on those. At least that's the theory. One thing I really want to fix up is the client performance. Last time I ran a load test, having 50-100 characters running around caused the client to become fairly unresponsive. Not surprising since I'm not doing a ton to mitigate that. I'm sure some people are probably hoping I'll talk about 38 Studios and Copernicus. About all I can say is "Yes, it's awesome, and no, I can't talk about it." Ok, I can say more than that. We're hiring! Check out the 38 Studios Jobs Page. It's really a ton of fun working with such an incredible group of people. Hopefully, with things picking up on MV3D again, I'll be posting a bit more. I've also started an MV3D page on Facebook. Mostly, I'll use that for random related things that don't really warrant a whole blog post. I'll probably also put pictures up there that I wouldn't want to put on the main page. (Comment on this)
Thursday, May 14th, 2009
11:13 pm	Lack of Windows 64bit support Seriously. I have XP 64 on my main system at home (ok, stop laughing) because I have 4gb of RAM and don't want to make my Athlon X2 into a K6 by running Vista. Anyway, I've recently decided that it would be a good idea to move my music creation stuff from my old desktop to the new one. The old one just really can't keep up any more and starts getting tons of lag when doing real time effects. Anyway: M-Audio Midisport 1x1: no drivers for XP 64 (most M-Audio hardware: no drivers for 64 bit OSes) Every MIDI loopback driver except LoopBe and MOLCp3: no support for 64bit OSes Behringer FCA-202: no 64 bit drivers period (most Behringer hardware: no drivers for 64 bit OSes) Cakewalk 64bit version: runs ok but seems to not detect some VST plugins (32 bit ones maybe?) Cakewalk 32bit version: BSOD. The last one is the one that really irks me. Apparently, the reason it blue screens is because Microsoft never made ASIO sound drivers work properly in XP 64 or Vista 64. Seriously? ASIO, by the way, is pretty much a requirement if you want minimal sound lag. Apologies for the lack of updates lately. I've been plugging away with refactoring load balancing and am getting close to done. I'm considering another release shortly after that stuff is finished. I'll probably put in some things I was hoping to get in to the last release, along with some bugfixes and then call it done. Other things have been keeping me busy such as my new job, which is completely awesome of course! (2 Comments |Comment on this)
Sunday, March 22nd, 2009
3:20 pm	LFG There hasn't been a lot of visible progress on MV3D recently. That's mostly due to changes in my employment, but also because I'm working on a monolithic project to revamp the load balancing. I think I'm half way through, but I'm not really sure. Anyway, for the past 3 years, I've been the only developer working on MV3D. Mainly, I wanted to make sure that the foundation was in place and it had a clear vision. After these load balancing changes, though, I feel like the foundation will be there. So, I'm looking for help. The big areas are client side programming, tools / editors, and help taming Ogre's art pipeline. However, once the load balancing is done, I'm going to start working on Siegium again, but this time it'll be as a demo world for MV3D that has game logic. If you are interested, comment/email/post on the forums/send carrier pigeons. (5 Comments |Comment on this)
Wednesday, March 4th, 2009
4:58 pm	Balancing act. I didn't really go into detail too much as to how I solved load balancing and redundancy previously. In order to better flesh it out, I'm going to do so now. Please refer to the following diagram: This is what I'm calling a cluster. It is what will be managing high availability in MV3D. Although there's on big box there, the cluster is meant to run on as many CPUs as you can throw at it. I've just demonstrated a single node in the cluster for simplicity. At the core, it is a sharded pool. A sharded pool uses a plug in mechanism to link a given id with the pool it exists in. The default mechanism is a range based partitioning scheme. A basic example of this would be one that sends ids 1-1000 to pool A and 1001-2000 to pool B. That's the general idea. Clusters use the default range mechanism to partition the ids into shards. These shards are themselves sharded pools. In this case, though, they use another mechanism that is optimized for a 1-1 mapping of id to pool. It is expected that the pools it maps to are redundant pools. That's a whole new type. The redundant pool is as it says. All of its objects are duplicated across all the members of the pool. So far, there's a hole in the scheme. Where do these mystical ids come from? Anyone who has looked at MV3D knows that an id is either an integer (0) or a two integer tuple (0, 0) where the first number is the parent's id and the second is the child's id. For instance, in the case of an item, the first number is the realm id and the second is the item id within the realm. Anyway, these numbers come from an IDDispenser object. The cluster has one of those. It sits in a cluster-wide redundant pool. This means there is one master dispenser per cluster (and multiple redundant copies). This is where the ids come from. The redundant pool it sits in can also be used for other things that belong to the cluster. One particular use for this is to have an object which provides data for the pool. For example, an Asset Group would be a cluster, but there would be an AssetGroup object in the Redundant pool that has information about the group. To expand on that notion a bit further, the redundant pool for a Realm would contain the Realm object which contains physics properties. I haven't mentioned too much about the load balancing aspect of this though. Really, it's fairly easy. The sharding of the top level cluster ensures that you can split up the management of the cluster across as many servers as needed. Then individual items in the cluster can be moved from pool to pool very easily to balance out the load. With directory, realm, and asset servers, the load balancing will be fairly manual. When you need more servers, add them to the appropriate cluster or pool. Load in these areas should be fairly predictable by standard means. The load balancing gets a lot more interesting when you start talking about simulated parts of the world. Load balancing at that level is more tricky because the load isn't predictable and is a lot more dynamic. 100 or more players could crowd into a shop where just moments before there were none. I'll likely write about this in more detail with a future post, but the basic idea is to automate enough of the load balancing to make capacity planning predictable. MV3D will have a bank of servers partitioned to simulate a set of areas and a mechanism to balance that load across the servers. With that in place, capacity planning can be done by determining the load across the group of servers by changing which servers simulate a given area. Watching the increase over time should allow the operator to predict when more hardware is needed due to population growth. In general, all of your simulation servers would be in this group so that you can best make use of them. As I said, though, more on this later. (Comment on this)
Sunday, February 8th, 2009
2:42 pm	Redundancy, check. After about a week of banging my head against the wall trying to figure out a better way to do redundancy in MV3D, I think I've finally got it worked out. I even have code to back it up. What I've created is a redundant pool of objects. Servers can join or leave the pool, and objects are replicated to all servers in the pool. One server is the master and the rest are slaves. If the master goes down, one of the slaves picks up the slack. The master can re-join the pool as a slave. It seems to work great. The next step is writing a million more tests to make sure it acts properly in every situation I can think of. Once that is done, I think I can build on the platform I created to make different types of HA pools. For instance, one that divides objects up into sub pools. Anyway, I'm pretty happy with this new method of keeping things redundant. It'll take a while to integrate it into the rest of the code, but I don't foresee any major problems. It is pretty cool though, I just implemented a method to move items from one pool to another. This could be used when changing the partitioning around, or (if I do one pool per area) when an item moves from one area to another. (Comment on this)
Saturday, February 7th, 2009
2:57 pm	Unified theory of high availability. I've been working on ticket #211 for MV3D lately. If you looked at the ticket, you'll see it's something that's been kicked around for a bit. The current redundancy and load balancing code is fairly broken in trunk. It did work at some point in the past, but a myriad of changes have caused it to break in various ways. Clearly, one problem is that there weren't enough unit tests for it or this would never have happened. The larger problem is that the code was very repetitive and not very organized. I'm setting out to fix this, but it's not been easy. I've written a bunch of code and tests, but I have no idea if it is remotely the right direction to go in. Not to mention that this is the 3rd or 4th major direction change I've had since I started on this ticket. Nonetheless, I really want to get these details worked out before MV3D gets much further along. The longer you wait on something like this, the harder it gets to fix in my experience. If what I'm talking about makes no sense, read up on MV3D's Server Architecture. The high level requirements are that there be no single point of failure for any service MV3D provides and that servers below the Directory servers can come and go with little disruption. Starting at the top, a Directory should be split horizontally (by item id) across a number of servers. Each part of the Directory should be replicated to several servers. Asset Groups and Realms should get the same treatment. Realms should organically divide items across Simulation Services based on the Area they are in. All Items should exist on at least two Simulation Services. To further complicate things, some types of Areas can spread themselves across multiple servers, which means the objects within them have to do the same. It is very important to keep objects in the same Area (or piece of an area) on the same server so that there is no time lag for physics collisions. The current way of doing this makes each level in charge of distributing the load for sub-levels. This means that there is also no method to get HA Directory Services. The Directory stores a master and a list of slaves for each Realm and Asset Group. Asset Groups also have no redundancy right now and must exist on a single server. The Directory Service is able to promote and demote copies of Realms on various servers from master to slave. Realms manage a list of Areas and what servers they can be simulated on. Each Area manages where its objects are simulated. This generally makes for a big mess without much rhyme or reason as to where anything is served from. Another problem I've encountered is that having all HA items be pb.Cacheable makes it hard to switch them from slave to master or back without re-caching them (which would cause confusion to any object that kept a reference to the old version). I was going to write about my solution, but after I started, it became clear that it was completely wrong, so back to the drawing board. (Comment on this)
Tuesday, January 27th, 2009
3:43 pm	Better late than never... I'm finally gearing up to make another official release of MV3D. This release includes quite a lot of new content creation features including: Add and remove objects Move and rotate objects Select objects by mouse or from a list Terrain Editor Grass Editor Object Factory UI (for creating complex objects using templates) A bunch of big client features: Configuration gui Camera that doesn't go through walls New loading screen / progress bar Windows install exe! Plus some behind the scenes additions: No more media directory (shaves 30mb or so off the download size) Bumpers on the ends of the world so characters don't fall off Client requests items from the server instead of the server pushing them on the client Lots of new unit tests! I think double the number in the last release. Here's a video I made for the release: You can download the first release candidate of the MV3D Client for windows right now and connect to the alpha server. If you don't already have an account, go to the MV3D login server and create one. As a side note, the music in the video is the first piece I've recorded since I got my new bass guitar. (2 Comments |Comment on this)
Monday, December 1st, 2008
11:03 pm	MV3D Status I've actually had some time to work on MV3D lately, which I've been happy about. I did make a short video of the in game editor. It's nothing wonderful (though I really like the music I came up with for it). One of the things I did over the long weekend was to start making the client behave a little more like a client and less like a dumb terminal for the server. Previously, when you connected to a server, it would just shove all of the objects in your view range at you. Now, the client gets to pick. This has the added bonus that the client loads the images from closest to farthest. It can also limit the view range to less than the maximum to save bandwidth or cpu. The client is still limited to getting items which are in its view range by the server of course. The other big thing I did-- I'm still amazed I got this working-- was to completely remove the need for the huge Media directory for the client. It's about 65MB. I had to keep a few things. Just the GUI related files and the background image. Everything else is downloaded through the resource system in game like it is supposed to be. This should reduce the initial download size for the client by a lot. That brings me to the next thing I'm working on, which is getting a Windows installer for the Client to work. I'm trying nullsoft to see how that goes. It seems pretty simple. I'd like to make some sort of script to put together the release using py2exe and such. Currently, there's a bunch of manual work involved after the py2exe step. Currently, there are 18 tickets left in the release. Hopefully I can get those finished up this month and get a new release out. That'll depend on if I can keep feature creep out of there. I really want to make a simple "Add item from template" type deal in the editor since right now adding an item is rather useless. (Comment on this)
Monday, October 20th, 2008
10:48 pm	Nevow + Axiom website: finished product (sort of) First off, websites are hardly ever "finished" as I'm sure many of you know. Anyway, I've got the site up for real now although it's still lacking in content (Corey, put some stuff up there, hint hint). Working with Nevow and Axiom was great and enabled me to build the site in a very short amount of time. The brunt of the work was done in about a month. It's got a complete admin interface to it including image uploading. I also wrote a full featured shopping cart for the first time. Check it out: http://www.cescenics.com By the way, don't those calendars look nice? I know you want to buy one. Another cool thing-- got to give some credit to PayPal. Their sandbox is a great tool, but also they've added some really neat stuff since I last used their API. You can have them notify you via a hitting a URL of your choosing when the status of a transaction changes. So, I've used that to verify that a purchase has actually gone through. This website plus lots of extra hours at my job have really slowed down MV3D work. I'm currently finishing up the in game ui for adding and removing objects. Unfortunately, for every in game editor piece I finish, I find about 5 more that need to be done. One I just thought of today are body modifiers-- so you can modify the physics properties including colliders and also the visual properties like models, textures, scaling and placement. I have found a new web host though. And I'll be attempting to move trac over there shortly. (Comment on this)
Sunday, July 6th, 2008
12:55 pm	Nevow Complaints Vol 1 I've heard a good amount of complaints made against Nevow, and one of them was that templates can't include other templates. I've been working on a web based resource management system for MV3D this weekend and of course, it uses Nevow. I decided it would be nice to have a main layout template that included other templates for navagation and the content of the page. But that can't be done with Nevow, right? Wrong. It's pretty easy to include other templates. Just use rend.Fragment-- it even suggests using it that way in its docstring. Before I get in to specifics, I'd like to just comment on what I just said. Another complaint that I've heard about Nevow is that there is barely any documentation. In some cases, I can't disagree-- if you are talking about missing docstrings or an extensive manual. One thing I've learned, though, is that if you want to know how to use something, just read the code. The only Divmod code I've found so far that was hard to read was deep inside Axiom. Definitely part of that was because I didn't really understand metaclasses at the time. What I'm saying is that I've always found the quickest way to answer a question is to just get out the code. Anyway, rend.Fragment isn't mentioned anywhere in the Nevow getting started manual that I know, but it took me 20 seconds of skimming rend.py to find it and even before reading the docstring, I knew it was what I was looking for. I also found that there's a nice example of how to use it in exactly the manner I wanted in the examples folder. What's neat is that you can use it to cache chunks of your pages really easily. Say you have a header bar on the top of all your pages that is always the same for users who aren't authenticated. Just make a subclass of rend.Fragment to render it and use the same instance of that everywhere. If that header changes for logged in users, then you can easily switch which rend.Fragment subclass you display in the header section depending on whether the user is logged in or not. I could give an example usage here, but the best place to look is in Nevow/examples/fragments/. In other news, there was something strange going on with the MV3D alpha server where it wouldn't allow people to log in after creating an account. I'm not sure what the deal is, but somehow, I've fixed it. So, please give the new release a try if you haven't already. (3 Comments |Comment on this)
Thursday, July 3rd, 2008
12:23 am	Release time! I just released MV3D 0.32 today. It has all the features I mentioned in a previous post plus now a load tester. There's a slight issue with the load tester, though. It can't handle load very well. The load tester, not MV3D. I had it going with about 75 clients connected and moving around, but the load tester was going very slowly. The problem is that currently, the client has no choice on which objects it gets updates for. The server decides which objects are within view range and automatically makes sure those exist on the client. Since the load tester impersonates any number of clients (75 in the example above), that means 75 player objects get updated 75 times. I have a ticket for the next release that will stop this behavior and allow the client to choose which objects to receive updates on (of course limited to ones the server deems are in its view range). I suspect that will fix the load tester and allow it to test more effectively. However, 75 clients connected is pretty impressive. I was even able to log in via a real graphical client and walk around a bit. It got choppy now and then, but for the most part, other than a low framerate (30-50ish), it was pretty responsive. Impressive considering there were three apps running on my system that wanted 100% of a single core, and I only have 2 cores. I didn't end up making any changes based on the load testing I did. That was mostly due to not being able to stress the server enough to make it matter. My next task is to figure out what the 0.34 and 0.36 releases mean. Now that I have persistence solved for the moment, there are two areas that need attention. One is the world editor, and the other is load balancing and redundancy. My current thinking is that since load balancing and redundancy worked previously and the framework for them is still in place, it should be ok to focus on world building first. I figure that there won't be any need for load balancing if no one can make worlds other than the test world. In any case, it's time to do the ticket shuffle. (Comment on this)