Slick Forums

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:





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.

_________________
Breakout is a stupid game - XKCD

Awesome stuff, nice to see you again

Kev

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!

_________________
|
| |

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 .. there's Java implementation at , but it's GPL

looks awesome!

@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!

_________________
Breakout is a stupid game - XKCD

_________________
Breakout is a stupid game - XKCD

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.

_________________
Breakout is a stupid game - XKCD

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

_________________
Breakout is a stupid game - XKCD

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

Yup, I'm interested in that also!

_________________
"The Keeper is aware. The Keeper understands. The Keeper has seen the enemy."

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.

_________________
Breakout is a stupid game - XKCD

_________________
"Artificial intelligence will never be a match for human stupidity" - "Jamos Kennedynos"