Slick Forums
http://slick.ninjacave.com/forum/

New Features for Slick
http://slick.ninjacave.com/forum/viewtopic.php?f=11&t=2826
Page 1 of 1

Author:  wam3483 [ Thu Nov 25, 2010 8:18 am ]
Post subject:  New Features for Slick

Been a long while since I posted here, thought I'd swing by again :)

I've been following Kev's blog on 2D lighting, and and have implemented my own class for lighting. Its looking good, once I've debugged it a little I'll share.

While I was implementing lighting, I decided to tinker with flocking, so I also implemented a flocking system using something I wrote a while back in C# using the XNA library. Combining lighting and flocking gave me some eye candy of which I am very proud.
Check it out:

Image

Image

The sprites must pursue my cursor (which you cannot see.) Sprites also must avoid the red circles when within 100 pixels, while trying to keep an average of 50 pixels between one another. Lastly, each sprite isn't allowed to change its heading from time step to time step by more than 1 degree (this forces nice smooth turns.) There are 100 sprites and I don't know how many circles. Lets call it 75. The FPS is an easy 60.

I know many people know this, but for those who don't...

Flocking allows entities to move in relation to one another. When combined with A* pathfinding and obstacle avoidance, flocking can be used to create groups of enemies moving in swarm-like behaviors. The results are impressive. Its something 2D engines could really use imo. Flocking systems rival particle systems in their "awe" factor. (Flocking systems are close cousins to particle systems.)

My code runs on my "engine." Its a hybrid between Slick and GTGE (ie there's a Java2D fallback, more background management etc.) Its in its infancy, and buggier than either I'm sure. Because of this I want to review it before I post my code, maybe rewrite it just for Slick.

I also plan to implement an abstracted adversarial search system for Slick users interested in puzzle games. Flocking and adversarial search are the only things I've noticed 2D game engines never seem to have.

But anyway, Hi Slick community. Hopefully I'll be haunting your forums often.

Author:  kevglass [ Thu Nov 25, 2010 9:12 am ]
Post subject: 

Awesome stuff, nice to see you again :)

Kev

Author:  Tommy [ Thu Nov 25, 2010 9:51 am ]
Post subject: 

Hi wam3483,
your lighting looks great - a view into your code would be cool.

Also flocking would be great to have - however I'm not sure what objects flocking should work on. Many people already have their own Entity classes and don't use Sprites directly, so it would be nice if flocking works on some Interface class for example.

Do you have a simple explanation what could be done with an adversarial search system? I know it's AI related but what is it's purpose?

And yes, great to have you back in the forums!

Author:  Kova [ Thu Nov 25, 2010 11:08 am ]
Post subject: 

looks awesome!
I hope you did lots of new stuff for the lighting so we can continue to improve what we have now :)

also flocks look great.. boids right?
So far I've implemented separation and wander behavior as I only needed those so far, would be nice if someone implemented whole set from steering behaviors .. there's Java implementation at steeringbehaviors.de, but it's GPL :(

Author:  dime [ Thu Nov 25, 2010 1:03 pm ]
Post subject: 

looks awesome!

Author:  wam3483 [ Thu Nov 25, 2010 6:54 pm ]
Post subject: 

@Tommy
Adversarial search allows AI players to strategically determine a course of action by looking ahead in the game and considering all valid moves. There are many extensions to this definition of adversarial search. This search is only useful in games involving multiple competing entities.

Yeah, good point. I do try and use interfaces whenever possible. What a boid interface requires depends on the values to be measured. At minimum we need coordinates, and velocity as the bulk of rules depend on these two things.

I've got a Flock class that represents groups of boids, and their rules. Flocks update boid's values by the flock's rules, and telling each boid to update itself.

There is a FlockingRule interface whose purpose is to return a vector used to update a single boid. It also has get/set for weight. The normalized summation of all the rules in relation to each boid alters each boid's velocity.

The boid interface just has get/set for position and velocity, and an update method.

@Kova:

I don't know how much new stuff I did... I've got transparent squares overlaid the viewport, and "ambient" lighting, which is just the starting color of each square. The idea of ambient lighting's probably my biggest innovation.

I plan to share flocking within a week or so. I've implemented separation, cohesion, tend to location, and avoid location. I've also restrict the change in angle each update. Sort of a guiding triangle I guess? My flocking system's pretty solid; I've used the same basic logic in C# all semester. Course that really means nothing since I've rewritten the code, but I'm optimistic! :)

Author:  wam3483 [ Sat Nov 27, 2010 3:06 am ]
Post subject: 

Finished abstracting my flocking code.
Future improvements include:
    Use shape interface instead of circles for areas to flock to, or avoid.
    Steering algorithms.
    Match velocity rule.
    Match heading rule.
    Triangular field of view instead of a 360 degree view (more realistic but expensive, and hard to notice. Might not implement)
My lighting code needs a bigger rewrite as its not nearly as well designed.

Flocking system:
https://dl.dropbox.com/u/785846/wam3483%20Flocking.zip

Feel free to leave general comments or criticisms.

Author:  wam3483 [ Sat Dec 04, 2010 9:06 pm ]
Post subject: 

I've taken a video of my flocking code and light map in action:
http://www.youtube.com/watch?v=iry784xEsG4

Soon I'll post my lighting map code. Its shaping up a little better day by day.

Author:  dime [ Sun Dec 05, 2010 6:13 am ]
Post subject: 

wam3483 wrote:

Soon I'll post my lighting map code. Its shaping up a little better day by day.


How hard/feasible would it be to integrate that lighting code into the main slick library?

Author:  wam3483 [ Wed Dec 08, 2010 12:24 am ]
Post subject: 

Shouldn't be too much work. Right now my LightMap class relies on a package I've created for background management, but I should be able to disassociate it just with some copy/pasting.

Though I really feel the background package necessary I know some developers would probably disagree...

Author:  liamzebedee [ Sat Jan 14, 2012 12:46 am ]
Post subject:  Re: New Features for Slick

Could someone please post the source for lighting used in this example

Author:  IgoR [ Wed Jan 18, 2012 6:01 pm ]
Post subject:  Re: New Features for Slick

Yup, I'm interested in that also!

Author:  wam3483 [ Fri Jan 20, 2012 5:21 pm ]
Post subject:  Re: New Features for Slick

Hey guys, sorry it took so long to reply!

Since starting this topic I graduated and got a job. Hobby stuff took a backseat for a while :'(. Give me a week or so and I'll try and track the source down. Its probably pretty ugly code, but the basic ideas should be there. It'll give ya a place to start.

Author:  Mr. Kenkron [ Mon Jan 23, 2012 4:31 pm ]
Post subject:  Re: New Features for Slick

Quote:
I graduated and got a job

Congratulations!

Page 1 of 1 All times are UTC
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/