1
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.
Pages: [1] 2
2
Programming / Re: L-Systems
« on: April 28, 2013, 12:17:06 AM »
I give up on the L-System front. I'm quite happy with what I achieved so far but my motivation has burned out too much to push it further. Here's a screen capture of a demo I've scripted in the last week. All the animations visible in the above video are real time generated, rendered at 60 FPS in my Grove Script interpreter and captured with hypercam. As the script is only 1KB big, the perceived complexity and the way the result is randomized is a nice demonstration of the power of L-Systems and emergence.
http://www.youtube.com/watch?v=twZLhxi_964
And this is how the script of the demo looks like:
http://www.youtube.com/watch?v=twZLhxi_964
And this is how the script of the demo looks like:
Code: [Select]
//set some basic constant parameters to be used in expressions
//feel free to play with the values and see how the animation
//adapts
set speed, 15
set pause, 15
set fadetime, 15
set budstep, 5
set maxage, 80
set leafAge, 5
//let the size of the structure adapt with window size
set step, 0.4*_height/480
//these variables change every frame because they all depend on the current
//value of the time() function.
//Thanks to the modulo operate age wraps around at maxage.
set age, (speed*time()) % maxage
set fade, min(1, (maxage-age-pause) / fadetime)
out fade
set age, 2.5*age^0.55
set frac, max(0.01, frac(age))
//each structure should look unique.
//So we use a different random seed for every new structure
out 'rnd seed, floor(time()*speed/(maxage))
shuffle floor(time()*speed/(maxage))
//init the turtle
dir random(360)
pos 0, step*(5*age-100)
//set the axiom of the 'plant' structre
seed plant, A(0,0,1)
//apply the ruleset 'r1' as often as the plant is old.
repeat age
grow plant, r1
//fun info: how many buds were generated?
out budCnt
//render 'plant' twice - mirrored.
push
rotate -45
run plant
pop
rotate 135
run plant
//Now the Tokens that the L-System operates upon are defined.
//light blue tips of the structure
#A(age, angle)
run shade(leafAge/frac)
size frac^0.5
move step*frac^0.5, angle
//what becomes of A in the next cycle - a simple curve
#B(t, angle)
run shade(leafAge/(t+frac))
size (t+frac)^0.5
move step*(t+frac)^0.5, angle
//B becomes C when it's old enough to spawn leaves - does the same thing, though
#C(t, angle)
run B(t, angle)
//a growing leaf
#L(t, angle)
run leaf(t+frac, angle)
//a finalized leaf
#xL(t, angle)
run leaf(t, angle)
//a growing bud
#Y(t, spread, angle)
run bud(0.3*(t+frac), (spread+frac)*budstep, 0.1*angle)
//a finalized bud
#xY(t, spread, angle)
run bud(0.3*(t+frac), (spread+frac)*budstep, 0.1*angle)
//render a bud
#bud(len, angle, curve)
run budshade(1/len)
//left side
push
size 2*len^0.3
rotate angle
move len^0.3, angle
size len/2
rotate -90
move len, -angle
pop
//right side
push
size 2*len^0.3
rotate -angle
move len^0.3, -angle
size len
rotate 90
move len, angle
pop
//stem
rotate curve
move 0.55*len^0.7
//render a leaf
#leaf(len, ang)
size 1
rotate 10*ang*len^0.6
move 0.5*len^0.3
move len^0.6, ang*(60+len*5)
rotate 180 - ang*0.4*(60+len*10)
move 0.5*len^0.5, -ang*(len*5)
move 0.7*len^0.5, ang*(len*10)
//color buds
#budshade(alpha)
visible alpha * fade
rgb 1.0-0.8*alpha*alpha, 0.6*alpha+0.2, 0.2*alpha*alpha
//color rest
#shade(alpha)
visible alpha * fade
rgb 1.0-0.5*alpha, 0.5*alpha+0.5, 0.3*alpha
#[
push
#]
pop
//The rules are evaluated in the order of appearance.
//rare rules appear first, if all are skipped the general case is usually to just grow the existing tokens
#r1
//BRANCHING
//higher c makes a vine less likely to bend or split but increases chance to spawn buds
A(i, j, c) : rnd(0, c) > 2+budCnt -> B(1, j) Y(0, 1, j)
raise budCnt, 1
//if old enough there's a chance to split into 3
A(i, j, c) : i > c and rnd() < 0.5/c -> B(1, j) [ A(0, rnd(-40,-60), c+2) ] [ A(0, rnd(40,60), c+2) ] A(0, 0, c+1)
//...or into 2
A(i, j, c) : i > c and rnd() < 0.5/c -> B(1, j) [ A(0, rnd(-40,-60), c+1) ] A(0, rnd(40,60), c+1)
//or just change the direction
A(i, j, c) -> B(1, j) A(i+1, j+rnd(-90, 90)/(c+1), c)
//LEAVES
//based on the curvature leaves spawn on different sides
B(i, j) : j < 0 and i = leafAge-1 -> C(i+1, j) [ L(0, 1) ]
B(i, j) : j > 0 and i = leafAge-1 -> C(i+1, j) [ L(0, -1) ]
//GROWTH
//and of course everything needs to grows
Y(i, j, k) -> Y(i+1, j+1, k) xY(i, j, k)
B(i, j) -> B(i+1, j)
C(i, j) -> C(i+1, j)
L(i, j) : i > 1+rnd(7) -> xL(i+1, j)
L(i, j) -> L(i+1, j)
3
Programming / Re: L-Systems
« on: April 03, 2013, 05:47:39 PM »
Sorry, I was getting ahead of myself. Gonna push to finish the interpreter + renderer first. Clean it up. Make a blogpost. Then I can delve deeper into finding out how it could be used for map generation.
4
Programming / Re: L-Systems
« on: March 30, 2013, 12:30:20 PM »
I've been thinking a bit on the connectivity problem. Before I can even start thinking about how L-Systems fit into the picture (if at all) I need to find some theory of how connections in cities and dungeons would form.
Consider the picture below. Think of the black lines as roads or tunnels. Now you start building a new one (the red line). Where would you need to stop so the result you generate makes sense in the big picture. I mean we know how a city looks like but what are the rules? Do you know any theories/algorithms regarding that problem? Is this a variant of the "Space Colonisation" approach we discussed earlier? (I see how it applies to trees but don't think the same would work to build web-like structures)
My guess is that you'd continue to build the red line segment until the distance to other segments (green line) become closer then the distance to the origin of the red line. I think you could calulate the point - not locally but if you know the existing line segments (black). I guess that results in an algorithm that will hierarchically partition the space in an efficient and hierarchical way. Has it been done before? (Usually I just keep reinventing wheels with thoughs like that...)
Consider the picture below. Think of the black lines as roads or tunnels. Now you start building a new one (the red line). Where would you need to stop so the result you generate makes sense in the big picture. I mean we know how a city looks like but what are the rules? Do you know any theories/algorithms regarding that problem? Is this a variant of the "Space Colonisation" approach we discussed earlier? (I see how it applies to trees but don't think the same would work to build web-like structures)
My guess is that you'd continue to build the red line segment until the distance to other segments (green line) become closer then the distance to the origin of the red line. I think you could calulate the point - not locally but if you know the existing line segments (black). I guess that results in an algorithm that will hierarchically partition the space in an efficient and hierarchical way. Has it been done before? (Usually I just keep reinventing wheels with thoughs like that...)
5
Programming / Re: combat/conflict resolution system development
« on: March 29, 2013, 10:34:10 AM »
A fighting mechanic i once experimented with wsas trying to simulate swordfighting as a process of trading blows that usually don't deal damage until one combatant fails to parry. But hits are very likely to be severe if not fatal. To score a hit you need an advantage. Advantage builds or diminishes over time like the combat in a DOTA match can flow back and forth. Usually when the enemy has advatage you can sidestep or take a step back fom your oponent to regain advantage.
6
Programming / Re: L-Systems
« on: March 29, 2013, 01:38:52 AM »
If I am to shift my projects goal from rendering fractals to game-map generation I'll have to refactor my code anyway. So why not decouple the L-System code from the domain specific commands and functions completely? Is there anyone interested in some general purpose L-System interpreter in form of a small C++ library? I don't want to make the extra effort in vain but if there's an interest I don't mind to open source it.
7
Programming / Re: L-Systems
« on: March 27, 2013, 11:34:18 PM »
Damn, I'm glad I asked. I was close to shelve the project. Now, I got so much new input my vigor is restored! 
@Naughty: Hadn't heard of Space Colonisation. (Awesome name) But the longer I think about it the more I see that the problem that technique tries to adress is indeed a problem. At first I thought that something similar could be integrated into the L-System production conditions but the two-passes process of first generating a string of symbols, then executing it is a problem. The conditions for phase one would require knowledge from phase two. Also this approach seems to be based on a breath first execution. Not sure if that's true for all L-System based systems but my implementation is depth first.
The screenshots you posted remind me of Voronoi diagrams. Is this due to how you render the graphs you generated?
@John: Not sure I can follow. Wouldn't interesting splits suffer from the same problem that they overlap in a manner that's hard to control and work with?
@Paul: Looks like you got a real interesting job! Reminds me of this guy: http://www.ted.com/talks/michael_hansmeyer_building_unimaginable_shapes.html
@Naughty: Hadn't heard of Space Colonisation. (Awesome name) But the longer I think about it the more I see that the problem that technique tries to adress is indeed a problem. At first I thought that something similar could be integrated into the L-System production conditions but the two-passes process of first generating a string of symbols, then executing it is a problem. The conditions for phase one would require knowledge from phase two. Also this approach seems to be based on a breath first execution. Not sure if that's true for all L-System based systems but my implementation is depth first.
The screenshots you posted remind me of Voronoi diagrams. Is this due to how you render the graphs you generated?
@John: Not sure I can follow. Wouldn't interesting splits suffer from the same problem that they overlap in a manner that's hard to control and work with?
@Paul: Looks like you got a real interesting job!
Reminds me of this guy: http://www.ted.com/talks/michael_hansmeyer_building_unimaginable_shapes.html8
Programming / Re: L-Systems
« on: March 26, 2013, 03:56:10 PM »
Hilbert Curves and Julia Sets are really basic. The L-Systems as presented in the book I linked can do a lot more.
For example you can provide conditions that have to be fulfilled before a production triggers. I guess you could put most of the necessary checks (like boundaries) into the conditions. If the structure you want to generate isn't valid it won't be generated.
Lack or unpredictability of variations shouldn't be an issue, either. I wouldn't change the productions at all but tweak the conditions and parameters.
Foo : (rnd() > 0.3) -> Bar
Foo -> Boo
30% of Foo would evolve to Bar and 70% to Boo.
Different seeds would yield different maps with exactly the same rules. Or you could change the threshold (0.3) slightly. If not all seeds produce maps you like you could provide a list of seeds that you know work well. Elite did that.
I guess the biggest problem is, that the idea of turtle-graphics doesn't work to well if you want to operate on a grid and can't have overlapping structures. How would you check for let alone prevent collisions?
But the constraints of Turtle Graphics are not a limitation of L-Systems. I'm sure one could come up with more suited backend (set of available commands and functions that can be used in the condition) if map generation were the purpose.
For example you can provide conditions that have to be fulfilled before a production triggers. I guess you could put most of the necessary checks (like boundaries) into the conditions. If the structure you want to generate isn't valid it won't be generated.
Lack or unpredictability of variations shouldn't be an issue, either. I wouldn't change the productions at all but tweak the conditions and parameters.
Foo : (rnd() > 0.3) -> Bar
Foo -> Boo
30% of Foo would evolve to Bar and 70% to Boo.
Different seeds would yield different maps with exactly the same rules. Or you could change the threshold (0.3) slightly. If not all seeds produce maps you like you could provide a list of seeds that you know work well. Elite did that.
I guess the biggest problem is, that the idea of turtle-graphics doesn't work to well if you want to operate on a grid and can't have overlapping structures. How would you check for let alone prevent collisions?
But the constraints of Turtle Graphics are not a limitation of L-Systems. I'm sure one could come up with more suited backend (set of available commands and functions that can be used in the condition) if map generation were the purpose.
9
Programming / L-Systems
« on: March 26, 2013, 11:58:52 AM »
A while ago I started to look into L-Systems because their emergent properties really fascinated me. I like how simple rules produce great complexity. There's this great book The Algorithmic Beauty of Plants on modelling plant development through L-Systems. Once you get to parametric, context-sensitve L-Systems the technique really gets powerful beyond "some kind of recursion".
I started writing a script-interpreter so I could try and experiment with the productions from the book. In my script I don't treat L-Systems as formal grammar where commands that control the turtle are symbols in the alphabet. Instead the strings of symbols the L-Systems produces map to named sequences of commands, not unlike what you'd expect from a simple imperative programming language. So, basically you can define procedures and generate procedure calls through L-Systems. But ultimately it's the same thing.
It's fun to play with but I'm not very interested in modelling plants. Have you guys ever used L-Systems for something interesting? I'm trying to come up with ideas how this could be used for procedurally generating content for games (beyond plants) like generating dungeons or citys, monsters, behavior, talent trees, branching storylines... (I'm just making things up on the spot)
I started writing a script-interpreter so I could try and experiment with the productions from the book. In my script I don't treat L-Systems as formal grammar where commands that control the turtle are symbols in the alphabet. Instead the strings of symbols the L-Systems produces map to named sequences of commands, not unlike what you'd expect from a simple imperative programming language. So, basically you can define procedures and generate procedure calls through L-Systems. But ultimately it's the same thing.
It's fun to play with but I'm not very interested in modelling plants. Have you guys ever used L-Systems for something interesting? I'm trying to come up with ideas how this could be used for procedurally generating content for games (beyond plants) like generating dungeons or citys, monsters, behavior, talent trees, branching storylines... (I'm just making things up on the spot)
10
Programming / Re: Torso & Head direction
« on: December 14, 2012, 12:12:51 PM »
Thanks for trying the demo, guys! And I'm glad to hear that you like the keyboard + mouse controlscheme because personally I found it pretty interesting, too. Maybe I'll expand on that idea over the christmas break and add some gameplay.
@AgingMinotaur, I agree that the subtle change of viewing direction despite NOT moving the mouse is a little annoying. I could imagine 2 solutions:
a) only when the mouse is getting moved the desired viewdirection is recalculated. Very easy to implement.
b) the character is always in the center of the screen and the map is scrolling. That way your mouse positiion would always be relative to the character regardless of it's current world position.
Based on your feedback I added 2 new control schemes to the demo:
I added this as "Control Scheme 2" but I can't get the strafing right on an intuitive level. :/
But it makes looking around a dedicated action (costing a turn) and I'm not sure how that affects the gameplay. Would you feel like "just" changing your facing is a waste of a turn in combat situations? Not sure.
@AgingMinotaur, I agree that the subtle change of viewing direction despite NOT moving the mouse is a little annoying. I could imagine 2 solutions:
a) only when the mouse is getting moved the desired viewdirection is recalculated. Very easy to implement.
b) the character is always in the center of the screen and the map is scrolling. That way your mouse positiion would always be relative to the character regardless of it's current world position.
Based on your feedback I added 2 new control schemes to the demo:
What I mean is: the character is facing N, you press right arrow (RA) to turn E, you press up arrow (UA) to walk E, you press and hold shift and press UA and you still move E (shift just means "no turning" but when going forward no turning is involved anyway), you hold the shift and press RA and you now move S (right arrow meaning move to the right according to character's perspective without turning). That would be what I meant and what I think would be easier to grasp.
I added this as "Control Scheme 2" but I can't get the strafing right on an intuitive level. :/
I've just tried implementing it in URR, and currently each numpad key moves you in that direction (so up is up, no matter how you face) and with shift held down, the same applies (ie up is up), and it works really well, actually.I'm not sure I understood you correctly. Is "Control Scheme 3" what you meant? I quite like it. I would prefer this over 1 and 2.
But it makes looking around a dedicated action (costing a turn) and I'm not sure how that affects the gameplay. Would you feel like "just" changing your facing is a waste of a turn in combat situations? Not sure.
11
Programming / Re: Torso & Head direction
« on: December 12, 2012, 11:54:56 PM »
I've implemented your suggestion (link). For me it seems less intuitive to press the correct key because instead of pressing into the direction you want to go you have to think relative to your current facing. With strafing (hold SHIFT) this relative movement was almost impossible to get right so now while pressing SHIFT it doesn't take the facing into account. It's okay but I think I prefered the mouse controls (press SPACE to toggle between modes) over the keyboard-only version. Is it just me?
I guess the reason why it worked well in older FPS is that they are from the ego perspective so you see the world from the characters perspective and you're less likely to think in world-coordinates then in a topdown view.
I guess the reason why it worked well in older FPS is that they are from the ego perspective so you see the world from the characters perspective and you're less likely to think in world-coordinates then in a topdown view.
12
Programming / Re: Torso & Head direction
« on: December 09, 2012, 12:49:52 AM »
Mark, your description illustrates perfectly why it could be interesting to take the characters orientation into account. But, I wonder, what solution you found to make it easy and intuitive to control your character - especially when you want to allow walking backwards and strafing I can't see it working with the established Num-Pad movement. Simulating all this without ruining the flow of the game sounds like the real challenge here. :/
When I played Mujahid yesterday the help-screen says "Use the mouse to look around and aim". It wasn't implemented that way but I kinda expected to be able to control the view direction with the mouse, while walking with the keyboard. Pretty much what you'd do in a FPS game, too. Didn't sound like a bad idea to me. So this evening I hacked together a small prove-of-concept.
http://web.pixelpracht.net/stealthRL.php
Draw some walls, then move around using WSAD. Whatever direction you point in with the mouse the characters new looking direction will become. So, you can strafe and move backward and it comes quite natural to me. What do you think?
And now I'm gonna give Vapors of Insanity a try.^^
But, I wonder, what solution you found to make it easy and intuitive to control your character - especially when you want to allow walking backwards and strafing I can't see it working with the established Num-Pad movement. Simulating all this without ruining the flow of the game sounds like the real challenge here. :/When I played Mujahid yesterday the help-screen says "Use the mouse to look around and aim". It wasn't implemented that way but I kinda expected to be able to control the view direction with the mouse, while walking with the keyboard. Pretty much what you'd do in a FPS game, too. Didn't sound like a bad idea to me. So this evening I hacked together a small prove-of-concept.
http://web.pixelpracht.net/stealthRL.php
Draw some walls, then move around using WSAD. Whatever direction you point in with the mouse the characters new looking direction will become. So, you can strafe and move backward and it comes quite natural to me. What do you think?
And now I'm gonna give Vapors of Insanity a try.^^
13
Programming / Re: Torso & Head direction
« on: December 07, 2012, 10:41:30 PM »
Thanks for all the valuable input!
I had to google 'lighthouse syndrome' but I guess now I know what you mean. The limited FoV should increase the suspense and add to the experience not make it annoying to play and I realize that's difficult, otherwise the thread wouldn't exist.
In Mujahid turning seems to take a turn, and I guess that's to prevent the behavior you called 'lighthouse syndrome'. I think it works pretty good! Feels quite 'stealthy'.
The main reason for decoupling torso & head direction (or view direction, from walking direction) was that I hoped to allow for strafing and leaning to the sides. While the latter would allow you to peek around a corner without risking to be seen yourself (at the cost of a turn), strafing allows you to move without changing your current direction. All this is meant to reinforce the idea of staying in cover, planning your next move and striking quick and well prepared.
I had to google 'lighthouse syndrome' but I guess now I know what you mean. The limited FoV should increase the suspense and add to the experience not make it annoying to play and I realize that's difficult, otherwise the thread wouldn't exist.
In Mujahid turning seems to take a turn, and I guess that's to prevent the behavior you called 'lighthouse syndrome'. I think it works pretty good! Feels quite 'stealthy'.
The main reason for decoupling torso & head direction (or view direction, from walking direction) was that I hoped to allow for strafing and leaning to the sides. While the latter would allow you to peek around a corner without risking to be seen yourself (at the cost of a turn), strafing allows you to move without changing your current direction. All this is meant to reinforce the idea of staying in cover, planning your next move and striking quick and well prepared.
14
Programming / Torso & Head direction
« on: December 07, 2012, 06:26:52 PM »
In most RLs the characters and monsters just have a position. Are there any games where the orientation of the torso and head are simulated in a gameplay-relevant way? I can't come up with a decent control scheme for the player character but imagine it could add some depth to movement and combat. Any ideas or suggestions?
15
Off-topic (Locked) / Re: Burn Out
« on: December 07, 2012, 12:01:07 PM »
I enjoy coding stuff. I know that when I get into "the zone" it's a very pleasent and relaxing experience. It should be easy to just code something for the sake of the experience but I can't do that. I just don't find the motivation to do coding for the sake of it.
So I'm always looking for the thing that set's my next coding-project apart from all the other zillions of projects/games that's been done before. But the resources I have to spend are limited. So how realistic is it to do something groundbreaking all the time? Not very, but I still need the illusion of 'meaning' to find motivation, what can I do?
I prefer to work on games because the world is full of potential players. Players can be really passionate about the games they play. The feedback you get, or just the statistics, give you the feeling that you did something significant. Statistics tell me that the last game I completed as a hobby project in a couple hundred hours spare-time was played about a hundred thousand hours by players all over the world. So other's wasted a lot more time on my product then I did creating it. I'm not even sure that's a good thing (karma wise) but it feels like my deeds are having an impact. I'm also working on games as a day-job. Some browsergame we did has 3 million players and I can't even start guessing how many million hours (man-lives?) I have helped wasting with the 'entertainment' we produce. But when I was younger it was easier to feel proud about that. Now I'd rather cure cancer or build a house or something...
So, why do I always gravitate towards the next hobby gamedev project like a moth to the light? I guess because I (sometimes) enjoy it and I'm rather good at it (coding) and I still haven't lost hope to do something really great (by whatever definition) some day if I don't stop trying. But as soon as the project turns into a disappointment in comparision with my initial ideas it get's hard to I stick to it and see it through. I don't see the point anymore and I just stop. That's why most projects end as just another folder on my harddrive that's never going to be opened again. Ever.
So I'm always looking for the thing that set's my next coding-project apart from all the other zillions of projects/games that's been done before. But the resources I have to spend are limited. So how realistic is it to do something groundbreaking all the time? Not very, but I still need the illusion of 'meaning' to find motivation, what can I do?
I prefer to work on games because the world is full of potential players. Players can be really passionate about the games they play. The feedback you get, or just the statistics, give you the feeling that you did something significant. Statistics tell me that the last game I completed as a hobby project in a couple hundred hours spare-time was played about a hundred thousand hours by players all over the world. So other's wasted a lot more time on my product then I did creating it. I'm not even sure that's a good thing (karma wise) but it feels like my deeds are having an impact. I'm also working on games as a day-job. Some browsergame we did has 3 million players and I can't even start guessing how many million hours (man-lives?) I have helped wasting with the 'entertainment' we produce. But when I was younger it was easier to feel proud about that. Now I'd rather cure cancer or build a house or something...
So, why do I always gravitate towards the next hobby gamedev project like a moth to the light? I guess because I (sometimes) enjoy it and I'm rather good at it (coding) and I still haven't lost hope to do something really great (by whatever definition) some day if I don't stop trying. But as soon as the project turns into a disappointment in comparision with my initial ideas it get's hard to I stick to it and see it through. I don't see the point anymore and I just stop. That's why most projects end as just another folder on my harddrive that's never going to be opened again. Ever.
Pages: [1] 2