Maek Gaems Blagh

jub jub

2011-09-17T22:31:00.000-07:00

This week status effects and their related actions were done. Additionally the data portion of abilities was down in addition to part of their implementation.

microimplementation

2011-09-10T20:53:00.000-07:00

I have begun implementing the battle system in tiny independent pieces. So far this is going pretty well! Currently I have damage processing, conditionals (non-trivial when game data can be transferred over the network so an ordinary eval statement is out of the question), and actions. I will talk more about this design strategy next week!

batter

2011-09-03T20:53:00.000-07:00

I added a new model-file selection prompt, a sync and change model button, and even optimized the DB slow issue (h2o used to take 4 seconds to load. now it's instant)- which turned out to be a fairly simple error on my part. Hooray! Next week, the battle system begins.

Return to Gruedorf

2011-08-27T18:13:00.000-07:00

The gruedorf site was down for like a week and without a timer to nag me I simply didn't care to update this thing. But that's all in the past.

Updates or not, plenty of progress has went down. In short summary the current build of the game lets 4 players connect together using a simple gui, walk around the map in a turn-based fashion, and chat.

That was completed weeks ago. More recently I have been churning out technical documentation for the battle system's mechanics and designing how the main game plays out. More recently I took ikaDB out of the attic, ripped out its dependencies on iked (since ika in general is now dead), renamed it to GameDB (I need a better name), and have begun to spruce it up a bit for this project.

The first improvement I've made is caching the GUI for models. More specifically: wxpython (or possibly the database itself) is really slow at generating the GUI for each model, so I added caching the generated model GUIs at start up so the interface is much snappier now. Unfortunately I couldn't make it cache modal pop-ups for add/editing sub-models due to how wx works, but those are used less frequently and they cache after the first instance so it's not too bad.

Next up is revising the GUI for its new standalone format, fixing up the bugs I encountered while working on Hydration 2, and trying to speed up the underlying DB access (presently it's too slow to use in real-time, you basically have to load the entire thing into your game at start-up, and that takes a few seconds. I hate this and want to fix it. I'm not sure of the underlying cause yet.) I'm toying with the idea of a public release of GameDB since it would be useful for virtually any game written in Python, but there's a lot of nasty gunk in it I'd want cleaned up before a public release.

aaaaaaa

2011-06-18T18:54:00.001-07:00

Some design doc work was done. That was it! for reasons beyond my control.

Find Path

2011-06-11T20:07:00.001-07:00

I got the beginning of pathfinding done but there's still additional work to be done on it. Then I realized my planning was insufficent to determine how to connect the dots so I went back and started expanding the design doc for the code. And I am still doing just that. A poor week.

Bugs, bugs, bugs

2011-06-04T20:25:00.000-07:00

My goal for the week, after some soul searching, was to get sprites working. That goal has been mostly completed.

It's partially due to my inexperience with it but so far C++ is like working in sludge since virtually every additional piece of functionality I add gets a bug/flaw associated with it that takes an hour or more to fix before I can move on to the next thing (hello thar manual memory management). Hopefully that becomes less plentiful as I get used to it.

Questionable time allocation

2011-05-28T21:33:00.001-07:00

So I swapped out CEGUI for MyGUI, which took a lengthy amount of time to do. I'm somewhat second guessing that decesion since it's even worse documented than CEGUI was, though it makes up for it with a better toolset and working in a way I prefer for the most part. I also brainstormed some means of dealing with sprites. I am not particularly pleased with this week's progress and I kind of wonder where my time even went. Such is the curse of a broken sleep schedule.

Untitled

2011-05-22T00:04:00.000-07:00

-Messed around with the general architecture of the map engine to support multiple maps at once, among other things.
-Added mouse click detection (extra fun in iso) and various tile setting/coordinate converting utility functionality.
-Began making CEGUI and SFML cooperate. It's working fine! Just need to learn CEGUI now.

I was originally planning on offloading most of the game logic to python, but after looking in terror at the embedding guides I'm probably just going to write most of it in C++- though I may end up revisiting python integration to a lesser extent much later on.

land grouping screen display

2011-05-14T18:21:00.000-07:00

I guess it's some isometric map engine written in C++ using SFML or something.

It has zoom functionality as well I suppose.

More details laaaaater.

The Littlest Gruedorf

2011-05-07T21:04:00.000-07:00

A busy week, so a meager offering this week of having written, like, 4 text boxes. That's it. There was some beta testing / advertising but that's not REAL work. Next week the gloves come off for seriouse.

Whoops

2011-05-01T05:07:00.000-07:00

I actually did make progress (In fact I did it on like Sunday of last week), just gruedorf slipped my mind. In short I finished hooking up the first area so encounters and relevant NPCs are in there and working. I even had a little beta test on it and I'm up to about 30mins of gameplay so far. Busy week so I haven't touched it since, but we'll see where this goes.

Plot a portal to progress

2011-04-23T20:52:00.001-07:00

-Added first area's boss.
-Created crafting items/menus (still need to place 'em though)
-Finished obstruction exporter. Also did a foemap exporter.

Snaketrap

2011-04-16T13:39:00.000-07:00

-Drew a new map
-Created the 3ish basic enemies (drawn/in-game)
-Did half of the obstruction editor (python script reads/writes OHR obstruction format, now I just need to make the sphere map editor output collision data and have it read that format and put it into ohr format- I have to do this since the OHR doesn't natively support image based maps, but Sphere's editor does.)

Not fast enough.

You can't just win a gruedorf

2011-04-09T04:13:00.000-07:00

Grue pointed out that he is currently winning the gruedorf and we all know that no one can win the gruedorf.

The heck is that? I don't even know how to explain it since it involves several layers of community that no one who reads this blogs knows anything about (hence why I wasn't gruedorfing it to begin with!).

In short I'm making a game for the OHRRPGCE (it's a terrible engine, but you know sentimental community value), there's a fangame contest, and I'm making a fangame of a game the author deleted because he didn't think it was good enough.

You can see the original game here:

He's kind of a lot better of an artist than me!

Of note I'm trying to draw all of the maps, enemies, and even sprites by hand with a tablet. I'm a really, really bad artist. But for some reason drawing doodles doesn't infuriate me like drawing pixel art so I'm making a lot more headway with my awful art here!

Right now I'm really just drawing crap and outlining the plot since I have to wait on an engine feature to make it POSSIBLE to do image-based maps in the engine (now THAT'S customer service). You'll probably get some more awful doodles next week!

Let's talk about MMO's

2011-01-08T22:36:00.000-08:00

I'll be breaking off from gruedorf tradition in that I probably won't even be talking about Actual Game Progress. Probably. I'm here again because I want to talk. I've decided to set out upon the greatest of foolish hobbyist ideas: an mmorpg.

Fortunately I'll be bored of it in a month and we can all forget about what a bad idea it was.

So I'm here to talk about the genre and why I feel like wasting my time working on an entry for it that won't be completed. Mostly it's a way for me to sort my thoughts on how to design this thing.

I find the current manifestations of the genre to be truly terrifying. By and large companies have homed in on isolating ways to short circuit the human mind's desire for progress in order to be paid money on a regular basis. This is clearly a pretty good business model. But I'm not much of a business man, and I don't find it very interesting.

Let's look at the social aspects of MMOs for a moment. I think we can divide current examples of the genre into two pools: Social and gamey. Social mmos like, say, Second Life mostly focus on sharing crap with other users and talking about stuff.

Gamey mmos I would compare to the pvp and raid/instance content of World of Warcraft (and basically every "gamer" mmo out there). Here you get to enjoy users talking primarily about the game itself, whether that be strategies or bitching about altered mechanics (in addition to general random talk).

Then there's stuff like world of warcraft's world content which essentially may as well be a single player game where a bunch of other random people pass by occasionally or you can drag in your friends so you can do the same thing individually but faster. The only other time other players have any meaningful interactions here are with sporadic pvp or if it's new content, long waiting lines. So essentially the social aspect in this type of game is basically nothing.

Let me contrast this with a little story. Some years ago there was a player-run Ultima Online server that was focused on roleplaying. Part of what they used to enforce this is that there were no NPC stores whatsoever. There also wasn't an auction house for automating player interactions. Crafting classes were also essentially separate from combat. What this meant is if you wanted better equipment you had to set out and talk to another player and ask for it. Sometimes you'd need to pay, sometimes you'd need to fetch the materials, sometimes they were busy. Sometimes you'd talk about something else while you were at it. I think that's interesting. Somewhat casual player interaction about the game without being about the mechanics and how to exploit them in minute numerical detail.

Obviously this is somewhat contrived in that roleplaying was enforced (you had a write a short background biography to get on in the first place, so literacy was a requirement) and the scale of the community was small. Still, it's interesting. It's something I'd like to shoot for: encouraging social interactions that are about the game.

Next time I'll talk about balance in mmos (which is to say something that cannot be achieved and is the reason why there are no worldwide consequences in any current mmo).

Contrary to what the Gruedorf may imply...

2009-06-04T22:14:00.000-07:00

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

2009-03-08T16:31:00.000-07:00

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)

2009-03-01T19:09:00.001-08:00

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

2009-02-22T14:18:00.000-08:00

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

2009-01-12T00:30:00.001-08:00

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

2009-01-04T22:16:00.000-08:00

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.

Steadily unimpressive progress

2008-12-28T18:10:00.001-08:00

Added categories to the editor as well as adding instances of models (Which are all unnamed because the name editor isn't there yet). This may look pretty trivial but it required adding on the the database's functionality which required learning how to do that in the first place. And stuff. This actually pretty much ate all of my holiday weekend. It should be noted that saving and loading are already added as part of WIP's previous work on the backend of this thing, so it's edging remarkably close to usable. Next week, adding the actual data editor generator! (and maybe even the advanced tree functionality of cut/copy/paste etc)

Untriumphant Return

2008-12-21T19:24:00.000-08:00

Oh what a surprise, still working on ikadb. Started on it again this week, though prior to that WIP wrote out the majority of the database-side code. To be completely honest doing this kind of application programming bores me stiff and also involves a lot of trial-and-error with wxPython so progress is retardedly slow. So far it sorts out the models into parent and child (with children capable of belonging to more than one parent though there's really no application for that) and then lets you choose a parent model to work with and generates the pop-up menu based on its children. That's it. Other, future differences from past versions of this includes that it'll generate a table-style GUI for working with the data instead of an actual table. I am gradually slipping into "oh fuck it, I'll just make it work and to hell with it working well".

In other news I started a new project to avoid entering the new Verge contest (codename Delta t), only to have a desire to enter the contest anyway with another game. Great.

Nothin'

2008-10-26T23:26:00.000-07:00

Ain't gonna lie, I got nothing done this week for all intents and purposes. I have decided on a few changes about how to do ikadb, though. Firstly the database part of it will be more modular than originally considered- the ika implementation will use sqlite but if I want to switch over to something else it should be simple. Secondly, I'm keeping the backend's name as GRAPES rather than calling the entire project ikadb. Following that, the program itself will be able to run independently of iked. Simple fact is I want to take my tool with me when I have to depart from ika without having it too heavily tethered. Using separate Python code to define data types might be a little awkward but it'll do.

Aside from that I've done some consideration and decided that a more demo-oriented approach (as the original Gruedorf rules promoted) is probably a good idea. While it may not be the most logical approach in programming, the human side of it is much more inspired when it sees actual progress instead of theoretical progress. So expect posted builds from this point on (at least, if I can find web space to put them on).

The last few Gruedorf posts (notably grue's and overkill's) were remarkably more inspiring than usual, not that this actually promoted me to do much of anything, but I'd still like to take note of it. But since this is an awful filler post of "really I'm doing something guys honest" I might as well fill it with more filler in the form of the Gruedorf anniversary posts that a few others have done.

When I started this blog I was restarting Contrivia from scratch. Skip a year and we now have an almost-finished Contrivia battle system/editor (the second version of it, the first being pre-Gruedorf) with most of the documentation and around 65% of the art, a now-discarded partial version of GRAPES, and a finished Magical Unicorn Adventure.

That's awful. Contrivia still being so far away from being done is awful. Not having GRAPES done by now (and having to restart it) is especially awful. Magical Unicorn Adventure probably having lost the contest because we stalled starting on it for two months is awful. This is terrible. It's a mess.

V. little

2008-10-19T22:15:00.001-07:00

Currently playing Mother 3 and progress is very difficult to obtain since if I had to describe this game in a sentence it would be: It makes me want to stop making games.

Otherwise, more planning on ikadb but no real progress. Between playing games, school, and worrying about the ever-nearing contest results...yeah. Awful, really.

Maekin' Gaem Maekin' Tools

2008-10-12T23:59:00.000-07:00

I was sort of worried about this before I ever joined gruedorf. It's inherently against the way I work: I burst between months of nothing but working and months of nothing but doing nothing. But at this point I don't care all that much about gruedorf in general so, whatever. When Contrivia is released I'll probably take a much longer break to really skyrocket that fail bar.

Nothing exciting this week. I resumed work on GRAPES this week. Mostly rewriting it from scratch since the previous build was mostly me seeing how to do it in wx. Major changes include it being built as an iked (ika's future IDE) plugin, using sqlite instead of a custom format, and a few general architecture changes relating to things I didn't think of last time. As such, it's being renamed to ikaDB for the time being.

Right now it's very much early with a basic design doc and the beginnings of pseudo code (trying to do it for a personal project for once, it'll be interesting to see how it turns out. So far it seems much easier to deal with wx when you don't worry about it and just write your code the way you want it without considering it heavily).

Considering this is the third time I've started this project I hope I actually finish it this time. I just don't relate to application programming as well as game programming. But the general implications of getting this done are enormous for me and probably other game makers that I just cannot resist trying to get this thing out.

Maekin' Gaems

2008-09-28T23:18:00.000-07:00

My web space expired last week and in the heat of finishing Magical Unicorn Adventure I had no time to bother with a replacement, though I assure you that there sure wasn't much losing since I haven't done much of anything other than make games for the last 3 weeks up until Thursday when we submitted it. It's done and we're taking a three week vacation before resuming work on Contrivia.

As you might note from the new blog title, naming my Gruedorf blog title after only one game was probably a little short sighted. Well, for me anyway. Might make sense for all you losers out there. During the three week vacation I'll fill my Gruedorf duties with...something. I don't know what yet.

In the meantime here's the proof of unicorn completion (can't really post a build given part of the contest is a publishing arrangement)