Topics

1

Traditional Roguelikes (Turn Based) / Roguelike GCS .27 A Released

« on: June 09, 2011, 12:20:40 PM »

Roguelike GCS is a roguelike engine with an editor. It can be used to create random dungeons like in the original Rogue, static adventure worlds like in ZZT, or to do both at once. There will eventually be a built in scripting language for controlling game world objects, and implementing unsupported functionality.

Ver 0.27 Alpha (June 9, 2011)

* Play Engine: area transitions
* Play Engine: simple turn system
* Play Engine: basic monster behaviour
* Play Engine: basic melee combat
* Play Engine: items can now be equipped

http://www.roguelike-gcs.co.uk/

2

Programming / throwing objects

« on: May 09, 2011, 02:32:58 PM »

One of the problems I'm faced with in the development of my roguelike engine, is how to limit the distance a thrown-object travels, based on the mass of the object. The force applied is fixed, assuming average muscle development of an average 150 pound human male.

I might be tempted to program a fixed threshold, at which point it becomes impossible to throw an object (say, an 800 pound washing machine for example). I don't like this approach because it is unrealistic.

I do not know much about mathematics or physics. I *am* currently studying maths at university (only introductory level). But that could take ages to finish, and it might not provide the knowledge needed to solve this problem.

I'm not asking people to solve it for me, just to point me in the right direction.

What I'm aming for is a function that takes the mass of the object, the force applied, and returns how far in yards the object travels.

Something like this:

Code: [Select]

function(int mass, int force) // force is always the same, but we shouldn't hardwire it, just provide the value as needed
{
    /* math expression */

    return value;
}

3

Traditional Roguelikes (Turn Based) / Roguelike GCS .21 A Released

« on: February 22, 2011, 03:42:56 PM »

Roguelike GCS is a roguelike engine with an editor. It can be used to create random dungeons like in the original Rogue, static adventure worlds like in ZZT, or to do both at once. There will eventually be a built in scripting language for controlling game world objects, and implementing unsupported functionality.

Ver 0.21 Alpha (Feb 22, 2011)

* Editor: rewrite and tidy up
* Editor: updated palette - 16,000+ selectable colours
* Editor: added support for lower minimum resolution (1024 x 600)
* Editor: fixed bug in cleanup code called when deleting a template
* Editor: fixed bug in code for escaping chars 0-31 & 256-1535 in project file output
* Play Engine: item selector now displays the items' glyph
* Play Engine: added behaviour code for portals, movable objects and for moving between boards
* Play Engine: fixed minor oversight in door behaviour code
* Play Engine: fixed null-pointer dereference in object behaviour code
* removed support for 8-bit and 24-bit modes (supports 16-bit, 32-bit)
* Unicode now supported for keyboard input
* various minor changes and fixes

http://www.roguelike-gcs.co.uk/

4

Early Dev / Roguelike GCS Engine feedback

« on: June 11, 2010, 12:04:58 PM »

Roguelike GCS / Maker is a toolset that can be used to create roguelike adventures. It will eventually include several dungeon generators, and a scripting language used for controlling Objects, Items, Creatures, and Effects. The toolset is intended to allow designers and artists to focus on storytelling and level design rather than difficult programming.

I'd be grateful for any suggestions you might have regarding improvements, new features.

http://www.roguelike-gcs.co.uk/

5

Programming / Virtual Machine VS Procedural Interpreter

« on: June 11, 2010, 11:58:10 AM »

Eventually I'm going to start writing the scripting language for my RL. The dilemma I'm faced with is whether to commission someone to develop a proper VM to execute low level byte code generated by my parser/compiler, or to develop a perl style interpreter myself.

The main issue seems to be with speed and efficiency; it's hardly rocket science to write an interpreter to execute through a data structure created by a parser. but even with optimisations, I can't imagine this approach producing a very fast scripting language.

The VM would be a complex engineering feat - something I would not likely be able to achieve myself (but it would offer irresistible performance).

6

Traditional Roguelikes (Turn Based) / Roguelike GCS 0.16 A

« on: May 29, 2010, 11:51:03 PM »

Hi!

Roguelike GCS / Maker is a toolset that can be used to create roguelike adventures. It will eventually include several dungeon generators, and a scripting language used for controlling Objects, Items, Creatures, and Effects. The toolset is intended to allow designers and artists to focus on storytelling and level design rather than difficult programming. (See FAQ: http://www.roguelike-gcs.co.uk/?q=node/6.)

Latest version: 0.16 Alpha

Feature list:

* emulated console graphics (28 x 16 pixel)
* multicolour tiles
* portable project format
* saving/importing BMP tileset files
* object, item, creature, race, effect templates
* unlimited, unlimited, unlimited

Download: http://www.roguelike-gcs.co.uk/

7

Programming / auto managed item prices

« on: May 27, 2010, 03:41:36 PM »

For my project I have considered using some kind of auto managed system where prices are based on money supply and item availability/rarity.

Consider this hypothetical example:

A player goes through a dungeon and collects a handful of money; he emerges from the location and heads to the nearest shop; he buys some items from the shop, thus transferring money to the shopkeeper. The shopkeeper is now aware that there is more money in the system, and can put the prices up a little bit (not necessarily proportionately). If the player sells items to the shopkeeper, there will be less money in the shopkeeper's system, so there will need to be a mechanism to track the total money that has ever been put in the system, and the current level of money in the system. This way, the prices can increase even if the money in the shopkeeper's pool decreases. (For example: the player sells something for 100 money units, and then buys something for the same price; the shopkeeper should not count this 100 units as new money entering the system.)

Because the player can go through dungeons and find money, or take it from corpses, it will always be possible for him to afford really expensive rare items despite the increasing prices of items (because prices are only updated per trip to a shopkeeper); the shopkeepers don't know about all the money in the game world.

Another side of trading is item rarity.

There should be some way to account for lots of a particular item being added to the game world, so that the prices of items can reflect the availability of items. Really rare items like artefact neutronium lighsabres etc should cost an arm and a leg; the price should be roughly proportional to the delayed shopkeeper knowledge of the money supply.

8

Programming / Sound Event Propagation

« on: May 23, 2010, 11:38:37 PM »

I'm thinking about creating some kind of system for semi accurately allowing sound events to travel around a dungeon or other area. The events should have an intensity value based on the type of sound and loudness; the intensity should decrease as the sound moves, and if the sound passes through a wall (walls will have sound proofing values to determine how much they muffle). Sharp corners (in corridors) might be able to deflect sounds in a perpendicular direction, allowing sounds to properly navigate labyrinthine corridors. This could have the interesting effect of allowing a delayed repetition of a sound. Consider this:



In that image, if the sound is propagated in a somewhat realistic fashion, then the PC would presumably hear the event (muffled), followed by an echo, depending on the intensity. If it's a footstep, it will likely not reach the PC at all.

My maths abilities are somewhat lacking, so I'm having trouble figuring out how to use circles, increase the size of them as the sound event propagates, but maintain the correct muffle values for the relative pixels in larger version of the circle as it increases.