Show Posts
1
Programming / What would a programming language for roguelikes look like?
« on: April 01, 2016, 03:13:21 PM »
If one were crazy enough to implement a new programming language expressly for roguelikes, and possibly even a (virtual) chipset expressly for running said language upon, and potentially even a portable cross platform (virtual) operating system atop said chipset expressly to support the integrated development of roguelikes, what features and/or syntactical sugars might one expect to find therein?
Let's assume that the language's standard library would have the expected bog standard algorithms for pathfinding and procgen, such as A*, voroni, perlin & simplex noise, etc. as well as abstractions for recording and retrieving the game state and levels via the platform's available storage medium. Let's also assume the standard library includes a tile based display interface capable of multiple layers of ASCII or graphical and potentially animated cells / sprites, something a bit more friendly than curses but in a similar vein, with definable "window" objects and scrolling regions within the display, etc. And while we're at it let's assume there's a simple music and audio event system included.
I'm not asking what standard tools a roguelike programming language would want to have in a standard language library as that's quite apparent from existing frameworks, but rather I'm curious to discover what, if any, linguistic flavoring could prove more "expressive" for roguelike development than existing general purpose languages? For example, in my experience roguelikes tend to be extremely stateful. So, perhaps a roguelike language would have builtin Actor entities an in addition to the generic OOP features these would have "states" and "statuses" which can affect the actions the Actors perform.
Thus:
The above would create a new Actor of the Enemy type, randomly selected from those registered types matching the current set of "of" qualifiers: Actors of Enemy type available on the current floor, at the current difficulty setting and matching the current floor's environment status. The union of qualifiers represents the pool from which the enemy's type would be randomly selected prior to instantiation. The pseudorandom "rand" selector being deterministically seedable at the outset, of course.
Then the enemy.attack() function may perform a different set of logic depending on whether it entered the "Angry" state due to it having the Pain status, i.e., more than one set of "methods" could be registered for the Actor, and if the Enemy has an Angry state that defined a different .attack() method, it would be called rather than the Enemy's default attack() method.
The attack() function(s) would not be called if the status of sighting its current target is missing. Furthermore, the state transitions would have a default "on" method that is called when entering such a state:
Also note the "with [object]" shorthand of "[object]:", which selects the given Object/Actor/Entity as the default scope for the duration of the following statement / block.
A form of compile time static type analysis could generate warnings if unique / non-eventful, and possibly misspelled statuses/states are applied to Actors.
This is a hypothetical syntax, of course; I'm only mostly crazy enough to implement such a domain specific language, and can neither confirm nor deny whether several iterations of cross platform virtual machines already exist and are hungry for construction of a language other than Assembly or C... Mostly, I'm interested in what features / syntax others would envision an RL lang of having.
The obvious response that few if any would bother tinkering with a new language just to utilize some newfangled portable rogulike operating system is a given; Thus, please ignore the difficulty and insanity required to achieve such a goal and instead approach the question as an outlandish thought experiment:
What if...
Let's assume that the language's standard library would have the expected bog standard algorithms for pathfinding and procgen, such as A*, voroni, perlin & simplex noise, etc. as well as abstractions for recording and retrieving the game state and levels via the platform's available storage medium. Let's also assume the standard library includes a tile based display interface capable of multiple layers of ASCII or graphical and potentially animated cells / sprites, something a bit more friendly than curses but in a similar vein, with definable "window" objects and scrolling regions within the display, etc. And while we're at it let's assume there's a simple music and audio event system included.
I'm not asking what standard tools a roguelike programming language would want to have in a standard language library as that's quite apparent from existing frameworks, but rather I'm curious to discover what, if any, linguistic flavoring could prove more "expressive" for roguelike development than existing general purpose languages? For example, in my experience roguelikes tend to be extremely stateful. So, perhaps a roguelike language would have builtin Actor entities an in addition to the generic OOP features these would have "states" and "statuses" which can affect the actions the Actors perform.
Thus:
Code: [Select]
Actor enemy = new rand Enemy of [ floor.actors with[ Enemy ], currentDifficulty, floor.environmentType ];
...
enemy: if ( has Pain ) is Angry;
// Equivalent to:
// if ( enemy has Pain ) enemy is Angry;
...
enemy: if ( can See( target ) ) attack();
// Equivalent to:
// if ( enemy can See( enemy.target ) ) enemy.attack();
The above would create a new Actor of the Enemy type, randomly selected from those registered types matching the current set of "of" qualifiers: Actors of Enemy type available on the current floor, at the current difficulty setting and matching the current floor's environment status. The union of qualifiers represents the pool from which the enemy's type would be randomly selected prior to instantiation. The pseudorandom "rand" selector being deterministically seedable at the outset, of course.
Then the enemy.attack() function may perform a different set of logic depending on whether it entered the "Angry" state due to it having the Pain status, i.e., more than one set of "methods" could be registered for the Actor, and if the Enemy has an Angry state that defined a different .attack() method, it would be called rather than the Enemy's default attack() method.
The attack() function(s) would not be called if the status of sighting its current target is missing. Furthermore, the state transitions would have a default "on" method that is called when entering such a state:
Code: [Select]
Dragon:Enemy{
...
on: Pain{ is Bleeding; }
on: Death{ floor.addAt( self.position, new rand Drop of self:[ drops, inventory, floor.level ] );
...
}
Also note the "with [object]" shorthand of "[object]:", which selects the given Object/Actor/Entity as the default scope for the duration of the following statement / block.
A form of compile time static type analysis could generate warnings if unique / non-eventful, and possibly misspelled statuses/states are applied to Actors.
This is a hypothetical syntax, of course; I'm only mostly crazy enough to implement such a domain specific language, and can neither confirm nor deny whether several iterations of cross platform virtual machines already exist and are hungry for construction of a language other than Assembly or C... Mostly, I'm interested in what features / syntax others would envision an RL lang of having.
The obvious response that few if any would bother tinkering with a new language just to utilize some newfangled portable rogulike operating system is a given; Thus, please ignore the difficulty and insanity required to achieve such a goal and instead approach the question as an outlandish thought experiment:
What if...