Well for one thing it has already been done before. My idea is to make some thing like TheUniversal (A Tractor originally) and it has been made and has not attracted too many users. Well my copy of the universal will fail too probably for the same reasons lack of time and motivation to complete it. The basic idea. Player has essentially a client and he goes from world to world (as one would go from zone to zone) but each world is located on a different server. Each server is player run and can have any rules they like. Some worlds are economy worlds where you get jobs and build stuff. On some worlds you play games like Mech fights. Basically you do any thing you want with the world you host. As long as its on-line players can come a visit it. The money and the items that you acquire in one world don't transfer to the next except some times through basic galactic currency. I can expand the idea of having 2 inventories one for inter-world items and one for world items that will remain in that world when you go some place else. But i guess the things you can do with an item will change from world to world ... This will allow the other people who want to make an mmorpg to make one! Just take a world and mod it to any thing you want. If you like wow, draw the models and tweak the rules and you got shadowy resemblance of a carbon copy of wow. If you want races make a race world where you get wheels and get points by finishing first. If you like FPS you can make a world like that too. Or a Mario Brothers jumper or some other classics like space invaders. But have multiple people play it at the same time ... I plan to do this in an easier to maintain language, a language i like – python. This way the world files could be as simple as couple values in the script or as complex as client itself. Also will probably make it open source after i do the bulk of the work on it. I will use blender as the modeler and would ask mods to use it b/c its such a nice tool. I will probably use mygl.istrolid.com 3d engine because i know it inside out having written it myself. The game client needs to function with a couple of things. Logging in into the name server, chat on chat server, have ability to download and display 3d models the world provides and send user input to it. “Sounds simple if i say it that way”, you say... In the end the game will look like a mesh up of low quality games that have a cross reference persistence theme to them. And will probably will have not much fun things to play just unfinished,buggy worlds on low bandwidth servers. But who knows it might allow creative people to make an mmorpg for my web...grr mmorpg browser. Maybe it will even transform the way people use the interment. But that is down the road for big companies to stump out in the unlikely case the game gets any popularity. So i beg you to talk me out of it!

Yes if you do the entire client (and whatever server -- assuming all those people wont have to create the server part all themselves in your scheme) on Python it will be like you say. Python runs something like 20X slower than C/C++ and IS NOT a good candidate for writing entire clients/servers (it might be OK for scripting simple behavior stuff and config, etc..... ontop of a native code server/client, but NOT the entire thing).


You might want to look at Second Life (which sux in a different way - its more a pretty chat room than a game) and Neverwinter Nights (which has player run servers in which good ones are far and few between).

Quote:

Original post by wodinoneeye Yes if you do the entire client (and whatever server -- assuming all those people wont have to create the server part all themselves in your scheme) on Python it will be like you say. Python runs something like 20X slower than C/C++ and IS NOT a good candidate for writing entire clients/servers (it might be OK for scripting simple behavior stuff and config, etc..... ontop of a native code server/client, but NOT the entire thing). You might want to look at Second Life (which sux in a different way - its more a pretty chat room than a game) and Neverwinter Nights (which has player run servers in which good ones are far and few between).

It is indeed true that Python-script is being executed slower then native compiled C/C++ code, but Python is a linking language. It can call and execute C/C++ code.
That is the reason why it is so powerful, you can simply call piece of C++ code which is beeing execute faster then if you would do it in Python itself. So it is a win-win situation, Flexibility of Python and the speed and performance of C++ combined.

As for the idea. It has indeed been done before and has not been a great succes. If you ever going to undertake such a massive project, you should be very precise at what features are going to make it into the game. Else you will drown in all the problems... and problems are motivation-destructive.

Regards,

Xeile

So basically, you're making an online development program. The game itself is in making different games. Do you realize how much programming that would take? It's one thing to make one game, but a game that lets the player make their own world with all the aspects of a complete game...

I suggest stripping the idea down a bit. Set out some unified gameplay ideas that would be common across the worlds, and let the players focus more on the aesthetic aspects of the worlds. Also, this concept seems more suited to a lobby based server than a persistent world, so keep that in mind.

Yeah, I see a couple problems..

#1 What is the advantage of using one shared platform? To me it seems like using a shared platform would be a limitation. In writing a library you often have to make choices. (One example: are you going to assume that your world map is static, so that your action games get the best speed possible? Or is your world map dynamic, giving people the ability to change the terrain on the fly). Writing a library that keeps everyone happy is a very difficult task.

#2 Content. How are you going to get people to make games for your platform? There is already a wealth of great, free game libraries out there. And yet, there is not a wealth of great independently-made games. Why is that? I think it's because most hobbyist developers dislike using someone else's library. Everybody wants to write everything from scratch (something you yourself are guilty of)

#3 There are (or will be) lots of MMO engines available. Sun's Project Darkstar is one. And when I was at the GDC this year, I counted roughly 6 companies that were also selling MMO platforms or middleware.

There was even one guy that advertised something really similar to your idea (I don't remember his company). He said something like "If everyone uses our platform, then the customer gets the benefit of a shared client! Players can jump between worlds instantly!" I was skeptical of him too.

Quote:

Original post by Xeile Quote: Original post by wodinoneeye Yes if you do the entire client (and whatever server -- assuming all those people wont have to create the server part all themselves in your scheme) on Python it will be like you say. Python runs something like 20X slower than C/C++ and IS NOT a good candidate for writing entire clients/servers (it might be OK for scripting simple behavior stuff and config, etc..... ontop of a native code server/client, but NOT the entire thing). You might want to look at Second Life (which sux in a different way - its more a pretty chat room than a game) and Neverwinter Nights (which has player run servers in which good ones are far and few between). It is indeed true that Python-script is being executed slower then native compiled C/C++ code, but Python is a linking language. It can call and execute C/C++ code. That is the reason why it is so powerful, you can simply call piece of C++ code which is beeing execute faster then if you would do it in Python itself. So it is a win-win situation, Flexibility of Python and the speed and performance of C++ combined. As for the idea. It has indeed been done before and has not been a great succes. If you ever going to undertake such a massive project, you should be very precise at what features are going to make it into the game. Else you will drown in all the problems... and problems are motivation-destructive. Regards, Xeile

Yes I know that usually python is used a glue and relies on speed from the C code it calls (and the libraries...). But it sounded like the OP was speaking of writing the entire thing in Python (try writing a fast A* in python for example....). Thats why I emphasised saying 'but NOT the entire thing' .....

There are an awful lot of different areas of a game engine which the table lookup mechanism and allocations that python uses would be deathly slow.
All the high soeed guts to it would have to be coded in C/C++ and thus most of the system would not be in Python. The game mechanics stuff that defines specific games (the big feature of the idea) could lean heavily on python but only if enough of the primitives interfacing with the engine were exposed to it.

This sounds like teh best idea ever, and I think you should definitely go for it. Just be sure that you also make a default world where you can be anyone and do anything. And don't forget to make it free.

[rolleyes]