ID:55193
 
Keywords: dbo2, engine, soulreaper
Well, man it's been a long time since I've made a post about my SoulReaper Engine, although I'm still working on it constantly. For those that aren't aware of what SoulReaper is, it's a game engine I'm building using the BYOND DM language. Currently SoulReaper is being used to power the DBOII (Dragonball Online II) game, although in the future I wish to be able to use it for other games as well, (a good RPG would be nice). Recently I've been working hard on the GUI code and I've completed most of it. Here is a screenshot:

GUI In Action


The reason for all the radio buttons is because the GUI supports two types, vertical and horizontal layouts. I should note that the gui isn't a browser window or anything, it's using the map to render it's graphics. Also, it's using pixel coordinates and can be of any dimension. The GUI isn't completed yet, there's still more I wish to add, but it's getting close to a final version. My inspiration this entire time too has been Acheron's Awakening gui system, it looks amazing and for those who haven't seen it you should really check it out here: Acheron's Awakening

I also thought I'd provide some code to show you how simple it is to make GUI windows using the SoulReaper engine. (Sorry if my code looks weird...)

/**
 *      This class is a Test window with GUI elements.
 *
 *      @author:        Victor Holt
 *      @date:          3/05/2009
*/

SoulReaper/Object/GUI/Template/TestWindow
        var/SoulReaper/Object/GUI/Element/Window/wnd = null
        var/SoulReaper/Object/GUI/Element/Window/Button/closeBtn = null
        var/SoulReaper/Object/GUI/Element/Window/Edit/strEditBox = null
        var/SoulReaper/Object/GUI/Element/Static/strText = null
        var/SoulReaper/Object/GUI/Element/Static/spinnerText = null
        var/SoulReaper/Object/GUI/Element/Static/imageText = null
        var/SoulReaper/Object/GUI/Element/Image/testImage = null
        var/SoulReaper/Object/GUI/Element/Window/CheckBox/testCb = null
        var/SoulReaper/Object/GUI/Element/Window/CheckBox/testCb2 = null
        var/SoulReaper/Object/GUI/Element/RadioGroup/rG = null
        var/SoulReaper/Object/GUI/Element/RadioGroup/rG2 = null
        var/SoulReaper/Object/GUI/Element/Spinner/spinner = null

        /**
        * The constructor.
        */
        New()
                wnd = new()
                closeBtn = new()
                strText = new()
                spinnerText = new()
                imageText = new()
                strEditBox = new()

                ...

                wnd.create( CHARACTER_VIEW, "GUI Test", 250, 300 )
                closeBtn.create( 2, "Close", 80, 30, null, wnd )
                strText.create( 3, "Strength:", 5, 260, null, wnd )

                ...

                rG.create( 6, GUI_VERT_STYLE, wnd )
                rG2.create( 7, GUI_HORIZONTAL_STYLE, wnd )
                spinner.create( 8, 20, 30, wnd )

                rG.addOption( "Male" )
                rG.addOption( "Female" )

                rG2.addOption( "One" )
                rG2.addOption( "Two" )
                rG2.addOption( "Three" )

                ...

                GUIServices.register( wnd )
                ..()
        /**
        * The destructor
        */
        Del()
                GUIServices.unregister( CHARACTER_VIEW )
                ...

                ..()
        /**
        * This method renders the gui template.
        */
        render()
                GUIServices.render( CHARACTER_VIEW )
        /**
        * This method does a listen event.
        */
        onListen( var/userGuid )

                ...

                ..()


Cant wait to use it Victor! :)
Yeah, the next DBOII alpha testing with this gui system should be fun... hope we find all the bugs in it before DBOII's release!
Just out of curiosity... Why go to all the effort of making a GUI like that when you could have done the EXACT same thing with BYONDs interface... Only with a fraction of the effort.
Using interfaces would also make editing and changing things easier, and would be much more efficient to use. It would also provide much more flexibility if your example code is anything to go by.
The Magic Man wrote:
Just out of curiosity... Why go to all the effort of making a GUI like that when you could have done the EXACT same thing with BYONDs interface... Only with a fraction of the effort.
Using interfaces would also make editing and changing things easier, and would be much more efficient to use. It would also provide much more flexibility if your example code is anything to go by.

I won't argue the point of effort and flexibility, but to be honest... I just don't like the BYOND 4.0 interface.

*Edit*
I should correct myself on what I said above. I don't like their interface for in-game content. I do however love their interface tools for making things such as editors and whatnot for various BYOND applications. For instance, I intend to make a game editor for SoulReaper using the BYOND 4.0 interface tools.
Masterdan wrote:
http://en.wikipedia.org/wiki/Scope_creep

Please don't post your ignorance... Ask questions if you don't understand something.
Why would you reinvent the wheel. And how long do you intend to take to make this game when it is currently slated as version 0.0.35?

What is the point of this? why wouldnt you use the tools that BYOND already has for interfaces, what is the big advantage of the soulreaper engine that you have derailed development of DBOII for like 2 years to focus on this engine instead? Why do you call me referencing scope_creep, a completely relevant criticism, as ignorance?

I dont mean to break balls, this would be neat if it wasnt completely out of the scope of what you really should be doing to develop the game. Im criticizing you not for your programming or whatnot, but for your project management skills. You need to get a realistic smaller scope so you can actually get this thing moving. You are not going to have all the time in the world to work on this game.
Masterdan wrote:
Why would you reinvent the wheel. And how long do you intend to take to make this game when it is currently slated as version 0.0.35?

What is the point of this? why wouldnt you use the tools that BYOND already has for interfaces, what is the big advantage of the soulreaper engine that you have derailed development of DBOII for like 2 years to focus on this engine instead? Why do you call me referencing scope_creep, a completely relevant criticism, as ignorance?

Awesome! Good questions!

First, SoulReaper is a completely separate project from DBOII, and is being developed separately. As far as the GUI update goes, it's completely optional whether or not you wish to use this feature. If you're creating a game with SR you can still use the BYOND interface tools..., I prefer not to but weather or not DBOII does is a decision the team will have to make ultimately.

Furthermore, before I was asked to help out on the DBOII project, I had already begun developing the SoulReaper engine, which has always been my primary focus. I'm not sure if people know this or not, but I've been developing SoulReaper far longer then I have been on the DBOII team, and that is my primary focus.

The point... well to add a blog post concerning my SR engine! =) I think I can do that... wait, I know I can do that!

Finally, I called you out because you should have posted a question, not make vague references... If you don't understand something ask a question my boy! I very much appreciate you asking questions rather then throwing vain insults. Be respectful.

Oh yeah, once again, thank you for your questions. ;-)
Ehh, I suppose i was "Confused" because the title bar says DBOII and not Soul Reaper. I was under the idea that this was in fact an integrated part of DBOII as soul reaper updates have been passed off as DBOII updates. Also, I dont know about the "my boy" comment, Im not sure how old you are, but youd best be a great deal older than 21 to be making comments like that.

So, wait. I thought you were the primary coder to DBOII, if its not you then who is it?
Masterdan wrote:
Ehh, I suppose i was "Confused" because the title bar says DBOII and not Soul Reaper. I was under the idea that this was in fact an integrated part of DBOII as soul reaper updates have been passed off as DBOII updates. Also, I dont know about the "my boy" comment, Im not sure how old you are, but youd best be a great deal older than 21 to be making comments like that.

So, wait. I thought you were the primary coder to DBOII, if its not you then who is it?

I guess I can give you a hint of my age... I own a BYOND key called progman84.

The confusion is understandable though, because SR updates do end up on the DBOII forums and blog updates. Although SR is completely independent of DBOII, and exists on it's own as a set of tools to build a game. Also, the title of the window is actually determined by a config.xml file. I guess the best way to describe this is here: http://dboteam.com/resources/goten84/soulreapercode.png

There's a bootstrap file that you would setup to tell SR which Mod(s) to load, and from there it runs the game. In the link you'll see that DBO2 is a mod of the SR engine, which could easily then be replaced with Naruto Universe, Naruto GOA, or any other game. The whole point of SR is to provide tools for people to create games with, but whether you use every feature provided in SR is up to you.
Are you planning on releasing Soulreaper?
Masterdan wrote:
Are you planning on releasing Soulreaper?

I do hope be able to release SoulReaper, full source and all so that people can improve on it, and perhaps optimize it in places that I've overlooked. I do need to work on some documentation though rather than relying on my code comments. I'd also like to provide an editor for people who just want to make mods really quickly without doing too much work with coding. A lot of content is driven through xml files and creating new content is mostly just a matter of editing the xml files.
Hmm, if you bundled it with good documentation and a good example "mod" then this could come to be useful. Assuming it is easy to use.
Masterdan wrote:
Hmm, if you bundled it with good documentation and a good example "mod" then this could come to be useful. Assuming it is easy to use.

Yeah definitely. I'm really trying my best to make sure the code, (especially the mod portion), is easy to work with and to understand. And your right, providing some good examples will be a must!
I still don't understand.

This looks like alot of work for something that was much simpler than this.

Give me an example (in non-coder lingo) of why this is better. Why exactly is it better than the norm?
I can see both sides of this. There are a lot of particulars with the 4.0 interface that you can't control (rendering styles (how the control looks), behavior (how the control is manipulated), or custom controls of any type), and you'll hafta wait for T&L to implement that functionality if you want it with 4.0.

My experience with map-rendered controls, tho, has been that your gains will quickly turn to losses if you've got a lot of them on all screens at once. The client.screen rendering just doesn't seem to be able to handle a lot of these going on with DM's thin client (Ah, if only there was a javascript for the DS). It does seem like most of your needs could be handled with browser controls, at least, but I totally understand your desire to make your own.

Are you using overlays to hold each tile of the dialog or actual objs for each one?
TheMonkeyDidIt wrote:
I can see both sides of this. There are a lot of particulars with the 4.0 interface that you can't control (rendering styles (how the control looks), behavior (how the control is manipulated), or custom controls of any type), and you'll hafta wait for T&L to implement that functionality if you want it with 4.0.

My experience with map-rendered controls, tho, has been that your gains will quickly turn to losses if you've got a lot of them on all screens at once. The client.screen rendering just doesn't seem to be able to handle a lot of these going on with DM's thin client (Ah, if only there was a javascript for the DS). It does seem like most of your needs could be handled with browser controls, at least, but I totally understand your desire to make your own.

Are you using overlays to hold each tile of the dialog or actual objs for each one?

Yeah, one of my first implementations for SoulReaper was to have a really easy to use browser/page system so that people could quickly use the browser for their GUI needs. I agree with you, most of your needs could be completely handled with browser controls. Here's a very early screenshot of SoulReaper almost two years ago: http://everfluence.com/narutou/Art/gamescreen3.png It uses browser controls for the character creation portion.

With the map-rendered controls I wanted it to be easy to create things like huds, or splash screens, and I've even seen people do more extensive things with map-rendered controls lately (Talent Trees). I really wanted to provide that feature for those who use them. I haven't (yet) experienced any major issues with rendering the graphics. Most of the objs (I use a combination of client objs/overlays) are reused for each client, so I'm not creating tons of new objs each time a player logs in. There's an InputListener class which handles who clicked the object and how that object should respond and render for that client... That's the best I can do so far for those that want to use map-rendered controls. :)
Goten84 wrote:
http://everfluence.com/narutou/Art/gamescreen3.png

Nice. Pretty-good UI. Weird cutoff on the left hand side of the frame, tho. Which reminds me that the browser itself can be painful enough to write a UI in.

(I use a combination of client objs/overlays)

Yeah, almost every alternate map and/or hud setup I've used relied on overlays. I came to find out later that, not only are certain parameters in overlays irretrievable after placement (like the icon if you use icons (you can retrieve that if you use /images), or pixel_x, y), but that they're slower to place and, strangely, sometimes update asynchronously.

I say they're slower to place relative to using actual objs to hold tiles because I ran a test profiling the two. It may have been other factors in the test environment, but objects updated/rendered much faster.

I say they're asynchronous because I had a problem with setting overlay icons that would only show up on the map after a small delay. Strangely (or not when you think of it), if I set the icon of the object the overlays were attached to at the same time as setting the overlays, the update was immediately apparent.

There's an InputListener class which handles who clicked the object and how that object should respond and render for that client...

Cool. I like listeners and handlers - they make things easier to organize.
Cool! That's quite impressive. The code in particular, is neat and simple. Frankly, I think you're the first here to create an engine of such scope.

Have you considered releasing its, or some of its features, source code? More than sating my curiousity, I think it can be a valuable contribution to the devsphere here... if only as something to learn from, or a big asset to game development.

Edit: Oh, it seems someone has already asked you about this! I misread some of the comments... sorry! Allow me to change the question then, as not to be redundant: when will you release it? ;-)
Page: 1 2