[Project] RPG with GOSU?

[kyonides]

[ignore]The main purpose of this topic is to show you how far I've develop a simple game on Chingu, a pure Ruby framework built on Gosu, that allows you to make it simpler even to make your very own RPG some day...[/ignore]

Here I let you take a look at some screenshots that'll show you how easy it'd be to implement such games on Gosu by telling the game how to show a specific frame set taken from a single bitmap with a single character... So I chose to use Vlad's character file to demonstrate it.

Spoiler: NOW 4 Screenshots

Of course, I had to modify Chingu::Animation class and create my own Hero class (that inherits methods from GameObject) in order to let the game show a single player tile at a time based on what's the last button you pressed...

NEW!!! First DEMO

Version 0.0.5.1

You'll need to run kyogame.rb to start playing / testing...

 

[ippa]

Hola kyonides, always fun to to catch real world usage of Chingu. =)

I see you're used Chingu in some new ways.

I'm curious, how did you have to modify Animation to serve your purposes?

 

[kyonides]

Updated the first post with a new screenshot and a download link!

Well, the hero should be an animation himself... but not like the common animations, so I just created a new child class of Animation, named HeroAnimation (yeah, very creative he he he). It just modifies the initialize method of Animation class.

Later I had to implement a Hero and Game::Hero classes with every single (invisible) feature inherited from a template class AND a movement method, which is the feature that allows me to check both, the animation and its movement. The animation variable is passed from the second child class to the first one and then finally checked in the parent class to make sure it was acceptable. (Maybe I can directly set it up so it's already configure in the first child class... or possibly, I already did that...)

By the way, I also had to modify the push or switch_game_state, because I created classes like the HeroStats game state class that required the Level or Map class to pass a parameter, but it didn't. I first thought I could use the options Hash to solve this, but the values passed straight to the GameState class not the new one I made up... I also noticed that you used something like...

new_state.new if #some conditional statement I just forgot for no good reason...

And it didn't leave any space for parameters not included in the Hash that should be call in the exact moment the class would be created.

The point was I also noticed the push and switch_game_state methods in GameStateManager class were so cluttered up that required the definition of another method to make the code look cleaner, more readable.

There's something I learned about working with Ruby. You might need to create child classes as needed... sometimes, just sometimes, there are several child classes to be conceived...

 

[kyonides]

OK, I updated my first post on this project. Now the game displays a simple HP ring on screen. I also tested the game and now it allows us to include character files if they have the following dimensions:

W * H

96 * 128
128 * 192

 

[kyonides]

Does anyone know why the collision box for the NPC does not match with the NPC graphic on screen?

Spoiler: See The Screenshot

 

[kyonides]

From now on I decide to forget about using Chingu, I'll now only use some things like changing from one game state to another and the animation class. I'll replace them asap or as soon as I get an idea on how to implement my own versions of them.

 

[kyonides]

OK, I wasn't that strong willed(?) as I thought, now I was working on this project and now it's possible to display a simple windowskin on screen just like on RPG Maker, but it doesn't include the pause symbol or some other curious features. The point is that it's now possible, visually you can't notice the difference.

 

[trebor777]

COolio!
Some screens would be nice maybe!

 

[kyonides]

Well, the game is now known as Glanon (it's a codename). It's current version is 0.0.4. Later I'll edit this post to include some screenshots.

Edit...

I added a few screenshots... Remember that this project is at an early stage...

The windowskins (except for the RPG Maker ones) belong to chickendips.

Spoiler

Spoiler

http://img200.imageshack.us/img200/8683/kyogame03.png

Spoiler

Spoiler

 

[kyonides]

Recently I was developing my own RPG Database GUI with Qt Ruby and here you can take a look at the results.

Spoiler

This would only work on your OS if it's an GNU/Linux with KDE as its GUI or if you install KDE in Windows.

 

[BlueScope]

What I see looks like a great step forward to an interesting RPG Maker alternative, however, I wonder if you're copying a bit too much here... after all, you seem to make exactly the same mistakes that Enterbrain did, making the Database a very in-general tool without too many opportunities to really create individual stuff... however, as you're clearly not done, you might develop more into a freedom-oriented version there... for example a basic hask key interface, as follows:

It enables users (or yourself, if you don't want to publicize it) to freely create new values with no hazzle at all, not forcing them to use pre-set values of no significance to their project whatsoever that are causing unnecessary data junk. Instead, you get a sleek interface with the possibility to switch to a Visual Edit mode, showing the window you have posted, to aid inexperienced users with editing, as well as to serve as an integrated learning device, as whatever you'll input will in Visual Edit mode become a data field - or not, if you mess up.
This, in my opinion, is the only way a database can and should be. My Database Flag Reader (linked in my signature, might want to take a look at it) is a good step in that direction already, however with RPG Maker as framework program, it's not possible to achieve maximum efficiency. You, however, are very able to fix what Enterbrain screwed up, so I can only beg you to fix it, as your way isn't going to make anything better...
Also note the '+' tab, Firefox- or IE-style, at the tab bar in the database. Having a fix amount of tabs is as useless as having a fix amount of options, and as everything's freely configureable, a 'add a tab' feature makes perfect sense.
The 'max items' thing could also use an overhaul, as this way is way too complicated. I've bothered to do a simple mockup of a very apparent simplification of the whole deal that would make the life of everyone so much easier...

Please note that all of the above is in no way meant to be offensive or anything... I'm trying to help you out with a concept, as (being an Interface and program designer myself) I've had the urge to punch some Enterbrain designers in the stomach for a long time...
Other than that, keep up the good work, the interface layout itself looks awesome! :D


EDIT: I just remembered Danc writing about turning applications into games. This blog post of his is the kickstarter for an interesting development called Ribbon Hero, which goal it is to turn Office (being quite a complex program series) learning processes into a game. The first linked blog post illustrates design processes of applications, and how they sometimes are just out of place. It's an interesting read for application designers, in my opinion (while I want to also say that RavenTDA called me stupid, as apparently, everything explained in there is common sense to her...)

 

[kyonides]

Actually, the Maximum Items spinbox was exactly what I had in mind at the beginning, but I wasn't sure if it was a good idea to make people accidentally delete almost all of their items or weapons, etc. because they couldn't stop clicking on that box.

What I don't see as practical as you think would be the plus tab. Mmm, the qt ruby binding wouldn't allow me to let people create their own tabs on the fly because it expects the scripter to enter as much info as he or she likes to type before it temporary compiles the app. I'd still need to check that but I don't think I'd be able to include that feature in the script for now.

I've seen the "basic hask key interface" you mentioned in Qt Designer but not as a freely modifiable interface...

Anyway, the GUI was specifically design for Glanon and not any other game, but I guess I should consider to include these alternatives some day if other people get interested in this kind of Qt GUI.

 

[BlueScope]

First of all, I can imagine this as a standalone tool to create databases. This could work for RPG Maker as well, if you write in the default rxdata/rvdata formats, or any other project really that reads data the same way. That way, you couldn't only create an engine that has exchangeable data with RMVXP, but also have a standalone database to edit RMVXP data files and therefore get rid of the necessity of stuff like the Database Flag Reader... sounds good to me, however, I can't put my finger on how hard it'd actually be...

As far as the tabs go, I get why it's a problem... there should be a number of workarounds though, for example... a dropdown menu? Well, basically anything that doesn't require updating the actual GUI elements...
For the max item switch, there's also a few possibilites I can think of, as what you mentioned is true of course. What I thought about when pasting the above picture together was that you'd simply get a message when you'd go below the current max value, however, that'd probably work better with a number input field and a confirm button next to it (however, definately not in a seperate window :p ). I guess getting rid of a number cap and just adding items on the fly would be valid as well, however, that sounds like a huge probability for id errors when deleting items...
Something like that would work alternatively to the hash key interface though... above the list that's showing your entries (clickable, del or right-click => delete removes an entry) is a text field labeled 'key', a text field labeled 'value' and a button named 'update'. Update, because highlighting an item on the list fills the values in the fields, making them updateable. This should be doable with a simple multi-line selection that every GUI should have, afaik... not optimal, but at least a viable workaround ^^

Good luck with it either way! (and I hope you'll release it, I'm interested in the coding :D )

EDIT: Another thing I've always missed in RMwhatever was batch shifting of items, aka move 20 items starting at id=45 to id=15... something like that. Or, even better, change it to something that allows you to insert an item above the current one, and when you delete one, it gets dropped from the list and doesn't leave a free spot, but vanishes altogether - much like the Script Editor list, if you want. Doing it like this would entirely get rid of the max item thing as well as giving you easier file handling (and because of the awesome hash key interface thing, you don't need to do "if item.id.between?(min, max)" either :D )

 

[Dargor]

EDIT: Another thing I've always missed in RMwhatever was batch shifting of items, aka move 20 items starting at id=45 to id=15... something like that. Or, even better, change it to something that allows you to insert an item above the current one, and when you delete one, it gets dropped from the list and doesn't leave a free spot, but vanishes altogether - much like the Script Editor list, if you want. Doing it like this would entirely get rid of the max item thing as well as giving you easier file handling (and because of the awesome hash key interface thing, you don't need to do "if item.id.between?(min, max)" either :D )

I've been thinking on doing this for my own editor. I'll try and investigate the .object_id or .__id__ property because the current ID property isn't a real one, if I may say that. The IDs are based on the database index (so basically they are indexes and not IDs?). If every database entries could have their own hex ID then it would be easy to make a database system independent from indexes. You could easily move any items wherever you want in the list and not scrap everything.

 

[BlueScope]

Taking this a step further, letting the user define that key should work perfectly. It shouldn't be the item's name (as that's a factor that's likely to be changed, and even if not, might be changed by a programmed routine; also, looking back at my list sugestion, Name is one of the modifyable factors, aka could be taken out completely as well - you never know what people will need!), so having a user-set field for the tag/id/whatever you wanna call it would work pretty well compared to an automatically created tag/id/whatever you wanna call it.

This has several purposes: First of all, you're giving the game designer control over the system. If he wants his item named bom_chika_wha_wha, then let him. If he wants to establish a certain addression for items ("You people working for me better stop calling 'Materia' Dragonballs!"), self-defined tags will aid that. Even if none of that applies, a self-chosen name will always be remembered better than whatever chosen-by-the-engine-maker tag.
Second, script systems could work from it. Sorting items by tag, for example, could make use of tags easily if a corresponding tag is chosen. The possibility to create custom item fields somewhat renders this obsolete, however, getting item order done by checking a single field is still more elegant than the other way round, in my opinion - which is the keyword: The more the user can choose himself within reason, the more he'll think the system suits his needs. Derived from that: The more a system is able to adjust to a user's needs, the more likely he'll try to explore it and get better at it (as a side note: within reason means without overwhelming the user - my list provides a very simple interface that allows a lot of self-chosen input and output, meaning it's a powerful device to work with that can be learned within minutes).

PS: I kinda feel bad hijacking this thread somewhat along with you, but well... as we lack a interface and program structure forum (for a reason maybe ^^), I guess this has to do... I really like to think about stuff like that though, and I hope it helps kyo with his system a bit ^^

 

[gerrtunk]

Its a interesting project, i have been testing gosu a little and i like it more than pygame because its more simple. Ruby is slow but we are talking of a library writen with C++ and thats hardware accelerated..

Anyway existing rpgmaker redoing the same thing again in gosu its seems too useles for me, but if you want, no problem.