Temple of The Roguelike Forums
Development => Programming => Topic started by: valianjuan on October 08, 2007, 08:30:11 PM
-
Well, thought it was worth posting what I was working on... :D
http://sourceforge.net/projects/beggar (http://sourceforge.net/projects/beggar)
-
Gave it a quick try today. Maybe you should mention a bit about your project, dont be shy, RL developers always need to do self promoting to begin with.
Another java RL in development...
For some reason I like the name, but why did the beggar chose to don a helmet and hack the poor helpless slimes apart? :)
Look forward for more development in the future.
Please no default full screen, seriously messed around with my desktop. Leave it as an option.
P.s Do slimes really breath? :)
-
Well,
I actually have a story written out in my notebook, but I figure I need an engine at least to put it in! ;) (Hence the slimes for testing. I mean, isn't an rpg that starts with you battling slimes classic?)
The basic bit o' it is that a beggar watches as a powerful (but old) wizard guns down a fleeing thief. Once dead, the wizard has a heart attack, leaving behind a mysterious item that puts you on a serious quest, because upon picking it up, you find it's cursed.
It's tile based, written in java, and will at some point have a full-featured :-\ xml input scheme that lets you write your own mods. I was greatly inspired by IVAN and hope to expand on some of the features in that game.
I'm working on various screen resolutions/full screen options now. That will be the 0.5.0 release. 8)
-
Well,
I actually have a story written out in my notebook, but I figure I need an engine at least to put it in! ;) (Hence the slimes for testing. I mean, isn't an rpg that starts with you battling slimes classic?)
The basic bit o' it is that a beggar watches as a powerful (but old) wizard guns down a fleeing thief. Once dead, the wizard has a heart attack, leaving behind a mysterious item that puts you on a serious quest, because upon picking it up, you find it's cursed.
Ha, take that stupid wizard!
It's tile based, written in java, and will at some point have a full-featured :-\ xml input scheme that lets you write your own mods. I was greatly inspired by IVAN and hope to expand on some of the features in that game.
I noticed the IVAN influence ;)
Good luck!
-
Just put up a new version w/ options for screen resolutions. ;D
-
And now with random map! And varied terrain.
-
Ha, development rush :P
-
I think it's an awesome project.
-
Thanks! :D
I like it. I just put up a version with much harder slimes. I think I'll have to implement resting for new releases... Too easy to die.
Also working on an xml parser, that will take a while, but then I'll be able to add content much more quickly.
-
You should probably check DOM, JDOM or SAX, I've read they have Java API's. I've worked with DOM for Python, and it's nice:) It's terribly easy to use - just tell it the file you want to open, and it'll give you access to a node which is the root of the XML "tree". Just browse the children and you're done!
I hear SAX isn't tree-based.
-
SAX is event based, which is nice for big XML streams too expensive to load in memory as in DOM
-
I saw sax but wasn't thrilled. Besides, I think the game runs better the more I can preload. Real time loading is slow for java, methinks.
I will check out DOM though. If it it saves me coding time, I'm in! 8)
-
Heh, cool!
From my (small) experience using DOM, you can pretty much just load the XML file you want into a "DOM" tree. Then, go through it recursively, putting everything you want in YOUR data-structures to ensure efficiency. Just get rid of the XML tree once you've got all the data, and the pre-loading's done :)
Not sure what the DOM java API looks like though, so I can't give you any pointers :\
-
After a little reading on my break I think JDOM is best. I can preload, and the code is minimized. SAX comes preintegrated as does DOM, JDOM just makes it easy to read and write.
-
One disadvatage of XML is some data is better handled as tabular data instead of tree structured, specially for human edition (I am talking about for example monster and item stats, which you may want to sort out, filter, etc). Best thing to do is using both things at the same time and link them via entity IDs.
-
I'm not sure I understood what you just said. :-\
Anyway, as an update, I've got the parser running using JDOM. ;D Now i just have to link the parser with the game... ??? not so easy as my xml is more robust than my engine... :P well... hopefully by the end of the week. :-*
-
I believe what he said, and what I sort of suggested, is that you don't link to the parser directly. A tree isn't really the best way to have all the information about your game. There are more efficient ways of accessing information.
Also, making your engine depend on JDOM primitives might not be a good idea. If some day you want to change JDOM to something else, all you need to do is rewrite the one function that gets all the data from the XML tree, and puts it in the according datastructures, within your classes.
If you have JDOM primitives (nodes, I'm assuming) scattered all over your classes, it'll be a pain.
So, I guess the suggestion is: use JDOM as an interface to get all the hard data out of the XML. Copy that data over to your classes, and dump the JDOM XML tree.
-
Ah! I see what you're saying. :)
I preloaded everything... meaning I parse the file, translate it to a game class that acts like a database for me.
So, I believe I got it! ;D
-
Well, that's not quite what I meant, though that's true too :P
I mean, when you get to the point of assigning meaningful (and balanced) stats to your items and monsters, you will have a better time if you process the data in a spreadsheet instead of having a flat text file as in XML, as you can apply functions to each entity stats, and get to compare each one stats in-between.
-
That is a good point! :D
It would be a great deal easier to do it in a spreadsheet from the client side. Hmmm...
I'll have to ponder on that one a bit.
Here's a question for you though,
If you were write a game where the game files are easily manipulated (as in where monster stats are kept in a spreadsheet or XML) would you give up some of the fun parts of say, maintaining a high score list? Does it matter and will people get around it regardless?
-
Highscores wont be compatable with anyone elses but the important part is that the player can see improvement, and judge success by the final result. I doubt it that most people will modify the data files regularly that much anyway.
-
Finally stable enough to put up an update! :P (www.sf.net/projects/beggar)
Check out the xml and cvs inputs (Thanks slash :D and everyone else)
The next order of business is to allow switching between maps... (coming soon!)
-
Here's a question for you though,
If you were write a game where the game files are easily manipulated (as in where monster stats are kept in a spreadsheet or XML) would you give up some of the fun parts of say, maintaining a high score list? Does it matter and will people get around it regardless?
Well, my high score lists are plain text files up to now :), I regard trying to protect it as something unneeded
On the other hand, I use encrypted XML for data files
-
:D Version 0.5.0!
The xml inputs are working pretty well with my initial tests. We'll see what comes up after a start trying to flex the parser muscles. Also added resting blah blah ... etc etc
I think the slime game I made for testing might become a game in it's own right. Or at least a minigame. ;D
www.sf.net/projects/beggar
-
:D Expanded the slime game for fun! (v. 0.5.1) ;D
With it came some of the features I've been meaning to put in, but didn't have the motivation until now.
-
Guess I hadn't posted in a while. ::)
Has anyone here tried the game recently?
Any suggestions?
Thanks!