31
Early Dev / Re: Ultima Ratio Regum (v 0.7 released, 18th April!)
« on: July 19, 2016, 05:38:26 PM »
Wow, this looks absolutely awesome. Is this moddable?
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.
32
Design / Re: Corridors considered harmful
« on: July 19, 2016, 03:42:47 PM »
I think in a stealth-centric roguelike corridors could be made interesting. The player character should be inferior in combat to almost anything else, so that fighting one-on-one in itself is already dangerous. Corridors become about controlling less visibility at the cost of having less freedom of movement.
With multi-tile creatures corridors become a safe escape, which doesn't necessarily translate into trivially solved problems – have smaller enemies with higher chance to detect you, for instance, or make any route necessarily go through a room with a bigger enemy.
With multi-tile creatures corridors become a safe escape, which doesn't necessarily translate into trivially solved problems – have smaller enemies with higher chance to detect you, for instance, or make any route necessarily go through a room with a bigger enemy.
33
Programming / Re: Sewer generation
« on: July 06, 2016, 07:54:34 AM »
The Huffman solution looks quite good, but is not sufficient. Generating believable positions for feeds and sinks is necessary, too, otherwise feeds/sinks being too close to each other leads to undesirable clumping of canals. Also all canals still have a width of 1 in my code, but that should be easy to fix.
One problem of the Huffman solution is that the distance check (which determines the cost of connecting to elements) needs to run across a whole canal if one of the elements to be connected is a canal. That's quite expensive.
Also there is a memory leak either in my implementation or in sbcl. Running the generation 3 to ~100 times (depending on the number of feeds/sinks) leads to sbcl crashing with an exhausted heap. That shouldn't be happening – the results of the tests I did all were thrown away and shouldn't impact memory usage at all.
One problem of the Huffman solution is that the distance check (which determines the cost of connecting to elements) needs to run across a whole canal if one of the elements to be connected is a canal. That's quite expensive.
Also there is a memory leak either in my implementation or in sbcl. Running the generation 3 to ~100 times (depending on the number of feeds/sinks) leads to sbcl crashing with an exhausted heap. That shouldn't be happening – the results of the tests I did all were thrown away and shouldn't impact memory usage at all.
34
Programming / Re: Sewer generation
« on: July 04, 2016, 03:39:07 PM »
This is not a topic about game design, it is about solving a programming problem.
More practically: Every time there is an new post here I am happy to get an answer. Instead I now have not one (which was fine) but three posts telling me that solving this problem may not be a worthy endeavor.
Unless you have something to add regarding writing and algorithm which does what I specified earlier I ask you to refrain from posting here anymore.
In more constructive news, I implemented the solution with first building the tree. It still needs some polish to be more efficient and retain more valuable information (why did I decide to screw both of these up at once?), but it works.
More practically: Every time there is an new post here I am happy to get an answer. Instead I now have not one (which was fine) but three posts telling me that solving this problem may not be a worthy endeavor.
Unless you have something to add regarding writing and algorithm which does what I specified earlier I ask you to refrain from posting here anymore.
In more constructive news, I implemented the solution with first building the tree. It still needs some polish to be more efficient and retain more valuable information (why did I decide to screw both of these up at once?), but it works.
35
Programming / Re: Sewer generation
« on: July 04, 2016, 01:29:27 PM »
I am specifically not interested in posts telling me not to write an algorithm for this. If you think I'm overdoing it that's fine, but there is no point in writing a post about it.
It's not about realism, it is about suspension of disbelief. The whole game will take place in a sewer system, don't you maybe think that I should get that aspect at least partially right?
Look at this sewer network:
My original idea is quite code-heavy. It's hard to split it into different functions and the two functions I could extract are monstrous. That is, they've got more vertical lines than my monitor, which is not acceptable.
I'm now trying to use a kind-of Huffman encoding on the feeds and sinks to generate the abstract structure of the network before painting it onto the map.
It's not about realism, it is about suspension of disbelief. The whole game will take place in a sewer system, don't you maybe think that I should get that aspect at least partially right?
Look at this sewer network:
Code: [Select]
#####~~~######
#####~~~######
#####~~~~~~~~~
~~~~~~~~~~~~~~
######~#######
######~#######
######~~~~~~~~
######~~~~~~~~
##############
It looks wrong. It isn't believable. It's obvious that this doesn't work.My original idea is quite code-heavy. It's hard to split it into different functions and the two functions I could extract are monstrous. That is, they've got more vertical lines than my monitor, which is not acceptable.
I'm now trying to use a kind-of Huffman encoding on the feeds and sinks to generate the abstract structure of the network before painting it onto the map.
36
Programming / Re: Sewer generation
« on: July 03, 2016, 06:58:23 PM »
I wouldn't accomplish what I want because this way the capacity of the streams isn't consistent. I think overflowing due to heavy rain might be an interesting addition to the game mechanics later.
37
Design / Re: Corridors considered harmful
« on: July 03, 2016, 04:12:36 PM »Nah, that post here seems very much more comprehensive:Most of the thread boils down to "Guys corridors are bad; trust me I'm right and also all the classic roguelikes are shit." though.
Please offer an alternative.
I would remind you that the typical level of engagement in this thread has been along the lines of "What?? If you don't have corridors, you won't have any walls at all!!!"
I take the point, and agree that games where corridors are always the optimal place to fight are boring, but a game where corridors are never the optimal place to fight because there are no corridors would also be pretty dull. And where do you go from there? Fighting with your back to a wall is always optimal so you take out all the walls? I would say that a lot of roguelikes would be improved by having significantly less corridors, but I wouldn't get rid of them entirely.But you answered that with such an infuriatingly dismissive attitude that the impression is that you just want to rave about some pet peeve instead of making a coherent point.
In the same way as everything else in a tactical game, you ideally want to make it so that fighting in a corridor is sometimes optimal and sometimes not. Fortunately, there are an absolute shit-tonne of mechanics you can employ to this end, some of which are so common as to be almost ubiquitous in Roguelikes anyway. Such as:
- The risk of getting trapped between two enemies
- Limited time to kite enemies back to corridors (hunger clock)
- Limited vision in corridors (darkness, corners)
- Enemies difficult to kite (ranged enemies, fast enemies, teleporting enemies, smart enemies, fleeing thieves)
- Area-of-effect abilities (spells, Brogue-like weapons)
- Bouncing spells (magic missile)
- Allies
- Different terrain types (water, high ground)
- Mana-/Stamina-limited abilities
- Reflecting explosions
- Dodging mechanics that require an empty space
- Barriers to retreating indefinitely (closing doors)
- And Many More!
Something I've not seen any roguelikes do but that might be quite cool would be to model the way that in Dark Souls and/or real life, you don't want to fight in enclosed spaces with certain weapons because of the difficulty of getting your swing on. An accuracy modifier based on your weapon and the number of wall tiles you're next to would be a pretty straightforward way of doing it, and may make the choice of where to fight a bit more interesting.
38
Programming / Sewer generation
« on: July 03, 2016, 02:53:23 PM »
I am working on a roguelike that's supposed to take place in a sewer system.
My idea is to first generate the underground canals themselves, border them with walkways and then let a dungeon builder plan out some dwelling places for denizens in the sewers.
Unfortunately I am quite stumped on how to generate the system of canals in the first place.
Canals should either begin at a feed or another canal and should end either at a sink or a canal. The graph of canals should be a forest.
Every feed and every sink has a capacity and the sum of capacities of sinks in a given tree should be at least as large as the sum of the capacities of feeds in the same tree.
One idea I have is to keep a list of all feeds, ordered in capacity from highest to lowest. Take the feed with the highest capacity, do a Dijkstra search for the nearest sink, substract the minimum of the capacities of the feed and sink from their respective capacities, if the capacity of the feed is still not 0, reinsert it into the list of feeds, if the sink has a capacity of 0 remove it as a valid target, repeat.
The Dijkstra search could be cheaper across tiles where there already is water. Also it needs to be tuned somehow to prefer straight lines – keeping track of the direction of the last step and making a step in any other direction more costly should do the trick.
This seems kind of nice for my purposes, but it has one large flaw: All of the canals end up with a width of exactly one tile. I had the idea of making canal tiles blocking for the Dijkstra search and making tiles next to a canal cheaper instead, but that means that canals will end up winding around sinks/feeds and will also path to different sinks than if they could just path straight through the canal.
Different idea: Every canal tile is represented by a canal ID and it's distance from the source of the canal of that ID. Every canal ID is also associated with a capacity.
The Dijkstra search runs as normal, but steps between tiles with the same canal ID can only happen downstream, that is, to tiles with ha higher distance to the source of that canal. When a canal is created, all the tiles it crosses are appropriately set, only that any tile with an existing canal ID downstream from where the canal enters that old canal and upstream from where the canal leaves the old canal gets a new canal ID. The capacity of the new canal is checked to decide whether it needs to be widened. The tiles created by widening get their distance value from the lowest distance neighbor tile of the same ID.
That seems awfully complex. Does anybody have experience with generating something like this? Or ideas how to simplify what I tried to describe here? Questions for clarification? Some pointers how the previous may fail spectacularly?
If it is of any consequence: I am writing this in Common Lisp with the help of "defenum", "fset" and "croatoan".
My idea is to first generate the underground canals themselves, border them with walkways and then let a dungeon builder plan out some dwelling places for denizens in the sewers.
Unfortunately I am quite stumped on how to generate the system of canals in the first place.
Canals should either begin at a feed or another canal and should end either at a sink or a canal. The graph of canals should be a forest.
Every feed and every sink has a capacity and the sum of capacities of sinks in a given tree should be at least as large as the sum of the capacities of feeds in the same tree.
One idea I have is to keep a list of all feeds, ordered in capacity from highest to lowest. Take the feed with the highest capacity, do a Dijkstra search for the nearest sink, substract the minimum of the capacities of the feed and sink from their respective capacities, if the capacity of the feed is still not 0, reinsert it into the list of feeds, if the sink has a capacity of 0 remove it as a valid target, repeat.
The Dijkstra search could be cheaper across tiles where there already is water. Also it needs to be tuned somehow to prefer straight lines – keeping track of the direction of the last step and making a step in any other direction more costly should do the trick.
This seems kind of nice for my purposes, but it has one large flaw: All of the canals end up with a width of exactly one tile. I had the idea of making canal tiles blocking for the Dijkstra search and making tiles next to a canal cheaper instead, but that means that canals will end up winding around sinks/feeds and will also path to different sinks than if they could just path straight through the canal.
Different idea: Every canal tile is represented by a canal ID and it's distance from the source of the canal of that ID. Every canal ID is also associated with a capacity.
The Dijkstra search runs as normal, but steps between tiles with the same canal ID can only happen downstream, that is, to tiles with ha higher distance to the source of that canal. When a canal is created, all the tiles it crosses are appropriately set, only that any tile with an existing canal ID downstream from where the canal enters that old canal and upstream from where the canal leaves the old canal gets a new canal ID. The capacity of the new canal is checked to decide whether it needs to be widened. The tiles created by widening get their distance value from the lowest distance neighbor tile of the same ID.
That seems awfully complex. Does anybody have experience with generating something like this? Or ideas how to simplify what I tried to describe here? Questions for clarification? Some pointers how the previous may fail spectacularly?
If it is of any consequence: I am writing this in Common Lisp with the help of "defenum", "fset" and "croatoan".
39
Classic Roguelikes / Re: Dwarf fortress
« on: February 16, 2012, 03:16:04 PM »
The eye tooth (as far as I know) is the canine tooth (at least that's how Wikipedia translates it for me as such).
40
Off-topic (Locked) / Re: Foreigners
« on: February 12, 2012, 09:28:02 PM »Quote
I think we have to think about preserving polar cultures which are vulnerable to outside influences.I have never seen any indication of immigration undermining culture. Tradition that deserves to be preserved is preserved. The people screaming the loudest, that culture is destroyed, are the ones knowing the least about what their culture actually is. If they really would like to preserve their culture they would create cultural values. Instead they just consume and even laugh about the people who dare try be creative.
Quote
Foreigners just suck that way, they become criminals easily. Maybe that's the reason why their own countries also suck (like Somalia, one of the worst places on earth).I think you have some serious misunderstandings about how this stuff works.
Foreigners get criminal more easily because it's harder for them to come by with legal means. Just a side note: That's why you need to make sure they can live a life that's worth living - whether that is through jobs, social care or whatever is an entirely other question.
Somalia is one of the worst places of the world because it is the dumping ground of the world and because they were a fishing nation that was outfished by "us" and not because "those people" are predetermined for criminality by their biology or culture.
Quote
Besides even in best case scenario, what is the point of taking foreigners? Why do we "need" them? And why can't they live in their own country? If their country sucks, why don't they ask the right question: hey, why does our country suck?We do need foreigners because we need the diversity. Cultural incest is only this much better than biological incest.
And I can very much understand why they leave their country, if it sucks. When it sucks to the point where I am likely to die when I try to change anything about my situation (or I die either way), then I go elsewhere. There's no point to try to fight a superior force when there is a way to outrun it. I thought you were playing roguelikes? Isn't this one of the first lessons of DCSS?
Quote
Quite a lot of money has been put into development of poor countries, but what are the results? How long we have to give them money?Yeah, and a lot more is taken back. We lend them money and thus the debt grows higher and higher so they can't ever pay us back.
And to the whole "job" thing: I never quite understood why we need full employment. We have the means to produce enough for everyone without having anyone employed and the pressure of needing a job is (in my experience) very much detrimental to the amount of creative work one is able to do. Most people too lazy to do anything productive haven't been lazy always but just gave up and "had enough".
41
Programming / CL scent-map - datastructures and algorithms for maps in a broader sense
« on: February 12, 2012, 05:06:20 PM »
So, I know Common Lisp is not widely used in the roguelike community (or anywhere else, for that matter) but it is my favourite language and therefore I need some basis on which I can build a roguelike.
I, for now, started with a library for maps. Right now I've got the representation of a single tile and maps done.
The results can be downloaded via
The basic principle behind a map is the following: A map consists of a set of directions and a set of positions, where tiles (called "cells" in the library) can be stored. In any map for any position and neighbour another position can be computed. This can be used to construct a graph, by filling the positions of a map with cells and then connecting those cells to each other based on the positions that lie in the defined directions. With this it's trivial to define subclasses of cell-grid (the basic map class) to get maps where any tile has 4, 6 or 8 neighbours (Von-Neumann- hexagonal and Moore-neighbourhood, respectively), general graph-like maps or whatever you can make up. Just define a way of finding a position, calling a function on every possible position and define how to translate the defined directions into the neighbours of a position.
Cell grids with Von-Neumann-, hexagonal and Moore-neighbourhood are already implemented as well as cell grids which are just a general graph.
The "real" work is done in the cells. Any cell knows what neighbour lies in which direction, so anything related to that (movement, diffusion of scent, fov) can be computed on it. Any cell doubles as a stack of cells, so actors, items, buildings, different types of terrain and whatever can be implemented as cells. Pushing a cell onto another cell preserves the neighbours, so the cell pushed has the neighbours of the cell it was pushed onto, popping a cell of a stack disconnects that cell of all it's neighbours and connects the underlying cell to those neighbours, all with directions intact of course.
Currently there are basic cells without any functionality and cells which can be blocked or not. Terrain cells, scent tracking cells, actors and items are planned to be implemented later.
Directions are an own class on which the generic functions SAME-DIRECTION-P and OPPOSITE-DIRECTION need to be defined.
Currently simple directions (which are compared per EQ and are their own opposite), angular directions (who have a angle in the interval [0 360)) and named directions (who have a name and a defined opposite direction with a name) are implemented. Anything goes, as long as
(SAME-DIRECTION-P DIRECTION (OPPOSITE-DIRECTION (OPPOSITE-DIRECTION DIRECTION))) => T
holds true for any value of DIRECTION.
Missing functionality includes
- diffusing and storing scent
- computing a view of a map as seen from a certain position
- map generation algorithms
I designed the current interface via concentrating on the needed generic functions. That means, that any map generation algorithms will be implemented via a class whose slots are the parameters to the map generator. Generating a map is done via calling the generic function GENERATE-MAP on one such object and an optional post-processor, that might place items and monsters, fill dead ends...
I posted about this on rec.games.roguelikes before and the reaction was less then enthusiastic.
I was told that my approach used too much overhead. Yet I don't see any way to do all that stuff as clean as I did it until now - for a new kind of map topology I only need to implement a few methods with a well defined interface and with only that I have a plethora of functions available to do anything I need to do on maps. Debugging is almost trivial in most cases and even using different kinds of topologies in the same game has it's uses - imagine the difference between a castle and a cave and you might know what I mean, not even taking into account the kinds of spells that can be implemented through this.
Any comments?
And, for inspiration: What functions need to be available in terms of terrain? Being blocked shouldn't depend on terrain alone.
I, for now, started with a library for maps. Right now I've got the representation of a single tile and maps done.
The results can be downloaded via
Code: [Select]
hg clone http://hg.sharesource.org/clscentmapYou need mercurial to do this.The basic principle behind a map is the following: A map consists of a set of directions and a set of positions, where tiles (called "cells" in the library) can be stored. In any map for any position and neighbour another position can be computed. This can be used to construct a graph, by filling the positions of a map with cells and then connecting those cells to each other based on the positions that lie in the defined directions. With this it's trivial to define subclasses of cell-grid (the basic map class) to get maps where any tile has 4, 6 or 8 neighbours (Von-Neumann- hexagonal and Moore-neighbourhood, respectively), general graph-like maps or whatever you can make up. Just define a way of finding a position, calling a function on every possible position and define how to translate the defined directions into the neighbours of a position.
Cell grids with Von-Neumann-, hexagonal and Moore-neighbourhood are already implemented as well as cell grids which are just a general graph.
The "real" work is done in the cells. Any cell knows what neighbour lies in which direction, so anything related to that (movement, diffusion of scent, fov) can be computed on it. Any cell doubles as a stack of cells, so actors, items, buildings, different types of terrain and whatever can be implemented as cells. Pushing a cell onto another cell preserves the neighbours, so the cell pushed has the neighbours of the cell it was pushed onto, popping a cell of a stack disconnects that cell of all it's neighbours and connects the underlying cell to those neighbours, all with directions intact of course.
Currently there are basic cells without any functionality and cells which can be blocked or not. Terrain cells, scent tracking cells, actors and items are planned to be implemented later.
Directions are an own class on which the generic functions SAME-DIRECTION-P and OPPOSITE-DIRECTION need to be defined.
Currently simple directions (which are compared per EQ and are their own opposite), angular directions (who have a angle in the interval [0 360)) and named directions (who have a name and a defined opposite direction with a name) are implemented. Anything goes, as long as
(SAME-DIRECTION-P DIRECTION (OPPOSITE-DIRECTION (OPPOSITE-DIRECTION DIRECTION))) => T
holds true for any value of DIRECTION.
Missing functionality includes
- diffusing and storing scent
- computing a view of a map as seen from a certain position
- map generation algorithms
I designed the current interface via concentrating on the needed generic functions. That means, that any map generation algorithms will be implemented via a class whose slots are the parameters to the map generator. Generating a map is done via calling the generic function GENERATE-MAP on one such object and an optional post-processor, that might place items and monsters, fill dead ends...
I posted about this on rec.games.roguelikes before and the reaction was less then enthusiastic.
I was told that my approach used too much overhead. Yet I don't see any way to do all that stuff as clean as I did it until now - for a new kind of map topology I only need to implement a few methods with a well defined interface and with only that I have a plethora of functions available to do anything I need to do on maps. Debugging is almost trivial in most cases and even using different kinds of topologies in the same game has it's uses - imagine the difference between a castle and a cave and you might know what I mean, not even taking into account the kinds of spells that can be implemented through this.
Any comments?
And, for inspiration: What functions need to be available in terms of terrain? Being blocked shouldn't depend on terrain alone.
42
Programming / Re: A world without money
« on: November 09, 2009, 04:38:43 PM »
This idea sounds wounderful. You could try this with other ideas too. Every social and economical idea in the end consists of certain rules, which could be implemented in games.
You could even start experimenting with those ideas to test those models.
You could even start experimenting with those ideas to test those models.
43
Programming / Re: A world without money
« on: November 03, 2009, 01:08:13 PM »
The wealth idea is used in the free (unluckily there is only a german version) P&P-RPG EPOS (www.epos-fantasy.de).
I'll try to tell in short how the system works: Shops are represented as parts of organizations - you don't really have to care what different shops you have, only whether the organization that can supply you with a certain item is present at your current location.
For buying any item from any organization you have only one try - buying the same item from a different organization or buying another item from the same organization should be no problem.
When buying an item a roll on wealth is done. Any item has a certain price - this is the number of successes you need in the roll on your wealth - how you measure those successes is not really important.
When you miss the roll by x successes, you either buy the item anyway and loose x points in wealth or you decide not to buy the item and just give up.
When you succeded with your skill roll you get the item.
When you bought the item before, you can try to buy more of the item - this time with the price raised by one. This way you wont be able to buy 500 potions of heal wounds only because their price is far below your wealth.
How you represent organizations in your game (as shops or maybe multiple shops or even with multiple shops which give you only access to a limited subset of all the items a certain organization covers or as whatever you would like) is up to you.
How can you raise wealth?
Whenever you find something valuable and manage to bring it back to your home/sell it/whatever you do another test on your wealth. When you get *less* successes than the price of the item is, you get your wealth raised by (+ (random price) 1), otherwise your wealth will stay the same - grinding for small items won't be really worthwhile when they will raise your wealth as good as never.
For wealth-only items you could do the roll as soon as you pick them up. This would take out the possibility of stashing them away for doing a grinding-circle of buying and selling. You could even limit selling to once in a certain period.
I'll try to tell in short how the system works: Shops are represented as parts of organizations - you don't really have to care what different shops you have, only whether the organization that can supply you with a certain item is present at your current location.
For buying any item from any organization you have only one try - buying the same item from a different organization or buying another item from the same organization should be no problem.
When buying an item a roll on wealth is done. Any item has a certain price - this is the number of successes you need in the roll on your wealth - how you measure those successes is not really important.
When you miss the roll by x successes, you either buy the item anyway and loose x points in wealth or you decide not to buy the item and just give up.
When you succeded with your skill roll you get the item.
When you bought the item before, you can try to buy more of the item - this time with the price raised by one. This way you wont be able to buy 500 potions of heal wounds only because their price is far below your wealth.
How you represent organizations in your game (as shops or maybe multiple shops or even with multiple shops which give you only access to a limited subset of all the items a certain organization covers or as whatever you would like) is up to you.
How can you raise wealth?
Whenever you find something valuable and manage to bring it back to your home/sell it/whatever you do another test on your wealth. When you get *less* successes than the price of the item is, you get your wealth raised by (+ (random price) 1), otherwise your wealth will stay the same - grinding for small items won't be really worthwhile when they will raise your wealth as good as never.
For wealth-only items you could do the roll as soon as you pick them up. This would take out the possibility of stashing them away for doing a grinding-circle of buying and selling. You could even limit selling to once in a certain period.
44
Classic Roguelikes / Re: DCSS Junk potions and scrolls
« on: October 26, 2009, 06:09:32 PM »
Scrolls of Random Uselessness are actually good for training spellcasting when you don't have that skill.
45
Programming / Re: Limb-oriented skill system - You see any pitfalls?
« on: October 22, 2009, 12:54:15 PM »
Thanks to you I now have a really clear idea of what the game should be like and how it would have to be implemented.
Freak Circus will be a game built around mutations. It's the only form of character advancement and will be the center of gameplay. Nearly everything will either be dependent on or will effect the structure on your body. I'm a bit unclear of the goal of the game, but I think about putting in a story generator when the rest of the game is done.
Bodys will be represented as I described in my starting post, with a few changes of course. The neat part is, to represent items in the same way. This way, you will get to use anything you may find in any way the game allows you with anything else - this means, you can wield them with one of your grabbing bodyparts, eat them, take them apart (which might be useless at a basic level) or just throw them away.
Monsters and you yourself will just be an interface to an AI/the player and a bodystructure. Items will be just a reference to a bodystructure. This way I can do the whole corpses-thing just with reattaching the monster-body to an item.
An additional system, which should be easy with CL, would be parsing bodystructures into a (genetic) code, which would in turn be used to determine preferences for certain mutations. It will be harder to come up with a good system, when it should come into the game.
Then eating could lead to copy genetic codes out of the eaten parts and include them into the genetic code in a random mode (overwriting strands, placing between strands, at the beginning or the end... Function passing seems like a good way of doing this). To get desired traits, you would eat limbs which have the desired trait and in this way enhance the chance of getting this trait hen mutation gets triggered. You are what you eat.
This is the basic system. I've got some ideas about style and story generation in mind, but they aren't so much related to the topic and the last one will presumably be pretty hard to do.
Freak Circus will be a game built around mutations. It's the only form of character advancement and will be the center of gameplay. Nearly everything will either be dependent on or will effect the structure on your body. I'm a bit unclear of the goal of the game, but I think about putting in a story generator when the rest of the game is done.
Bodys will be represented as I described in my starting post, with a few changes of course. The neat part is, to represent items in the same way. This way, you will get to use anything you may find in any way the game allows you with anything else - this means, you can wield them with one of your grabbing bodyparts, eat them, take them apart (which might be useless at a basic level) or just throw them away.
Monsters and you yourself will just be an interface to an AI/the player and a bodystructure. Items will be just a reference to a bodystructure. This way I can do the whole corpses-thing just with reattaching the monster-body to an item.
An additional system, which should be easy with CL, would be parsing bodystructures into a (genetic) code, which would in turn be used to determine preferences for certain mutations. It will be harder to come up with a good system, when it should come into the game.
Then eating could lead to copy genetic codes out of the eaten parts and include them into the genetic code in a random mode (overwriting strands, placing between strands, at the beginning or the end... Function passing seems like a good way of doing this). To get desired traits, you would eat limbs which have the desired trait and in this way enhance the chance of getting this trait hen mutation gets triggered. You are what you eat.
This is the basic system. I've got some ideas about style and story generation in mind, but they aren't so much related to the topic and the last one will presumably be pretty hard to do.