Adding to the swarm of developer blogs since 2007

Friday, April 20, 2007


Hi, this will be my new devlog, just to track projects I'm working on and collect thoughts on them and so forth. First up, PixelRPG! This is a little side project I've been working on amidst school projects and some other miscellaneous things. Currently it's looking like it's got a shot at being a reasonable game, so I'm actively looking for input on good traditional RPG gameplay, combined with more modern concepts like a full paperdoll for inventory and complex character/world development.

As of right now, the game consists of a rudimentary GUI written in C++ with SDL, using the default SDL blitter (although I've set the foundations for a GL renderer, but that'll take a while). The world of PixelRPG is a big one; the map is an image 2400x1800 wide (by default, the game supports maps up to 4096x4096). Each pixel on this map is translated into a cell 800x800 pixels wide, composed of 10x10 tiles, each of which is 80x80. If that's not enough numbers, i'll put it into simple terms: at 2 tiles per second (about average walking speed) it will take you 26.67 hours to walk across the map. I believe this is pretty representative of a large enough world. The big trouble in dealing with a map of this size is making it feel like enough work went into every area. Each 10x10 cell of tiles is randomly populated with tiles (using the tile's world position as a seed in order to make sure the tile will always use the same graphic) from a tileset determined by the pixel color of the main map. This means a ton of pixel work, but hopefully will end up with a very personalized world. The end goal is for the generator to recognize cell transitions and use tiles designed for borders appropriately, as well as randomly inserting neighboring cell types into the border to create an uneven transition area.

In addition to the random elements of the map, statics can be positioned anywhere using a cell-relative position (that is, using the cells of the main map to position elements relative to). Buffering for these objects will be managed by a static loader that loads statics within a certain cell range -- this will ensure that thousands of statics across the world won't bog down the system unnecessarily.

Currently the project is in need of sprite artists and good ideas, apply at my blog e-mail: ERASEMErwarho1@gmail.comNOSPAM (eliminate the capitals, I'd rather my e-mail not get scraped).

No comments:

Post a Comment

Give a hoot, don't pollute.