Mmorpgm


both lumina and javajake's project are interesting, but what ARE your goals with them? will they eventually be capable of things like transparent overlays, multiple levels of scrolling, high quality character animation, higher resolutions (like 800x640)?
also, what kind of sound software is planned for lumina?

to javajake, i would suggest using a mod based library (not mikmod tho!), it should at least be capable of .xm playback, .it is nice, but its much less supported by such libraries.
with a mod playback library, it would be simple enough to mute/unmute/change volume of each instrument in the song, or even change the tempo, to change the song based on where your character is.
im really not sure what the best library would be, ill do some checking around tho.

id love to write music for a pandora rpg project, i could probably help out with graphics as well if they are pre-rendered cgi type...
i love a well done top-down rpg, but i wouldnt want it to end up looking like a nes port -_-
 
Well my goal, in the beginning, was to create a game.
I did however come to the conclusion, that if I made a game engine which was capable of running the game I wanted to create, others who did not have sufficient programming skills, or just did not want to bother with programming would be able to create games using lumina.
The end goal, is still to create a game using lumina.

In terms of technical goals for the engine;
I'm not entirely sure what you mean with 'transparent overlays', If you mean being able to have, say trees that you can walk behind and on certain spots see trough, then it is earl ready implemented.
If you mean transparency as in partly transparent, then No, I have no plans to implement this right now, but in the future, who knows?

As for resolution, it should be able to run in most resolutions.
I have tried to run it in 120x96, 320x240, 640x320, 640x480, 800x480, 800x640 and 800x600, all successfully.

I have not decided on what formats the engine will be able to play, but im guessing the most common , and I can guarantee wav playback.

multiple levels of scrolling is really only objects with different moving speed or layers of different moving speed modifiers.
It is not yet implemented, but is on my "todo soon" list.

high quality character animation is more up the artist, no? :)
But the engine can handle objects of reasonable size, at 24bits depth (no alpha/alpha ignored) and they can have any ammount of frames and looping frames.
I have plans on expanding the capabilities of the engine on this front before the next version (0.6)
 
Don't know if anyone still reads this thread (I just found it).
Wanted to add another FOSS (zlib license) project that aims at creating an RPG toolkit: Mokoi Gaming
It's still in development and advancing slowly, but it's very promising. It has a nice visual editing kind of IDE called Alchera, and an engine called Lux.
It's aimed to be VERY portable, GP2X is a future target and right now there's work on a DS port.
It would be nice if more developers would support this project.
 
Wow. Quite the selection... where do I go? ;)

I'll look into all this thoroughly within the next few weeks. The IRC bot I mentioned earlier is finished, and a surprise report from another project is tying me down at the moment.
 
Finally, I've completed my other projects, and I'm ready to go. So, here's what I think of the three projects mentioned so far:

Mokoi: I really really like the cross-platform, scripting idea. However, I didn't have easy scripting in mind: they rely heavily on C++ programming. Also, since it is more low-level to allow for any type of RPG, it requires more programming. It seems very cumbersome to have to write up some of the back-end code to support each RPG you create. I say this with games like the first Zelda games and Pokemon in mind. I'd rather have the system become more specialized and provide quick and easy functions like "Talk", "Shop", etc.

CACK: It segfaults when I run it in Linux. No doubt it was meant for the GP2X, but I wish I could run it on my system as well. The code is also undocumented, making it very difficult for me to navigate as a newcomer to C. Without anything running to toy with, it makes it all even harder.

Lumina: I can't say anything, because there is no code to look at and no way for me to test the game. It's rather unfair, really, that I have to pass over this project, but I have no alternative.

So, it's a rather disappointing outcome for me. I thought there'd be some project for sure, but nothing provides the feature-set I'm looking for. No doubt I'll be pulling code from these and perhaps other projects for my own, but it's too bad these projects didn't satisfy me right off. :(

This is still open for discussion, but in the meantime planning for MMORGPM development has begun.
 
javaJake said:
Mokoi: I really really like the cross-platform, scripting idea. However, I didn't have easy scripting in mind: they rely heavily on C++ programming. Also, since it is more low-level to allow for any type of RPG, it requires more programming. It seems very cumbersome to have to write up some of the back-end code to support each RPG you create. I say this with games like the first Zelda games and Pokemon in mind. I'd rather have the system become more specialized and provide quick and easy functions like "Talk", "Shop", etc.
As developer of Mokoi Gaming, I would like to say thanks for you feedback. I like to point out that games are entirely written in a scripting language and the code can easily be shared, reused and soon created. This allows for flexibility, but since this isn't what you're after, good luck with your search.
 
Last edited by a moderator:
I think I've decided on a reasonable scripting language and a parser that can be extended for new vocabulary.

The entire language is based on BASIC, but reworked to fit in. Here's some sample code:
CODE

CHARACTER Enemy1:
#the parser uses particular pre-determined variables, in this case "SOUTH", "NORTH", etc., for certain things in the game
USE pic1.bmp FOR SOUTH #SOUTH could also be south: variable cases might not matter in the end
USE pic2.bmp FOR NORTH
USE pic3.bmp FOR WEST
USE pic4.bmp FOR EAST

#shortcut commands above, lengthened commands below:
#ATTRIBUTE front_pic IS pic3.bmp IF Enemy1 direction IS NORTH
#or even longer:
#ATTRIBUTE Enemy1 front_pic IS pic3.bmp IF Enemy1 direction IS NORTH
#however, the parser assumes local variables if no more than one variable name is supplied

#note that in some cases, the USE syntax doesn't sound right:
#USE false FOR cool
#this is a case in which the synonymous attribute command could be used:
ATTRIBUTE cool IS false
ATTRIBUTE strength IS 10 IF Enemy1 cool IS true
ATTRIBUTE strength IS 10 IF Enemy1 cool ISN'T true

USE pic2awesome.bmp FOR NORTH IF Enemy1 cool IS true
#note if clauses can be appended on the end of just about any command as a shortcut and for, most importantly, clarity
FINISH Enemy1

CHARACTER AverageJoe:
USE niceguy1.bmp FOR SOUTH
USE niceguy2.bmp FOR NORTH
USE niceguy3.bmp FOR WEST
USE niceguy4.bmp FOR EAST

#Game is an object already defined, and has its own mutable attributes.
USE AverageJoe FOR Game Player
#could also be:
#ATTRIBUTE Game player IS AverageJoe
#either sound fine and act the same way
FINISH AverageJoe

#note that this next clause commands can access objects without the word "Game" like AverageJoe clause did
TRIPWIRE ACTION attack IF Player WITHIN 5 PACES OF Enemy1:
#other example: ACTION attack IF Player RIGHT 5 PACES OF Enemy1:
#didn't make it. :)
ATTRIBUTE Game player life IS 0 #Game has its own "tripwires" that will call ACTION GameOver
FINISH attack

ACTION GameOver:
#note the lack of quotes.
DIALOG narrator SAYS Your character didn't make it. < WAITFORUSER > < CLEAR > Well, better luck next time. Just remember, your enemy's strength is < ATTRIBUTE Enemy1 strength >
#the < > mark dialog commands. Within these brackets any single command may be executed.
#WAITFORUSER is a pre-defined command that asks the user to hit a certain key to continue.
#CLEAR removes any existing text from the dialog.
#ATTRIBUTE is self-explanatory
#an action can also be called
FINISH GameOver


#actions will probably have arguments, though we'll wait and see on that one.

#using this syntax, the game will hopefully provide enough functionality for any game.



This is a last resort. I really don't want to code my own parser, so some heavy research will be done prior to coding this. :p

Edit: In fact, I may rip apart a real BASIC parser and just add my own functions.
 
luke said:
I like to point out that games are entirely written in a scripting language and the code can easily be shared, reused and soon created. This allows for flexibility, but since this isn't what you're after, good luck with your search.
Would you mind explaining? My foggy mind didn't catch the full meaning of this post. :p
 
Last edited by a moderator:
javaJake said:
luke said:
I like to point out that games are entirely written in a scripting language and the code can easily be shared, reused and soon created. This allows for flexibility, but since this isn't what you're after, good luck with your search.
Would you mind explaining? My foggy mind didn't catch the full meaning of this post. :p

you mention "they rely heavily on C++ programming.", while the engine is coded in C++ (looking into others), it's games are entirely written in a scripting language called Pawn. While there is a initial outlay of coding (like any projects), it can be shared, reused, and soon create via a GUI.
 
Last edited by a moderator:
Since my last post I have decided to almost completely rewrite the Lumina engine from scratch, there was just too much crappy code and I discovered a quiet fatal design flaw.
But if anyone wants to take a look at it, PM me.

The reason for there not existing a linux build is simply since i get some pretty weird segmentation errors every now and then, that seem to be more or less related to what machine I am currently running on.
 
Well, there is ONE thing...

www.stencyl.com

Check this out. From what I understand, THIS is being programmed in Java and runs on all platforms. Only thing is, it's not out yet. But it is a open source project.
 
Nice project. It doesn't replace MMORPGM, but I'll certainly keep my eye on it. :)

Edit: A little more digging revealed the following: "Genre Kits are Kits that span entire genres rather than specific styles of gameplay. We currently plan to develop 4 genre-kits for launch: Platformer, RPG, Turn-Based Strategy and Shooter." The RPG kit could be it! Wow, I'd be so excited! :D
 
bustaballs said:
When you buy Realm Crafter, they give you the source code along with the program.
It's a very cool looking software suite, but it's DX9 / Windows only. Not much chance of getting it to run on Pandora, even with the source.
 
Last edited by a moderator:
Chip said:
bustaballs said:
When you buy Realm Crafter, they give you the source code along with the program.
It's a very cool looking software suite, but it's DX9 / Windows only. Not much chance of getting it to run on Pandora, even with the source.

Still might be useful for making Pandora games on a PC
 
Last edited by a moderator:
PlopperZ said:
Still might be useful for making Pandora games on a PC
The game engine itself uses DirectX. Unfortunately it's just not Pandora (or anything non-windows) friendly.
 
Last edited by a moderator:
bustaballs said:
http://realmcrafter.com/store/home.php - 3D mmorpg maker

When you buy Realm Crafter, they give you the source code along with the program.



No good there. Not only does it cost (this developer right here is a free-or-bust developer) but it's written for Windows and DirectX like another RPG maker was...

Thanks for the idea, but as others have mentioned, it's not going to help too much as far as I can tell.
 
Last edited by a moderator:
OK, it looks like Novashell and the other (closed-source) Stencyl project will replace this project or at least come close. I think I'll play with Novashell and see if I can't get that to work for a decent RPG game.

Thanks for the interest, guys, but it looks like this all comes to naught. :(
 
World forge is an open source (GPL) toolkit to create MMORPG's, the engine is said to be quite flexible and can be scaled down from 3D to 2D or text based for very slow systems. It would be very interesting to have this running on Pandora with a specially tailored client! See...

http://www.worldforge.org/

This would be the thing to create that zombie MMORPG in :)
 
javaJake said:
40w bulb time! :D

So, I've been looking around for something that was like the RPG Maker. I loved that software, but, like Mario Kart 64, once I found out RPG Maker was illegal, I removed it from my system.

Seeing as there's no alternatives, I'm thinking about starting one. Ludicrous, I know, but it is worth a shot. I think it would be great for the Pandora, GP2X, and any other system that can handle 2D grids and maybe some simple animations (if I can pull that off *shiver*).

I've been programming Java applications for over two years now. I'm good enough to the point where I can pick up new libraries, read their API's and docs, and not need any help getting something rolling. At this point, I think I should learn C if I'm going to do anything fun.

So, I need some pointers to start. I can figure out C's syntax and all, but it's the SDL and Pandora bits that get me. I'd like some nudges in those areas, namely, how to code on the PC with SDL so that it ports to the Pandora (and maybe GP2X, though I won't own one) without much fuss.

Also, sound is a given (I'd love to have background music play based on your current coordinates) but the proper libraries to use is not. Linux has about 300^43 choices in sound systems, and I don't have a clue about where I should go to keep the Pandora port realistic.
If you wanted to sum up my post, it'd be: "HELP!!!" ;)



learn C++ :)
 
Last edited by a moderator:
Back
Top