[Nephilim]

After releasing 'Sacraments', I was asked by the folks at director-online.com to write an article on the architecture of the game. The article has now been published, and it goes pretty in-depth into the architecture of the game. The article will be released in three weekly parts.

You can check it out part one at:

Architecting a Console-Style RPG in Lingo : Part One

Thought some of the people on this forum might be interested in checking it out. Although it's somewhat heavy on Director-speak, there are parts that may be of interest to people developing in other languages.

[DrunkenCoder]

Seems like a nice article even for us in the non lingo crowd it's quite fun to see how architecture is really language independant, for most of my projects I've used the same stack based model to handle states it's really a great concept :)
_________________
If there's life after death there is no death, if there's no death we never live. | ENTP

[Adam]

I've never seen this stack based idea before, very impressive. Im now a slightly less crap programmer. Good article.
_________________
https://numbatlogic.com

[valderman]

What adam said.
_________________
http://www.weeaboo.se

[Joakim]

I don't think I really get the point, unless you're just saying that you should seperate things that shouldn't depend on each other. Then it's just he idea of OOP. But maybe I didn't get the point...

[white_door]

Its a cool article becuase it suggests a method to simplify RPG code. In my rpg I ended up with several seperate engines that I had to switch between. This is not totally ideal becuase it made debuging the execution that much more complex due to the fact that there was at least 3 different 'main loops' that the program could have be in at any given moment. (battle, menus/dialog, exploration)

The whole idea of having a unified interface for each element of the RPG, then having a single stack to deal with input and output is a really brillent way of designing things.

[mandrake_weee]

I agree. I have used stacks for input, as well as a machine state stack to control game flow....but never have I thought of creating objects that represent different chunks of the code and then pushing that onto a stack....brilliant. Combining this with a good scripting language interface and a good map editor, and you could have a great RPGMaker.

[Sirocco]

The FB engine has a similar approach to this, which is how every piece of the engine can commingle with any other piece in relative harmony. Bloody hell to code, since I hacked it all together, but I wouldn't have a hard time these days :)

.

[Nephilim]

That's awesome that you guys liked the article. I'm psyched, since it was this community of hobbyist coders that got me motivated to build Sacraments in the first place. Cool.

Just so you know, the second part of the article is now available at:

http://www.director-online.com/buildArticle.php?id=1135

This section basically deals with how I engineered the map drawing engine. Hopefully, there are some ideas you can take away from this article. I suspect that some of the concepts won't apply to some of you C++ coders, since you won't have some of the speed issues you deal with in Director, but you never know. (Director is a scripting language with some overhead incurred from a generalized drawing engine, so sometimes you have to trade RAM usage to get speed by pre-rendering stuff. I suspect that if it were written in C++, you could probably render the map on-the-fly, which would change some of the issues I mention in the article.)

Anyway, hope the second part is useful to some of you, too.

[Joakim]

Yeah ok, I guess you have a point afterall :) Not my taste, but I suppose it could work quite well!

Anyways in your second tutorial, you create overlapping trees by using the roof and floor layer, which gives you a couple of problems, that you mention too. While many people chose to do as you do and limit the player to pixel*tile movement, there is an easy solution out there. Simply make a list of game objects (aka actors or pawns), which holds trees and players amongst other things, and sort them by y value (or y + height if they have different sizes) every time you need to draw them. That way your objects will be drawn in the right order, and everything will look just fine!

btw good job on winning the contest ;)

[mandrake*rpgdx]

heh, not everyone here is jsut a hobby coder- some of us make money doing it as well.

Anyway- Joakim- z sorting (or sorting by the y value, whatever), might be too slow in Director, since he would have to sort for each frame rendered. In C/C++ the overhead is nill (if you get a good sorting engine. Bubble sorting by Y makes things slow as hell, but I found out that bucket sorting is a good fast way of doing it), but in a scripting language where there is an overhead (enough so that, as he mentioned, he can't even render the tile maps on the fly without getting slow down), then sortiung every sprite every frame might not be the best solution.

[Joakim]

Actually, would bubble sorting be that bad? Remember that it only needs to sort something once in a while, and not each frame. Every sorting algorithm needs to go through the list at least once, and that is fairly fast. Sorting is pretty fast too if only a couple of elements are unsorted.

Not that I use bubble sort... I use the quicksort function that comes with the standard c++ libraries.

But you'd think that a scripting language has this kind of things in it. eg. like SORT actors BY y or something :) Maybe not though. Maybe the solution is not to use a scripting language? ;)

[Nephilim]

Mandrake is correct - it was largely a decision based on my concern for the speed of Director. I did the 'canopy' thing so that I could pre-render the maps and not have to compute them every frame. All I have to do is copy a rect out of the ground layer, draw the characters, and copy a rect out of the top layer. I don't have to do sorting or piecemeal copies for every tree in the forest. I was trying to keep the CPU load for the map drawing low, because I knew I'd also be incurring a hit by simultaneously displaying dialog boxes and the combat engine, which could get large themselves.

But you're right, Joakim - that style of map drawing would certainly eliminate the "canopy error" I described, and would be a better choice if you are building the game in something zippy like C++ or Objective C. That would also drastically decrease the RAM usage, because you could refrain from storing an entire copy of the map graphics for each animation frame. Sometimes in slower languages like Director, you have to trade RAM usage for speed.

But I don't want to be too harsh on Director. These sorts of issues are heartily balanced by Director's rapid development features and cross-platform capabilities. If I had programmed Sacraments in Objective C, I would still be programming it, and it would never have showed up for PC. Plus, it's entirely possible that a z-sorting system in Director could have worked. I've done some z-sorting on the fly in Director for an isometric-based engine (which never panned out into a full-blown game), so it *is* possible to do in Director. But I had never tried it full-screen before, so I basically went with the way I knew would work. Depending on the particular needs of the RPG, it's likely that you could do that style of engine in Director (although you may sacrifice some of the lower-end machines that Director typically covers).

[LeoDraco]

[Bjorn]

I think most quicksort implementation have some randomness in them to make the chance of reaching that worst case scenario practically zero. This can be bad too though, as it can make sprites that are on the same height flip position every frame or so, which is visible if they overlap.