Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - RoguelikeGCS

Pages: [1] 2
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
Off-topic (Locked) / Re: Portal 2
« on: April 23, 2011, 01:22:10 AM »
I was very surprised by all the poor user reviews on metacritic. All the claims being made, such as it being an *obvious* console port, being too short, etc, are simply untrue. I'm willing to believe the theory that some users are getting revenge on Valve for some of its marketing ploys. Nevertheless, a metacritic score of 95 speaks volumes.

** SPOILERS AHEAD **

Portal 2 features:

* Potato companion
* Mind boggling test chambers
* Awesome scripted events
* Awe inspiring massive levels
* An absolutely preposterous ending that'll have you on the edge of your seat!
* Nutty voiceovers by Merchant & Simmons

4
Early Dev / Re: crashRun 0.4.0 released!
« on: February 26, 2011, 03:37:29 PM »
Whatever they should be, they ought to be lazier.

Have you thought of adding some other crazy monsters to your game? Such as deranged chicken wielding animal rights activists, or maniacal picketers.

5
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/

6
Programming / Re: Legacy code problems
« on: September 19, 2010, 07:30:25 PM »

7
0.16 released.

8
Programming / Re: Virtual Machine VS Procedural Interpreter
« on: June 17, 2010, 04:12:45 AM »
Why not use an already available scripting language like Lua?

For the sake of clarity, let me tell you that this scripting language is not for my own use during development of the RL engine, but for use by clients of the GCS. Therefore LUA will need to support adding callable functions in the following manner:

Let say for example, that the client wants to get a reference to an inventory so he can iterate through the items there; he would need some code like the following:

Code: [Select]
begin()
{
rInv = GetInventory(GetAutoPassedVars(0));

for (i = GetFirstItem(rInv); i; i = GetNextItem(rInv))
{
a = GetItemProp(i, 0);

DestroyItem(rInv, i);
}
}

the begin() function would be specified by the client, and called in the respective creature once upon entering an area, or starting the game.

Having looked at the LUA website, i must say, not only does it look highly complex with very strange python esque code, but it seems that getting it work for my needs (providing it can even do what i want it to) would be too much hassle. I think I'll roll my own. Good luck convincing me otherwise :)

9
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/

10
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).

11
Programming / Re: auto managed item prices
« on: June 11, 2010, 11:45:17 AM »
I think it's been mentioned on numerous occasions that the problem with fixed prices is that people can scum through a game, accumulate money, and buy all the expensive artefact items. I just want to explore other ways of dealing with trade in a roguelike.

It doesn't make sense to have inflation whereby the player amasses wealth far beyond the wealth of the combined force of shopkeepers.

If we recognise the often imaginary nature of money (the currency in ancient Rome was for a long time based solely on the popularity of Caesar Augustus), and we keep in mind the fixed value of physical commodities such as gold (valuable not because it looks shiny, but because it can lie in the sea for a thousand years and not tarnish), platinum, marble etc, we can see that it doesn't make sense to have fixed prices, while the money supply constantly increases.

12
Early Dev / Re: crashRun 0.4.0 released!
« on: June 09, 2010, 11:23:49 PM »
The reanimated unionzed maintenance worker hits you. -- more --

:D

13
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/

14
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.

15
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.

Pages: [1] 2