Contrary to what the Gruedorf may imply...

I have been making games. Starting as a 24hr contest game this sort of ballooned massively. I've actually been kind of avoiding Gruedorf because it seemed to make me less productive having to pump out a post every week and well... yeah. But every now and then it's nice to just sit down and talk about your game.


The name of the game is Hydration 2: Oasis. Long story short, while discussing a contest game to make with one Hachi-Roku of the OHRRPGCE community we came up with an idea that enamored Hachi so much that he made it himself. Flash forward to years later and Hawk wakes up in a sweat with regret. The idea of the game is pretty simple: You're in a desert with limited water. Find some water.



In H2O the desert is randomly generated with a few treasures scattered around and the ultimate goal always lying in the north. Every step consumes some of your water, so deciding whether to risk wandering off for better equipment or to rush ahead is vital. Additionally, using your skills in battle consumes hydration in combat as well so you have to make further conservation decisions there.



You actually pick 3 out of 25 or so skills at the beginning of the game. These are your skills for the entire game. The battle system is a fairly simple affair: At the top of the screen is a bar indicating when you and your enemy's turns are coming up. It's continually moving to the left. Once it arrives, it is your turn. From there you can choose what to do, but everything has a delay on it. If an enemy attacks you during this delay they deal more damage or potentially break your attack. This rule applies to the enemies as well. You can also just guard for a period, blocking any damage or effect. Even attacking and guarding still consume a little hydration, though.

How far along are we? The battle system is essentially complete minus enemy data/AI, but all skills and status effects are done outside of statistically balancing them. Equipment and item systems are also done and completely functional. The amount ikaDB helped with this project is stunning. I just wrapped up a large chunk of the random map generation (see the image at the top for an example of it), it's probably the hardest thing of the entire game and it's still not entirely done.

Graphically Giz, my new artist, has most of the art done as well aside from last minute pieces to be added as we go, though the music production hasn't really started yet. So basically, really close. I'm hoping to begin beta testing this month if not outright releasing it.

whoops

I was trying to take a break from doing anything this week but I accidentally made another JSH Story episode. Whoops.

ikaDB is done. (read all about what it is inside)

At the very end there was a horrific, time-consuming bug that cropped up. But it's dead now. Let's have a look at the finished product, shall we?



Here's some basic code for a hypothetical game database concerning items and a basic enemy.

Let's take a look at it from the editor.



The editor categorizes data by whether it's a parent data model or not- whether it descends from any other data models or not. From these it builds a tree view of all the instances of data. Above is where you select which parent model to work with.




Here are all the operations you can do on the tree- adding or removing data model instances, moving them around, and categories. Categories are basically non-data that's solely for in-editor categorization (though games can access them if desired)



Here we have a simple database filled in by me so you can get a feel for how categories work. As you can imagine, these would become quite useful in a larger database. We also see how the DB generates the UI in fairly obvious ways from the example code. All fields from the parent are inherited by the child so you can have a basic item class just for displaying its name/text and then create more detailed models for when it comes time to actually use the item, rather than having one giant data model for every type of item.



Here we have the Monster model. The important part here is the MultiForeign field that essentially allows you to store instances of other DB items. It has two main modes- new and set. New mode lets you create a brand new model instance then and there. Set allows you pick an existing one in the database. The two can be mixed if desired. Here we're about to see the new mode in action:



As you can see, it simply generates a panel identical to the others for inputting the new object's data. The drop-down box is so you can choose from multiple model types to create if desired. Next let's see how the set foreign field mode works.



As you can see it's much like the main tree view, except you can't edit objects. You simply double click to select the desired item. One last look at how it ends up inside the monster model instance:



That's pretty much how it works, I hope you like it. While it's functionally finished it's far from completely stable or polished, something I hope to correct while I work on my game and WIP works on integrating with his own. The release will be delayed until I'm comfortable with its stability. The other factor is that it's so tied with the new iked functionality that I'd like for ikedv2 itself to be further along before release as well.

Progressive Caveman

Finished up the read-only view of models (plus the different ways to view them). Added fully functional cut/copy/paste/delete to the tree view. All that remains are foreign fields and model editor-only displays, and some clean-up of the tree view (indicate that things are cut, disable rename on data nodes, add icons to distinguish categories/data, make right-click visually select an item). Almost there!

On the downside WIP pointed out pretty effectively that I couldn't really tack on an event editor as I had hoped which somewhat damages its utility for the upcoming Delta T and pretty much creates another future project. Oh well.

I am pretty sick of working on tools at this point so I am going to take a break to actually work on a game. It'll certainly make DT harder to work on than if I had finished the suite of iked tools I wanted to do, but ikaDB is enough to live with. I can -probably- hack together a dialogue tree editor with it for the writer it work on it and cheat on way points with the current ikamap by using an invisible layer.

I'm pretty excited! DT's battle system is nowhere near the complexity that Contrivia had that just drained the project, and for the over world stuff I'll be able to reuse tons of code from my other dead ika games. Plus, it'll be a great chance to finally put together an event system before worrying about how to do a graphical editor for one.

Progress end

Strings, integers, floats, booleans, and enums have all been added. It should be noted that everything you see in that screenshot is completely functional. You can enter data and it will be saved and you can easily load it into your game. All that remains are the two types of foreign fields which I've started work on but are basically the last big chunks of work on this thing. After that basic cut/paste etc functionality has to be added to the tree and some additional brush ups like how to handle DB syncing. Also the order of that screenshot is incorrect due to a bug, the final version will organize the GUI according to the order you define fields. It should be done in a week or two.

After that phase two begins where the new ika map editor is worked on and the DB is integrated into it. Honestly, I can't believe this thing is almost reality. I've had the dream for over 5 years now but my hate of GUI code has always held me back. But I think a lot of thanks is owed to WIP, without his back end work on the DB side of things I would probably have gotten sick of all the dirty work before getting to the interesting stuff.

When I wrap this part up I'll probably do a more detailed gruedorf post explaining what this thing actually does and why I made it, for those of you who missed my original explanation way back when. I'm also hoping to make a real fast demo game with it when I finish up just to illustrate the utility of it.

Oh, and school resume this week which means all progress is about to die. AWESOME.

Too lazy for a title

It's capable of generating stuff for a model but it's not especially functional yet. It was a bit of a shore connecting all the thingamabobs for it. In other news I started rebuilding my old website with django, and am partway through judging the verge compo. Yep.