Makin' Mah Mmo

[plopperz]

Just ignore poisenedV , he is a fag and is just jelous because he can't develop games.....

That was harsh and (likely) untrue. Deserves a ban IMO.
EDIT: Well, now that I'm posting here I should mention that this game looks great. It's good to see that MMOs are already in development for the Pandora

 

[sindbad]

I checked the article about making a python mmo server fast and it's very useful. The code is not exactly nice, but it's a very good design overall (I also thought of using pickle).

Now looking into twisted. It would certainly be much faster than a C# threaded server and may even be faster than a C# async framework (a benchmark showed that apache's java mina doesn't scale nearly as well as twisted).

 

[jakewastaken]

I'm excited about this project too keep up the good work!

 

[DasFool]

On another note, currently working on putting an abstraction layer between my client and Pygame/Pyglet so I can ideally allow the user to use whichever. Considering I've heard from some others that they're unsure which to use I'm wondering if there's any interest in me eventually releasing the abstraction modules?

I can't promise it'll be very good code, or even very useful to anyone but me, after all I'm an amateur, not some highly educated software designer. But hey, if there's interest, I'll see what I can do to keep it tidy enough for an eventual public release.

I'd be interested in coding some quests. I'm decent in python and pygame. Maybe you could set up your program for svn somewhere when it gets closer to completion so that others can add more of the major content.

 

[xyouheix]

Have you decided on the name yet? Silly question, but I was curious.

 

[Eniko]

In principle, I'm willing to help. I'm especially interested in taking your challenge of making a server in python (or something else if that fails).

I'd be interested in coding some quests. I'm decent in python and pygame. Maybe you could set up your program for svn somewhere when it gets closer to completion so that others can add more of the major content.
While I appreciate the offers of help, for now I'm going to keep this one a solo project. At some point I may open up the source, either a cut down branch so other people can roll their own, or the full thing because I can't hack it myself, or just bring more people in on it. But until that happens I'd like to stay the only developer on this project. ^^;

anyway, pixel art is awesome... i guess Im just a nostalgic bastard, but I will always appreciate the low res crispness of it.
Agreed, I have a great passion for pixel art. There's a lot of nostalgia there, and it does some things well that arbitrarily scaled graphics cannot do or do well, like highlighting details properly in a small canvas.

For targeting, you could use a system similar to Z-targeting, or the targeting used in Robotech Battlecry. You would have a special button (like L or R) specificially for targeting which you would then press again and again to switch targets. For targeting multiple enemies, you would hold the attack button and use the Targeting button to determine where each of the extra targets go.

I've got other ideas for controls, but don't really have the time to type them up atm, so if you like this idea, just reply here or send me a pm, and I'll see if I can find some time to type up the other ideas.

-God Ginrai
This would work better with a game where there's free, non tile based movement from the sound of it? Personally I was thinking more of a point and go stylus approach for movement a la Ragnarok Online, but maybe I should reconsider that for a tile by tile movement, like Ultima Online, driven by the analog stick.

Or maybe allow both? After all, different strokes for different people. Not everyone is as fond of touch screen controls as I am. I'd definitely like more suggestions on the issue of control scheme since it's not something I have already worked out in my head.

I, myself, have always dreamed of a Megaman Battle Network MMO, or something alike.

Perhaps i can persuade you to fulfill said dream >
I'm not familiar with the Battle Network series, but I think that that's not only an entirely different type of game but it would also result in cease and desist letters from Capcom. >_>

I checked the article about making a python mmo server fast and it's very useful. The code is not exactly nice, but it's a very good design overall (I also thought of using pickle).

Now looking into twisted. It would certainly be much faster than a C# threaded server and may even be faster than a C# async framework (a benchmark showed that apache's java mina doesn't scale nearly as well as twisted).
I personally found that article and the code kind of lacking. Sometimes the "make something that works then expand" thing works very well, but for a server I'd definitely try to think ahead more so you don't wind up with a clunky unwieldy beast that's hard to modularize or abstract. Plus the thought of running a server which has blocking IO calls in a single thread just makes me cringe.

Plus I was rather hoping he'd write about how he coded the server during those four hours, rather than just saying he did it, giving some code, and saying he went by a certain principle. Either way I don't think I'd develop a server in CPython, I've done some reading and - though I might have been misinformed - it seems as though the GIL would slow down any threading done in CPython, which disqualifies it as a suitable choice for me. IronPython might be an idea, but it doesn't run well on Mono and I'm unsure of the quality of the language in general.

Is Twisted really that powerful? I must admit I've never looked into it and was just going for a threaded C# server approach, but if it's that good I'll definitely have to look into it. More information would be highly appreciated.

Have you decided on the name yet? Silly question, but I was curious.
Not such a silly question. I have one, but it's more a work name so I'll probably wind up changing it a bunch of times before the end. Once I find something I like to settle on I'll create a new thread or rename this one.

I'd also like to say I'm glad that people are showing interest in this. It's very motivating.

 

[sindbad]

There's a benchmark comparing Mina and Twisted. This shows just how much more efficient epoll is in comparison to poll.

Threads don't scale nearly as well with a lot of connections. As soon as you go over 1000 it's not manageable anymore. Twisted does stuff asynchronously (look at lighttpd vs apache benchmarks) if you don't have blocking stuff. You can use a thread pool or a process pool (so it scales fine to multicore).
Stackless python is more similar to classic threading, but can spawn hundreds of thousands of lightweight userspace threads, a bit similar to erlang (which is the language to use if you want extreme performance, scaling and reliability in a server).

Threading in CPython is only a problem when you have mostly cpu-intensive tasks. The GIL gets released for some operations, like I/O, or can be explicitly released in C modules (something you'd write yourself to speed up your python code). There's also the pyprocessing module (multiprocessing in 2.6) which has a very similar API to the threading module, but instead spawns processes. If you don't have massive amounts of communication between your threads it's more efficient and the memory consumption on OSs with copy-on-write (linux, freebsd) is not much higher.

If you really, really want to use another language and want garbage collection, try D (C-like speed and better-than-java conciseness). C# is not such a good choice right now, since Mono is still quite a bit behind the JVM or .Net.

Have a look at this, it might be useful.

PS: Still willing to help with the networking part

 

[logokas]

QUOTE

I, myself, have always dreamed of a Megaman Battle Network MMO, or something alike.

Perhaps i can persuade you to fulfill said dream >

I'm not familiar with the Battle Network series, but I think that that's not only an entirely different type of game but it would also result in cease and desist letters from Capcom. >_>

Screw CAPCOM!

Well, not really. But you should try the BN games out. The games are mostly GBA, the latest games being on DS.

Might give you a good idea, if nothing else.

 

[BenTolputt]

sindbad has a decent summary of the options. I thought I'd add my experiences to the thread; hopefully to your benefit.

For long-lived, light-weight TCP network connections with high numbers of simultaneous connections (such as, say, an instant messenger and/or RPG), you need a framework that does not dedicate a thread to each person connecting to the server. There are a few of these around, but the easiest by far is probably Twisted (though it does have it's own limitations).

Erlang (& it's built-in OTP library) is much better suited for this purpose, having been designed & developed initially for telephone switches (so tens of thousands of simultaneous connections/processes). It is, however, an unfamiliar language to most and a functional (rather than procedural/object-oriented) one to boot. However, I have developed in it for sometime and there is another real-time online game (Vendetta Online) that moved to Erlang for managing their back-end NPC's & quest control systems with apparently resounding success. Other advantages include built-in clustering, SMP (multi-core) support, and hot-swapping of updated code (i.e. code can be updated while people are still playing the game!).

Stackless Python is another interesting development you may wish to consider. There has been some work on integrating it with Twisted, but I have not been directly involved with this for some time so I don't know it's current status. Stackless has a pretty good resume in that it is used as THE language for the development of the EVE Online back-end servers. there is, of course, C/C++ plugin libraries but the bulk of their development is in Stackless. Like Erlang, there is an adjustment to be made for the programming paradigm (messages & channels), but unlike Erlang it is in a familiar, mostly procedural language (Python). It's disadvantage is primarily with the fact that it (like all Pythons) is single-threaded. Whilst you can run multiple threads at the same time, only one of which can ever be running Python code at a time. Depending on the structure of your game, this may or may not be an issue for you.

 

[God Ginrai]

For targeting, you could use a system similar to Z-targeting, or the targeting used in Robotech Battlecry. You would have a special button (like L or R) specificially for targeting which you would then press again and again to switch targets. For targeting multiple enemies, you would hold the attack button and use the Targeting button to determine where each of the extra targets go.

I've got other ideas for controls, but don't really have the time to type them up atm, so if you like this idea, just reply here or send me a pm, and I'll see if I can find some time to type up the other ideas.

-God Ginrai
This would work better with a game where there's free, non tile based movement from the sound of it? Personally I was thinking more of a point and go stylus approach for movement a la Ragnarok Online, but maybe I should reconsider that for a tile by tile movement, like Ultima Online, driven by the analog stick.

Or maybe allow both? After all, different strokes for different people. Not everyone is as fond of touch screen controls as I am. I'd definitely like more suggestions on the issue of control scheme since it's not something I have already worked out in my head.

My method for targeting should work fine no matter the movement system. But on another note, what do you mean Tile-based movement? Do you mean that characters, when idle, are always wholly in a tile. (As in, they can never be standing partially in one tile and partially in another?)

Also, as for movement. I do think you should allow either the Analog or the Dpad for movement, because, like you said, not everyone likes stylus controls. (I like using either a Dpad or an analog stick for movement.)

I'd be glad to work out some control schemes for you. Do you think you could describe me some of the game mechanics?

-God Ginrai

 

[PoisonedV]

Allowing both would be nice. some could play it with squadbased / tactical rpg controls, while others could use action RPG controls depending on their preference. (like in NWN)

 

[God Ginrai]

Allowing both would be nice. some could play it with squadbased / tactical rpg controls, while others could use action RPG controls depending on their preference. (like in NWN)

Is that Freeware yet? I've been meaning to play that.

-God Ginrai

 

[PoisonedV]

Allowing both would be nice. some could play it with squadbased / tactical rpg controls, while others could use action RPG controls depending on their preference. (like in NWN)

Is that Freeware yet? I've been meaning to play that.

-God Ginrai

No, and I doubt it will be any time soon, since they just recently stopped making new content for it, and still sell the additional content and a special edition version of the game. its still quite profitable.

 

[Eniko]

Quick update: whatever time Twisted might save me during development I'm definitely losing struggling through it's documentation. Currently on page 150 of 220 or so. *twitch*

Speaking of, what's generally speaking the most efficient type of Twisted reactor? At a guess, epoll, but I'm not entirely sure.

 

[sindbad]

On linux, epoll.

Just try and get something working, after you use it a bit more it will make more sense.

The documentation is huge and you can cherry-pick through it. It may save some dev time or not, but it is much more efficient than something you'd come up with in that time.

 

[Eniko]

Well, I'm about to ditch Pyglet unless anyone here can advise me on what I'm doing wrong. For some reason whenever I try to render using Pyglet my framerates drop drastically and I'm hardly on an old machine. Right now with as many optimizations as I could find on the net I'm still getting only tops 40 FPS with Pyglet.

Compare this to almost double that with Pygame, and I'm not even bothering to be optimized when using Pygame, I just draw the visible portion of the map every iteration.

I've created a TextureBin, which I load all the graphics into. Then - in sheer frustration when no alternate method proved to top 10 FPS - I created one sprite per tile and object on the map, and still nothing. Disabled debugging and everything. It even gets only 120 FPS while simply clearing the screen.

My GPU couldn't possibly be this slow, so there's something else that's throwing a wrench in things, it's impossible to believe that software accelerate SDL can be twice as fast as OpenGL.

Ugh, so sick of this after two days of it.

 

[sindbad]

Try the Pyglet google group, they're very helpful. It may be that Pygame changes your resolution, while Pyglet does not. In my usage of both, Pyglet sprites and the like have been very fast.

 

[sindbad]

I just bumped into http://wiki.secondlife.com/wiki/Eventlet and a web server using it http://pypi.python.org/pypi/Spawning/0.7

There's also http://code.google.com/p/cogen/, but I don't know much about that.

These should require less of a mental switch than twisted, but are less battle tested.

 

[Eniko]

Thanks sindbad, I'll look into the alternatives. You've been a great help so far.

Now then, I have a question for the potential players of this game, whether it be on the Pandora or other systems: what would you think of the game being in 400x240 resolution, and scaled up to 800x480? I have the necessary experience required to create scaling algorithms, either through pixel shaders or C extensions, so it won't be crappy nearest neighbour or bilinear quality unless you like that sort of thing. (might need help if anyone wants me to implement hqnx though The code isn't even commented and optimized to all hell)

There's a few pros to this:

1. Easier to code. Upscaling a smaller screen will easily outperform using the larger resolution, which means I have less evil optimizing to do, which means I can focus more on getting things done.
2. Halving the resolution will greatly speed up my productivity. Not only do I have a lot more art assets for that resolution than 800x480, halving the resolution means for pixel art I only have a quarter of the work per asset to do. This will help me get things done more easily.
3. Portability. I'm not sure if this will be a big factor, but I'm putting it here either way. I believe for instance it might be able to be ported to PSP, though I only glanced at Python/Pygame on PSP at best so I don't know details. 400x240 resolution means it would fit on the PSP's screen, although whether the effort gets far enough for this to be workable remains to be seen.
4. Full screen post processing. Because the game will run a lot faster there's a lot of idle time that I could use for postprocessing tricks to make things look all pretty. I realize a lot of people couldn't care less about this, but as someone with a heavy focus in graphics programming I find this to be almost the most fun part of the whole process.

Of course, the drawback is the low resolutioness. Not even a good scaler can offset that entirely. On the other hand, some people might associate this with a retro kind of feel and appreciate it.

To give you an idea of what you might be looking at, I took an old mockup and scaled it up in a few ways: unscaled, nearest neighbour, bilinear, scale2x, and my personal favourite scale2x/bilinear blend

So, does anyone have a strong opinion on this either way?

 

[sindbad]

I think you should leave it resolution independent and, if after profiling it's too slow, do the scaling trick. You may very well not need to optimize it any further and you might want to port it to desktop OSes, which need variable resolution.