Intrest in a GG sponsored MMOKit.

#121 ________________________
A lot of people would really be happy with a stripped down system in which you can start with a foundation and work your way from there,
________________________

Thank you for the response Joshua, its good to see that we aren't barking up a fake tree :)

As for your statement about money and push I agree, but all money is, is incentive, and while its one of the best :) its not the only one. I am hopeful there will be more incentive as the ideas continue but likely you are right money will have to play a factor, Glory or accomplishment can help fill in but I am not going to be naieve about it, Optimistic yes ;) naieve no.

I am spelling Naive wrong aren't I?

Anyhow, Good blessings upon everyone who has a task, now back to mine!!

Chad.

#122 A stripped down system is exactly where I am started with things, I don't need the scale of MMO's right now so zone servers can wait, it gives us a setup that looks like:


Most should be self explanitory apart from:
- TRAC Integration: Expanded TRAC via a plugin to allow us to manage, start, stop servers, view stats, etc and create/maintain tickets.

- QA Server: we have a number of testers, this allows us to create tickets within TRAC directly from an in-game GUI including uploading screenshot and recording the players exact location. As developers we can then view a bug and get the game to jump our player to the exact location the bug was recorded from.

The servers are coded in Python and seem to be handle quite a volume of connections without any issue.

#123 Well it has been said a number time that what is needed/wanted is a bare-bones MMOKit, with the option of a basic game included to provide some form of guide for developers.

Andy's post is interesting, and would be great to have intergrated into the kit, be we need to start with the basics first, if a community MMOKit is to be made. Can't start running without learning to walk first! ;)

#124 Thanks Andy great feedback, between computer issues, a bad flu, family issues and errr a small online game addiction we won't go into here, I have been out of action.

Glad to be back, I am only hearing from a few people on this post, is it because few are left interested, or everyone has given up hope of Anyone doing anything?

Chad.

#125 What you might be seeing is a common phenomenon around hobbyist/indie built MMOs and MMO frameworks; too many "players" and not enough devs. If you want to start an indie or hobbyist MMO team, it is frighteningly easy to attract a team of ten or twenty. This team will gather around a forum. They have lots of interesting discussions about design theory and then after a couple of weeks they will all vanish to go play .

Given that this is the GG forums, what you are more likely seeing is that the people who don't fit the above description already have a project. Any project going down that route will have to woo them. It will have to show that it is organized, has a committed core and is not going to vanish in a fortnight. In short, it will have to convince them that they are not wasting their time with "players" taking a break from gaming to pontificate.


I'm still around and I'm making solid progress on my design language and interpreter engine. I'm hoping for a 0.1 release by the end of Jan and my offer to collaborate with anyone working on a framework still stands.

#126 As David mentions it's a common phenomenon in a lot of communities where people are quick to offer ideas or critisism but won't commit the time to working on resolving or improving things, you'll notice I vented my frustrations on that score earlier on in this post - although I could have chosen a less aggressive way to have put things.

Which is one reason why I've started something on my own so I can at least understand some of the pitfalls that you only find by having a go, I'm sure Josh learnt much by writing MoM and if it's like most projects he were to start again he'd probably do some things very differently.

If anyone wishes to get involved or help out then let me know, I've little experience with Python (although quickly becoming a fan) so have gone for an iterative approach to first just prototyping things with quick and dirty solutions to prove concepts, feasibility and learn some things and then re-writing as required with better versions.

@David - It's a little early for me to be discussing integration with your design language and interpreter engine but I'd be really interested to hear more and as I progress further look at how I can integrate with what you're doing.

#127

Quote:I'm sure Josh learnt much by writing MoM and if it's like most projects he were to start again he'd probably do some things very differently.

Yup, most definitely :)

#128

Quote:it's a common phenomenon in a lot of communities where people are quick to offer ideas or critisism but won't commit the time to working on resolving or improving things

I know of at least one community that doesn't fall into this category.

As stated before in this thread and elsewhere, a group of us have already made a lot of progress on some multiplayer online middleware.

Several of us are contributing 10 - 20 hours of work towards this project per week... each.

The middleware is 100% game engine agnostic, and even mostly game genre agnostic (if you're making an online game, this middleware should be a great place to start).

I know this isn't exactly a Torque specific project, but it doesn't exclude the use of Torque either.

In fact, if someone using Torque were interested in helping out in other areas, I would gladly lend my expertise with Torque and help you integrate the middeware with your game. (good C++ coders only please... I can help, but please don't ask me to do all of it for you.)

Some key features that you might find useful:

* Pure ISO C++ for maximum performance and compatibility
* Cloud computing support for low-cost, easy to maintain, scalable networks
* Service oriented architecture for increased flexibility, extensibility and scalability
* Login server, zone server, chat server, etc are individual services that can be housed together or independently
* Free for commercial and non-commercial use
* Source code include
* Redistribute the original or modified source code if you desire, but it's not required
* Minimal library dependencies (libxml2 and boost are the only required libraries)
* Community projects so you can learn by doing and by seeing what others do

Additionally, we're working on several other "genre" starter kits that use this technology including an RPG starter kit among other things.

We have several games under development using this technology already.... if you're interested you should consider joining in and helping out one of these teams.

AIR - An Aerial steampunk MMO RPG
Arcanoria - A medieval MMO RPG with a focus on innovative gameplay
Fractured Universe - A virtual world as a "toy" project.
Legynds - A live action RPG that's going virtual

Personally, I wish people would stop with the attitude that Indies can't make big games and therefore they should stop trying.

The "Indie 2.0" style of making games is about groups collaborating on the common while each game dev team focuses on creating their own innovative games...

Using this style of collaboration, we can make large games and compete with the big guys while using small teams.

[edit - clarification]

#129 @Tony
I don't think that it is that indies cannot approach and make huge games (though budgets often cause problems, especially in the art department initially and in the production department when it comes to paying for a MMO infrastructure down the line). But they are not insurmountable.

I think that the core of the problem is that inexperienced dev's or teams with a huge idea and no experience have an extreme uphill battle because they have to learn everything from scratch. Providing a great engine or middleware or free licenses to professional modeling suites can only go so far. The dev or team have a ton of elbow grease to put into it, and most new dev's just don't realize how much time they will be spending learning rather than creating their dream. Especially if they have no coding or art skills to work with and need to build them to even attract others to their idea.

You're a good example of an indie who has gone out and done of a lot of cool stuff. You have drive and you have taken the time to learn what you need to get things done. But if the stumbling block is getting through the difference between a while loop and a do-while loop and how to use arrays, it gets exponentially harder to attempt to work huge and learn the basics.

That's why I advocate the "start small, dream big; learn; develop chunk by chunk, but in small manageable learning chunks" approach for new developers. Experienced developers can often gauge their learning curve since they've worked several huge projects.

I personally don't believe that "indie" means small or cheap. I believe it means independent from the shackles of the industry. It doesn't mean that an indie cannot make a sweet MMO or high-scale FPS or the mext multimillion dollar Bejeweled casual game; it just means that they work on their own terms without traditional industry dictates.

But my ideas about the whole "what is indie" or "can they do it" probably doesn't belong here. I just thought I'd post my thoughts when I read your post. Can't wait to see what indieZen brings to the dev community.

#130 Nicely put and I'll make this short so as to not sidetrack the conversation too much.

Quote:I personally don't believe that "indie" means small or cheap. I believe it means independent from the shackles of the industry.

I completely agree.

It would be nice if we could somehow make the distinction between professional Indies and hobby game developers. Probably this is where some of my distaste with "Indies can't make MMO" attitude comes from.

A professional Indie is someone who knows his trade already. He's either done it or he's been trained to do it. A small team of professional Indies can indeed make an MMO.

Quote:That's why I advocate the "start small, dream big; learn; develop chunk by chunk, but in small manageable learning chunks" approach for new developers.

A hobby game developer is still learning the ropes and I completely agree that hobby game developers should start small.

That's how you "level up" from being a hobby game developer and turn into a professional Indie.

Maybe "professional" and "hobby" isn't the right terms, but it'd be nice if we did have some sort of "level" qualification on some of our statements.

#131 We've been using a term around the office for the last year to make a distinction between "inexperienced" and "experienced" Indies:

BHAD (Beginners Hobbyist and Aspiring Developers)

#132 I think the difference between hobbyist and indy professional really lies in the intent. Let's exclude the high flying "indies" who manage to secure VC for a moment. For most indies and hobbyists alike, this is a part time affair. A hobbyist who never intends to "work in the industry" can still bring passion, perseverance and excellence to their hobby. An indy who intends break out on his own can bring passion, perseverance and excellence to his moonlighting as a game dev.

Quote:The "Indie 2.0" style of making games is about groups collaborating on the common while each game dev team focuses on creating their own innovative games...

I've been keeping an eye on your group (I'm registered your forums and go by the nic "Cayle" - the same as on a few other places) and it pleases me to see a meta-group such as yours making progress. I was involved with a project a couple of years ago that tried to do exactly the same thing. It was called Build-A-World and was formed right after the free ryzom campaign after some people there surveyed the open source PW frameworks that we available circa Christmas 2006 and found it lacking. It has long since gone defunct, fell into the deadpool and disappeared from google's search list. The difference between baW and Zen is really the "player" to experienced dev ratio I think. Our own team (really two people), which was trying to build a small PW, were involved with them and I saw firsthand how dysfunctional such groups could be. Ours was the only actively contributing group and BaW only served to inject politics. We eventually cut our ties to save ourselves and BaW disappeared soon afterwards.

On the bright side, the Memotica design language came out of that experience. We looked at our design ideas and realized that the solution we were designing would also work for dikus and d20 clones with a bit of redesign and we kept at it after disengaging with BaW. Two years and two complete back to the drawing board redesigns later, we almost to the point where we feel comfortable releasing a solid 0.1.

#133 Very similar to what one sees in modding communities. In the "good old days" people would release Half-Life 1 mods for example, and not get too caught up in looks; concentrating more on making it fun and enjoyable. Then at some point near when several mods went commercial and Half-Life 2 came out, mod developers began to aim high - and usually beyond their means. What that's meant is one mod after another that had some promise, but never got released. They are forever stuck in the, "It's not ready to release yet" mode.

What I think more people ought to do is do more incremental releases. Don't make the uber fantasy MMO game with thousands of monsters, a dozen classes, hundreds of spells and millions of unique items spread across vast untold miles of land. Instead, make one with your basic game mechanics and like two classes ("Figher" and "Magic User"). Make an MMO that people can play and even max out on in a month of play. BUT, while they are playing for that month or two and you are fixing bugs, you are also coming up with expansions. Maybe a new class, or more items and monsters.

So aim for something like a release schedule of something small and cool every month (new item, new spell), something nice every two months (new class, new quests or monsters), and something very cool (expanded lands) every 4 months. If you do this, and your core game doesn't suck, people will stick to you I believe.

And the key to not making it suck is starting small. If you can make a fun little MMO with two classes that's fun and engaging, you can make a big one that's also fun and engaging. If you make a big one that sucks, you'll probably have a very hard time making it not suck.

And of course, don't forget that by starting small, you will have a FAR better chance of actually finishing something and get it out there for players to play. I'll contend that a small little game that's released is a million times better than a big one that's not (ever) released.

#134 An MMO Starter Kit designed for a BHAD would be significantly different from an MMO Starter Kit designed for a professional Indie.

A starter kit designed for a BHAD, you would probably spend more time on the tools, editors, etc, but the final product would present something significantly less flexible than a product designed specifically for a professional Indie.

A pro would want to be able to extend then core of the middleware, probably using C++, but also require the ability to use scripting language(s) so the game designers can have a more agile environment in which to work.

A BHAD would probably want more point and click type interfaces with the ability to drag and drop behaviors, do some scripting and possibly have some forms in which to fill some of the data (spells, item descriptions, etc).

A good example of this would be a starter kit that assumes you have linear levels, ever character has a class and each class has skills available at each level, etc... of course you could go the other way and the starter kit could assume that the RPG is more of a skill based system instead of a class based system.... and then a step further, your starter kit could leave that decision to the game developer, but that starts adding complexity to the starter kit.

The more "branches" you support, the more complicated the starter kit is to create and use. The more you leave completely undone, the easier it is for pro's to use but the harder it becomes for the BHAD's to use.

The trick is deciding which decisions should be left to the game developer and which decisions should be decided and pre-implemented in the starter kit, and how far do you take the "choices" that you pre-implement.

For the BHAD, you would want to make a whole lot of the decisions for him and make it mostly just a "fill in the blanks" type kit, much in the way you train kids to draw using "connect the dots" techniques.

Maybe what we really need is a "starter kit starter kit"....

I had started making something along those lines and had planned on making it open source but nobody was helping me with it, so I closed it up... I'm still developing it and making progress, but we could make more progress on it if more people worked together on it.

Originally I started writing it in Java and it was based on Eclipse and recently I moved over to C++ using wxWidgets and writing my own "Eclipse" like IDE... it's not far enough along to be very impressive right now, but I can promise that my design is good enough that it'll be a nice end product.... but if I do it alone then it's going to take me another year or two (or more depending on what you call "done.")

Personally I have no interest in creating tools for BHAD's and my interest in creating technology for Indies is primarily as the spear tip of the Indie 2.0 revolution... I'm not profit motivated, but it doesn't bother me if someone using what I create is motivated by profit.

For all I care, Garage Games could grab Zen Engine, polish it up a bit and sell it as Torque 2... the license actually allows things like that to happen.

I've proposed this before and I'll propose it again...

We should create a game development IDE that uses a plugin system so you can plug in new tools and new extensions and new features.

Next, we should make starter kit plugins with extension points where people can extend the starter kits.

For instance, you could have an RPG Starter kit plugin that that has an extension that adds support for classes and another one that adds support for some sort of spell pack complete with special effects, or whatever... It's slightly harder to create such a beast, but I've got some experience with this and I can bear the brunt of the pain (and risk).

With this type of approach, you have more continuity... people come and people go and the more of it that's open source (ZLib style) the less effect people have when they leave. Maybe someone pulls the plug on a plugin they've written, but should only be a small part of the whole picture and in most cases.

With this type of approach, you also have more opportunity to make smaller packages and sell them. You also have more opportunity to make more choices for the starter kits without making them completely unusable (you only use the plugins that are relevant to your game, which means you don't have a bunch of menu items or icons on your toolbar that are completely irrelevant to the game you're making)

As a starter kit developer, you also have the ability to take the code, package it up, add your own custom plugins and sell it as a standalone product.

All I ask is that for the core code we focus on writing middleware and not target any specific game engine. People have reasons for choosing one engine over another and I would like to preserve that right.

Why is this better?

Look at the success of Eclipse... it was originally primarily written by IBM programmers and IBM even resells it as the core of their Rational suite, but other companies (like the one that makes MyEclipse) can also package up a custom build of Eclipse and sell it as well.

Everyone contributes to the common stuff to make sure it works well, but everyone concentrates on their niche or specialty. This works even if there is more than one group in the same niche or specialty.

What I'm proposing is the long hard way to make a great product as opposed to the short quick way that would probably work just as well, but for a smaller audience.

I know I can do it, which means I know I can definitely do it with help.

The only problem is that you don't know if I can do it and therefore you don't know if we can do it together.

If you're a C++ programmer, take a look at some of my work. You can download and install a sample of my work.... look at the code (don't bother trying to get it to work because it's not polished enough and it's hard to get to work without some help).

Sure, some of it looks very complicated and a lot of it is very complicated, but mostly I can handle the complicated stuff.

Now, take a look at how easy it can be to use what I write. (This code is part of some tutorials I'm writing that shows how to make games using Zen Engine).

No matter how complicated you may think that writing a game engine agnostic game development IDE would be, I've got that covered... but the more people that help, the sooner it can be completed.

I'm going to do this with or without help. If it's without help then I'm keeping it to myself and selling it at a high price (because it's a valuable piece of software, not because I expect to get rich). If people join in and help me then I don't have a problem making 100% of the code I write free and open source using the ZLib license.

Just think of the possibilities... you could have L3DT (assuming he wanted to make a plugin) running inside of your IDE, editing the terrain, and then without switching tools (or even closing the viewport where you're viewing the terrain) you can add some new trees and tweak the position of a building, then switch to another tab, add some scripting to the game then spawn off a copy of the game and debug the script... all from within one feature-rich IDE.

Note: I'm not proposing you make an IDE inside of a game engine, as I think other people have misunderstood in the past. You might have a plugin that supports your game engine's render engine so you can do WYSIWYG editing, but otherwise the game engine has nothing to do with the IDE.

Anyways, I'm rambling... what say ye? Any C++ coders out there interested in helping? Going once, going twice....

#135

Quote:An MMO Starter Kit designed for a BHAD would be significantly different from an MMO Starter Kit designed for a professional Indie.

You can learn a lot on this front from Multiverse. Generally they have a great idea, but the tools and ease of use are a major pain point. And guessing that 90% of your market will be BHAD, and 10% GHOOD (whatever that would stand for :D), be prepared for that BHAD slice. Also you can bet that the GHOOD developers would love to have easy to use tools and such.

#136 Multiverse is just history repeating itself ten years later. Good company, good people, bad idea.

If the 3d Internet and virtual worlds ever takes off, there's not going to be a single solution provider, protocols will be standardized, anything that isn't open source on the server side will never get widely adopted, and the client browser will end up being free if not open source.

The biggest players in this space are Linden Labs, and IBM. IndieZen is one of the underdogs (as is Multiverse) and I'm working my tail off to make Zen Worlds becomes the next "Apache" for virtual worlds.... not for control or profit, but because it needs to be done and nobody else is doing it as FOSS.

But that's the server side... you're absolutely correct that tools make a world of difference... literally.

When I think of a tool for BHAD's, I think of pre-designed databases, pre-built forms for populating quests, NPC's, dialogs, etc.

When I think of the same tool for professional Indies, I think of exactly the same thing, except with a database designer and a form designer so you can completely customize everything.

That's just an example, but do you see the difference?

One is more for a team that has one or more professional programmers but is ultimately more flexible while the other is more restricting and promotes cookie-cutter games but is easier to use for BHAD's.

#137 @Andy Rollins: I like the server setup diagram you did. What software did you use to create that? :)

#138 Tony's goal is to build the Apache of virtual worlds. My goal is the build the HTML/CGI of games/virtual worlds. I see the following types of posts all the time on the TMMOKit and Multiverse forums: "how many levels should I have", followed by "I need player housing". This type of post defines a BHAD. They think strictly in terms of the mainstream MMOs on the market and what feature set they have. They never stop to ask if they need levels at all or if they prefer skill based, what the advantages and disadvantages of both are or even if they want character advancement at all. Both Realm Crafter and Josh's Kit are well suited to these people. All the choices are made and you just flesh out your diku. But what about designers who want to delve deep and explore nonstandard (i.e. non-diku) approaches?

I'll give a very specific example. What about physics in your ruleset? I'm not talking about kinematics which is already covered (at least wrt. naive physics) by "physics" engines. I'm talking about leaky containers, the weight difference between an empty mug and one full of water and assemblies. Assemblies can bring your server to its knees and no big house building "the next WoW" would dare try them, but what about small community worlds? What about simply the difference between making your sword out of iron and steel? These things get talked about on occasion, but nobody ever implements them outside of the text mud development communities. Why? The standard refrain is "complexity", blah, blah. I hold a postgraduate degree as a physicist and I'll tell you that the beauty of physics and nature lies in the fact that complex phenomenon come about because of simple rules. Despite what Damian Schubert may say in his blog, if someone implemented a universal and portable set of thermodynamics rules that struck a balance between fitting players' naive physics expectations about things exposed to fire getting hot and performance, it would be widely adopted. But even if I sat down and wrote that on a particular engine, it would be usable only by people on that engine and only if their own ruleset was written around it.
Ideally, there should be something that:

----Allows GHOOD developers to quickly and iteratively define rules in a standardized way using a "design language".

----Allows GHOOD developers to extend and enhance those rules and share them with each other as libraries.

----Allows library re-use. Seriously people! We are in the 21st century! Why does it always seem like everything is being re-invented from scratch?

----Does not limit devs to a single engine. If you create a model in 3DSMax, you expect to be able to get that model into Torque 3D or Unreal or anything else. It may possibly require tweaking, but you won't have to recreate it from scratch in engine specific tools.

----Allows the GHOODs to pull the BHADs along with them. Need a diku ruleset? Download and install a library. Need thermodynamics? Install a library.

Memotica tries to solve all of these. At its low level core, it is simply a way of defining abstract data structures. At a higher level, it uses standard data structure types to define agents (SimObjects in Torque) actions and stimuli (which get filtered and fed back to clients and AI), resulting in what amounts to something similar to a directed graph language where actions change the state of agents and stimuli report that state.

Edit: spelling naive the proper way will mangle your post :)

#139 @David - We need to sit down for a bit and talk...

#140 Nathan - It's just Microsoft Powerpoint, quick and easy to draw something like that in it.