next »

[encoder]

you have a ton of stuff there that could turn your project to vaporware. i reeeeeely admire your will. at this time reinventing the wheel is the best thing you can do to advance. however if you got stuck somewhere for more then 30 min, i recommend that you search for references. it gets in your head anyway.

overlays and effects could impact your full frame redraw, i recommend that you use redraw regions. you point out the part of your array that has to redraw and you redraw only that rectangle. for this you have to have some positioning system in place (array

• [y] or something). and there is antialiasing, and so on..

anyway, good luck. (i just love these eyes) 

[Mipe]

I'll just stick to the KISS principle (Keep It Simple, Stupid). I don't really need these effects, as my goal should be to get the basic and robust engine up, so it is going to be just a flat array. Instead of drawing tiles on top of each other, they'll overwrite each other, so only one is rendered at a time. Transparent tiles, which serve as selectors or whatever, can be drawn independently; Gosu handles transparencies and antialiasing by itself. All I have to do is to blit a tile to the screen at certain coordinates, Z level and color.

I daren't imagine developing the whole graphical engine all by myself.  

I hope I can make it simple and robust enough to make future work much easier (such as adding UI elements in a quick and painless way)! Because if this step is screwed up and I get a bulky interface, well, that sure would kill the drive.

Figure some foresight is a must when it comes to developing a game engine...

[jotapeh]

Figure some foresight is a must when it comes to developing a game engine...

Understatement of the year, perhaps

By the way, in case anybody is curious, I did pick up the book LemonScented recommended - Game Engine Architecture - and so far it's quite good. I was shocked at the sheer thickness of the book... loads of information to digest...

Fair warning though, it has a big slant towards C++ and 3D games, in particular FPS games seem to be the most fleshed out. Still quite good and most stuff is applicable to many genres/languages.

[encoder]

thx for the tip.

i'll torrentit.

[Mipe]

thx for the tip.

i'll torrentit.

And that, friends, is a fine example of what NOT to post on board frequented by indie game developers who loathe piracy even more than their mother-in-laws. 

[george]

There is a constant, a long hash of key IDs (Gosu) and symbols (such as :enter, :esc, :W, :w, :tab etc.). In the current form, I have a loop that iterates through the hash and checks whether that particular key is pressed, then it adds the appropriate symbol into another hash, which tracks pressed keys (as well as released).[....]

I dread the actual game engine; how would I handle game states, transitions, interface, logic, data? [....]

How to define skills and abilities? How to define items, equipment, ability to equip items? [....]

can't wait when I get to pathfinding, FOV and AI implementations. [....]

It sounds like you're doing great so I wouldn't be discouraged at all (you don't sound like you are really).

A little off-topic, but to respond:

Your key handling looks OK to me! That method actually is quite common.

In my first roguelike I handled states very simply. I had a hash of state strings which mapped to functions. Each update called a variable that contained the current state function. When the state changed, I updated the variable by finding the appropriate state function in the hash. I did this for gameplay, input, and rendering update methods at the same time.

An alternative way I've used is to keep a list of states. The update method calls the first state, which runs its update method. When you want to add a state you add it to the list (for example, you would push a pause state on top of the list).

For skills and abilities a very easy way is just to keep a list or hash of properties on each entity. Inventory also can be a hash with keys being slot strings that define what you can put there.

For FOV and so on, you might like to look at other roguelikes for inspiration, and some libs like libtcod and things like the roguelike development usenet group or the roguebasin wiki for educational value.

As a matter of fact...you could consider writing a Ruby wrapper for libtcod! That's be great and really leverage your work for others, while at the same time boosting your efforts with everything in the libtcod library.
 

[Mipe]

Thanks for the tips and encouragement! It's a long journey, but little bit by bit I'll get there!

As a matter of fact...you could consider writing a Ruby wrapper for libtcod! That's be great and really leverage your work for others, while at the same time boosting your efforts with everything in the libtcod library.

Had you suggested that a week earlier, I'd be like this: 
I did actually consider libtcod, but back then I've run into so many issues it was quite frustrating to even try. But now that I've done some shaky steps into Ruby I feel I could actually do it.

I wonder... *wanders off to libtcod site*

[encoder]

thx for the tip.

i'll torrentit.

And that, friends, is a fine example of what NOT to post on board frequented by indie game developers who loathe piracy even more than their mother-in-laws. 

and that, friends was a joke. it should be taken into consideration anyway.

at some point i arrived at the conclusion that until the human mind is free, you cannot control information and piracy is just a syndrome. so when piracy disappears we have a serious problem. piracy is good to a certain level. on the other side of your angry eye i must point out, that the all the illegal stuff that i download illegally, (witch i don't, actually lying here) if there is one that it worth it, i go and buy it. the main that drives me is usually multiplayer and sometimes good support. there are exceptions too. if i see some good discount or something i just want to have in my library i just buy it without thinking.

one of witch Diablo III will be. can't wait for it to hit the stores.

that is some of the causes i mentioned (thk i did) that multiplayer as a good and soon to be essential part of an engine in order to make it profitable.

[mewse]

No thread is complete until someone tries to justify piracy in it.   

[encoder]

No thread is complete until someone tries to justify piracy in it.   

  uuuu i ain't the first.

piracy is a variable that can be dealt with in multiple ways, either one of them won't stop it. in fact i plan to distribute one product via torrent and other "unconventional" means.

how? i will do some freaky game, offer full singleplayer with a 30-60 seconds wait time when it starts, and no multiplayer. advert in the game and other annoying stuff. after buy, take all that away and offer a well polished multiplayer, no countdown and such, and support.

and if the premium version hash fails, i make the client connect to a Trojan server  .

anyway, few hacker communities hack indies in mass witch is a good thing.