Makin' Mah Mmo

[MarkoeZ]

Eniko has stated that GM's will be able to edit the world in realtime, which certainly helps with content.




Ah, i missed that post, thanks

 

[kloplop321]

that would be nice.
I would guess with all this versatility, that character skins would be easily available as well? (as long as it does not exceed certain sizes and is not Rated M or anything)
I would like to have a clean(not dirty) game that is supported and mended by the community

 

[BenTolputt]

Always good to see a project actually make it beyond the initial "press release". Good going, Eniko!

Not sure what libraries you are using for TTF support. I don't use SDL (at the moment) so if it's natively supported, ignore me. I personally use the "freetype2" library in my engine - which works very well

 

[DasFool]

hmm, sounds nice, but this got me thinking about user created quests inside the general area as well (submitted for approval ofcourse ; ) Might increase the gameplay overall. That's the biggest challenge with small projects, (original) content takes a lot of time to develop. If users could submit their own, it would be more hours of single player enjoyment. And there might be some interesting/hilarious/genius entries as well

I suggested helping with quest content as well, but Eniko wants to keep this a solo deal.

 

[Eniko]

Keep in mind this is intended to be an MMO, not a user-created environment like Second Life or even something more sandboxy like Furcadia. (it's the only game I can think of with user created maps served from their local machines okay? ) On the other hand what Tempel said is true, and I'm looking into expanding that system to let GMs edit more than just maps, even scripts and events. That means that, possibly with some volunteer program in the vein of Ultima Online volunteers, new content could be created at any time by any number of privilidged accounts.

On the other hand, there are certain problems with the volunteer model.

To elaborate more on what content you can expect; personally I'm a big fan of event-driven content over quest-driven content. A quest here is defined as something that will stay in the world permanently, and every player no matter when they're playing can participate in it. This means your work will keep being worth something, as people will play it over and over.

But in my experience quests do little for most players' immersion. After all, how many times has VanCleef lost his head in World of Warcraft? It doesn't make you feel a part of the world since you can only consider that experience truly yours if you keep it sheltered away from everyone else. That's no good.

An event is defined as something with specific content that runs for a short while, probably overseen by one or more content GMs. These are actual non-repeating world events, and if you miss it you miss it. If you participate though, a mark will be placed in your character's profile that reads like "Survived the great turnip war of '74". While events have a very short life, and marginal returns on time spent creating them, they do create a lot more immersion than repeatable quests do.

Of course there will be a balance between quests and events, but expect things to lean more to event driven than quest driven. It is simply my personal preference, having played both the mostly event-driven MMORPGs of yore and the quest-driven ones that are popular now.

Not sure what libraries you are using for TTF support. I don't use SDL (at the moment) so if it's natively supported, ignore me. I personally use the "freetype2" library in my engine - which works very well

I'm using Pygame's font object which I'm pretty sure uses SDL's text rasterizing which I'm pretty sure uses freetype2.

Anyway. There's something I would like some opinions on, especially from people who have worked with Qt, but anyone will do. Before I started working on implementing my own GUI a little over a week ago I'd spend an entire day researching various libraries to do my GUI for me. None particularly stood out (I'm picky, what can I say?) save for Qt. Of course with the licensing and having to buy the software per platform that was right out the window.

Well, as you may have read in the general forum, Qt is going to be licensed under LGPL. Which means I could use it after all! The big advantage to Qt is that it supports rendering widgets into an OpenGL scene. What this means is that I can (possibly) integrate Qt for GUI inside my game, and not have to spend god knows how many hours writing my own GUI behaviour.

There's bound to be drawbacks though. I've personally never worked with Qt, so I'm not sure how cumbersome integrating it would be. Since this isn't a normal case of integration, I'm afraid it might be very hard. On the other hand, writing your own GUI library isn't exactly easy either.

The other drawback is that obviously Qt's GUI isn't made with my game in mind. It might not look pretty, and destroy immersion. Also I'm not sure about theming, Qt can be themed but I somehow doubt it'll be quite as easy as creating a TGA file and editing an XML.

So, thoughts? Opinions? Anything?

EDIT: I've created a poll for this over on the Purple Pirate forums. Feel free to comment here, or vote there.

 

[sindbad]

Qt is without doubt the best GUI toolkit available at the moment. You will love using it.

You could try basing your entire game on Qt since it has pretty much everything SDL has. It's bigger though and less used for games.
However, that may involve quite a bit of rewriting. If your renderer uses just PyOpenGL, it shouldn't be all that hard.

Making a new style involves a certain amount of programming, but existing ones can be customised more easily.

If you only want Qt for your in-game GUI and don't plan on taking advantage of it's other functionality (phonon comes to mind), you would probably be better off just using one of the pre-made pygame GUIs for size alone.

 

[PokeParadox]

Looking good!

"Go Go Eniko!"

 

[BenTolputt]

Honestly, I would recommend against using Qt for the in-game GUI. The needs of a user interface inside a real-time game are very different to that for a desktop-based application (where Qt shines).

In fact, given Pandora's input interfaces, the less explicit "window-based" user interface there is the better. As such, I would recommend you stick with one designed with gaming in mind. One of the better ones I have come across is CEGUI.

 

[echisketch]

I love you for putting a solid effort into this.

The graphics have a great pixel art style, and classic gaming charm.

Best of luck, when I get my Pandora - and if your project takes off, I might be willing to host a Western Canadian server.

edit
Its up to you, but in my opinion having the game at its current diagonal eagle eye point of view, but allowing 8 directions of movement (Think Diablo 2). And allowing touchscreen (point and click command) as an option for movement would have a great impact in various aspects of the game (mostly PvP)

CODE

\ | /
<- ->
/ | \

 

[Eniko]

edit
Its up to you, but in my opinion having the game at its current diagonal eagle eye point of view, but allowing 8 directions of movement (Think Diablo 2). And allowing touchscreen (point and click command) as an option for movement would have a great impact in various aspects of the game (mostly PvP)

CODE

\ | /
<- ->
/ | \


Allowing 8 directions of movement instead of only 4 is still up in the air. One reason I chose isometric view is that you only need two directions per frame of animation. Compared to top-down thats a 33% workload gain. Adding in 8 directions of movement would mean increasing from 2->5 directions per frame of animation, a workload increase of 250%.

There is the possibility of allowing it without adding additional artwork though, and support for moving 8 directions is already in the engine. I just need to figure out whether that looks okay enough to be desirable, and stuff like attacking would still be only in 4 directions.

 

[bencoder]

Hi Eniko,

This is kind of off topic but I'm just wondering, before I start my own project, you said you're using pyopengl, is that definitely going to be compatible with the Pandora? I can't find any clear references that pyopengl supports OpenGL ES. I might be missing something though, is ES just a subset of OGL, and as long as I don't use the removed features it'll work fine?

thanks for any help/references you can give me for this, your game looks great by the way.

 

[Eniko]

I can only say that I definitively do not know. This has been an issue for me as well, but I'm keeping my project OGLES1.1 compatible and so it shouldn't be too much work to get it working on the Pandora if and when I figure out about Python bindings against OpenGL ES.

And yes, ES is a subset of OGL. From my understanding so long as you stay with stuff thats OpenGL 1.1 or 2.0 compatible you should probably be fine for using the same stuff on OpenGL ES. So a few things you want to avoid are glBegin and glEnd and well, basically everything associated with that like glVertex3f, display lists, etcetera. If you implement all your rendering functionality yourself using GLSL shaders you'll be 2.0 compatible (2.0 lacks fixed functionality) and otherwise just make sure to use vertex arrays or FBOs to stay 1.1 compatible.

Can't give you more advice than that, since I don't actually know yet myself. I figure I'll figure it out when I get there.

 

[AireTamStorm]

Can't give you more advice than that, since I don't actually know yet myself. I figure I'll figure it out when I get there.

Admittedly I'm much more green in Python than C, but I've had a really hard time squeezing performance out of Python. I'm running on a Quad Core system with loads of memory and things seem sluggish, so I'm really worried about a disaster once I move my code Pandora-side. Think I'm better off just sticking with C?

 

[Eniko]

Can't give you more advice than that, since I don't actually know yet myself. I figure I'll figure it out when I get there.

Admittedly I'm much more green in Python than C, but I've had a really hard time squeezing performance out of Python. I'm running on a Quad Core system with loads of memory and things seem sluggish, so I'm really worried about a disaster once I move my code Pandora-side. Think I'm better off just sticking with C?
Not necessarily. While Python can be a bit of a pain because you need to know how some things work to get optimal performance it does - once you get into it - let you rapidly develop stuff. Way faster than, IMHO, C does.

For one thing when I just switched from Pygame's 2D rendering to OpenGL my rendering slowed to a crawl. Why? Because I was building the vertex array every loop through. I use the struct module to pack the vertex/uv/etc data into a cStringIO object, which is about as good as it gets (I think) but it still had overhead. But then, you hardly ever need to do that every loop through, just keep what's static.

I was also calling glVertexPointer and glTexCoordPointer for every quad then calling glDrawElements. The former two are incredibly slow and there was no real reason to set them for every quad, that's when I started writing everything to be drawn into a cStringIO object as explained above before making these calls once. Major speedups.

Similarly glBindTexture was being called for every sprite. This is also slow. Using sprite and tile sheets, or like I did runtime packing of the images into one large texture, greatly reduces how many times you have to call glBindTexture. If you turn on the depth buffer and add a depth value to every quad you write into the StringIO object you can use glBindTexture once per texture you have then draw all the quads that use that texture in one go.

And so on and so forth.

Of course, there is just stuff you can't get away with. Something like iterating over every pixel in an image and analyzing and changing colors just never will be fast enough in Python. Of course, why would you even want to do this? Additionally, if you do need to do this you can create a C extension to do it.

Long story short, there's no reason why you should be pressed for performance on your rig using Python unless you're doing something highly computationally intensive that it just isn't suited for. I suggest reading up on how to get performance out of Python, because knowing what might be slow and what probably isn't is definitely the key to your problem.

 

[logokas]

If you want to figure out what's better, 4 way or 8 way movement, then i suggest you play two games that each use one of the movement rules.

Experience will show you that 4 way is more annoying to use than 8. It will make traversing wide area maps very ineffective, because in some cases, diagonal routes are faster, and you'll effectively find yourself trying to 'staircase' your way through.

Yes, it does mean you'll be creating twice as many sprites if you use 8 angles, but the results will be more satisfying.

 

[Eniko]

Yes, it does mean you'll be creating twice as many sprites if you use 8 angles, but the results will be more satisfying.

Oh I'm sure it'll be more satisfying. But what's satisfying isn't the key issue here, what's realistic in terms of workload for me to be able to get done is. Just pointing that out here, if there is only 4 way movement then it won't be done because it's better, it'll be done because it'll let me get things done.

 

[dekutree64]

Yeah, I'd say go for 4 way, then add 8 way later on if you're not swamped with regular bug fixing and balancing type work (Logokas, it's actually more than 2x the work, because up and down can't just be mirrored).

Or maybe only do walks/idles in 8 directions, and snap to an angle for attacks and other animations.

 

[audovoice]

You could do what the old nes and snes games did. That being, allow sideways movement but just keep showing the move left and move right animations. It sounds dumb but River City Ransom did it and you would not think any thing about it. A lot of other side scrolling fighting games are the same.
http://www.youtube.com/watch?v=goQlPC5wOic

 

[Eniko]

I've certainly considered that, and it would probably look okay. That still leaves the question of 4-directional attacks or 8-directional. Now, of course, Ragnarok Online had 8-directional movement and only 4-directional attacks, but it was also less tile bound. I'm not sure how good and/or bad this would look, honestly.

So basically 8-directional movement is likely (probably without extra art though) and combat is still iffy on whether it'd be 4 or 8 directions, and won't have additional art either.

 

[audovoice]

4 directional art would probably be a good idea, but probably only some of the art would need to be 8 directional attacks even if you went that case. The attack animations for some of the attacks might already appear to strike a wide arc (sweeping attack from up, to up-right, then right) but that might be stretching what can be easily animated and still look right. If you had to rework something it would of course defeat the peruse of doing 4 directional in the first place. But if a sorcerer type character did a sailor moon kind (ie your basic charge up attack) then the direction of the resulting fire balls or whatever would not matter, there would only be one animation to an attack like that.