 |
Slick Forums
Discuss the Slick 2D Library
|
| View previous topic :: View next topic |
| Author |
Message |
Jon
Oldbie
Joined: 28 Nov 2006
Posts: 428
|
 Posted: Wed Mar 14, 2007 10:41 pm Post subject: SlickSet - v0.4 Final |
 |
|
What is SlickSet?
SlickSet is an physics-based game engine that integrates Slick and Phys2D (Box2D Lite).
Design Philosophy
1) Simple. The API is simple to understand and use.
2) Quick. Don't waste time integrating Slick and Phys2D. Use SlickSet and save yourself days of effort.
3) Small. At 120 KB in size, SlickSet is a small library that won't add much bulk to your overall game.
What does it do?
SlickSet provides the following features.
Actors, which are Game Objects.
ActorGroups, managed lists of Actors
A Scene that represents the whole playing field. Performs collision detection, rendering and updating for you.
Group-based collision detection through a CollisionManager. Just pass in two ActorGroups and a broad-phase CollisionStrategy.
Parallax scrolling and background images using Layers.
Integrated physics system (Phys2D)
Generic Effects system that allows you to attach reusable snippets of logic to Actors, Layers and Scenes.
Download
http://slickset.stencyl.com/
Discussion Forums
http://forums.stencyl.com/forumdisplay.php?fid=74
Current Status
SlickSet is no longer actively developed, but it is functionally complete.
Last edited by Jon on Mon Aug 25, 2008 10:03 pm; edited 152 times in total |
|
| Back to top |
|
 |
kevglass
Site Admin
Joined: 01 Jan 1970
Posts: 2851
|
| Posted: Wed Mar 14, 2007 10:57 pm Post subject: |
|
|
Moved it here since it's not a Bug, Idea or RFE that we need to act on.
Um.. comments...
- The name is never going to get typed correctly  I can see where you were coming from but I'm not sure it's great.
- The package org.newdawn.slickx is a neat idea, but I'm not sure it makes sense to tag stuff as org.newdawn since you're the guy that'll be creating it.
- I'd collapse the collision packages into one. Believe it or not, when a new developer looks at javadoc, more packages = more fear.
Kev |
|
| Back to top |
|
|
Tommy
Oldbie
Joined: 12 Nov 2006
Posts: 327
Location: Elmshorn, Germany
|
| Posted: Thu Mar 15, 2007 10:26 am Post subject: |
|
|
Eliwood, that sounds very promising 
Comments:
- Can single Actors also be used in CollisionManagers? You only mention ActorGroups?!
- I miss a CollisionCircle or CollisionEllipse.
- Which kind of layer is used for actors? Or can actors be placed on every layer, no matter what kind of layer?
- For collision: My WIP also has a collision manager who takes pairs of CollisionGroups (ActorGroup in your naming). What I haven't dealt with yet but would love to mention to you is the following: you might be able to optimize code if you have one ActorGroup several times involved. Example: Spaceship<->Asteroid, Spaceship<->Bullet, Spaceship<->Starbase, Spaceship<->Planet. Instead of traversing all ActorGroup pairs one by one you might be able to traverse the Spaceship ActorGroup only once and test against all the ActorGroups one after another...
- The name: I agree with Kev and think that cineslick does not properly describe what the extension gives you. What about something with Action like SlickAction? Or some silly abbreviation like Gosh (Game Objects Slick Hasn't) or Ego (Easy game objects)?
Anyway, I'm looking forward to see this baby come alive
_________________
Tommy's Homepage
Play SpiderTrap |
|
| Back to top |
|
|
orelero
Oldbie
Joined: 18 Nov 2006
Posts: 254
Location: Helsinki
|
| Posted: Thu Mar 15, 2007 12:15 pm Post subject: |
|
|
| CinéSlick hahaha, t'es français ? |
|
| Back to top |
|
|
davedes
Oldbie
Joined: 27 Jan 2007
Posts: 400
|
| Posted: Thu Mar 15, 2007 6:00 pm Post subject: |
|
|
| orelero wrote: | | CinéSlick hahaha |
Ehh ca veux dire quoi?? C'est "Movie Slick" en anglais.
When I first saw it I thought it had to do with movie playback in Slick. 
Just try and think of something simple that could be shortened easily, for example:
SlickSet
Slick Game Set
SlickDirect(or)
SlickGrip
SBOX - Slick Game Box
SGL - Slick Game Library
etc.
Sounds great though.  Can't wait to try it out. |
|
| Back to top |
|
|
Jon
Oldbie
Joined: 28 Nov 2006
Posts: 428
|
| Posted: Thu Mar 15, 2007 7:21 pm Post subject: |
|
|
| Quote: | | - Can single Actors also be used in CollisionManagers? You only mention ActorGroups?! |
It only takes ActorGroups, but it wouldn't be a bad idea to make a utility function that takes a single Actor and auto wraps that Actor in an ActorGroup behind the scenes.
| Quote: | | - I miss a CollisionCircle or CollisionEllipse. |
Easy to add in. In that case, I would just use CollisionEllipse since a Circle is a special case of Ellipse.
| Quote: | | - Which kind of layer is used for actors? Or can actors be placed on every layer, no matter what kind of layer? |
With the exception of the ParallaxLayer, you may add actors to any layer. However it is advised that you add all actors to the same layer (there are exceptions though!).
For ParallaxLayer, you need to add actors to some normal layer and then add that layer to the ParallaxLayer.
| Quote: | - For collision: My WIP also has a collision manager who takes pairs of CollisionGroups (ActorGroup in your naming). What I haven't dealt with yet but would love to mention to you is the following: you might be able to optimize code if you have one ActorGroup several times involved. Example: Spaceship<->Asteroid, Spaceship<->Bullet, Spaceship<->Starbase, Spaceship<->Planet. Instead of traversing all ActorGroup pairs one by one you might be able to traverse the Spaceship ActorGroup only once and test against all the ActorGroups one after another...
|
Sounds like an interesting optimization to do. I'll think about this one.
One way I can think about tackling this is to make a CompositeActorGroup so that you can compose several ActorGroups into one and treat that as a single ActorGroup. So instead of registering SpaceShip and each group individually, you compose all those groups into 1 and pass that in instead.
So for example,
| Code: | CompositeActorGroup composite = new CompositeActorGroup();
composite.addGroup(asteroids);
composite.addGroup(bullet);
composite.addGroup(planet);
CollisionManager cd = new CollisionManager(spaceship, composite, new QuadTreeCollisionStrategy());
|
Effects
One major thing I haven't mentioned yet is one of the ideas you had for GTGE which got rejected, which is the ability to add "Effects" (could be anything from particle effects to other kinds of effects like fog, rain, etc.) to Actors, Layers or even the Scene itself. How would you like to work that in? Here is what I have in mind based on your post a long time ago. This general idea came from Ultratron I believe.
class Effect
- Subclasses for Effect that implement each kind of effect. These have update, render in them. It's pretty much up to the individual game developer to implement these though I *may* provide commonly used ones.
- Effects can either go behind or in front of the "thing" they are attached to.
- You may attach as many effects as you'd like to "things" both behind or in front of.
- When you update the "thing," the effects are also updated along with it. Same goes for rendering. Basically, just attach it and forget about it.
- Effects can reach a finished state, at which point they remove themselves. For example, lots of effects would be short-lived such as explosions, and what's common is for an effect to end after its animation was played through once. This is what this is for.
Now, when I say "thing", we need some way of letting effects get attached not only to Actors but to Layers and the Scene itself and the only way I can think of is to use a common interface or Abstract Class (SlickObject?) for all.
------------------------------------
Now about the name, I'm mulling over alternatives. SlickSet sounds pretty good to me and its second meaning (as in a movie set) still encapsulates the idea without sounding misleading. |
|
| Back to top |
|
|
Tommy
Oldbie
Joined: 12 Nov 2006
Posts: 327
Location: Elmshorn, Germany
|
| Posted: Fri Mar 16, 2007 2:36 pm Post subject: |
|
|
Eliwood,
the CompositeActorGroup is a cool idea - but still ActorGroups could end up in several CompositeActorGroups at the same time. But that's for later optimization I guess
SlickSet is a good name. It sounds nice if you speak it - that's a plus!
One question about tile collision: How do you want to implement that? Do you base the TileLayer on the TiledMap class or something different? How do you plan to deal with tile collisions? What about special tiles like ones that are passable through from below and unpassable from the top (used many times in Jump and run games)?
And now for the effects:
My idea was partly based on Ultratron (as princec used Effects that could be attached to his game objects) and partly on SpriteCandy which is a game lib for Blitz 3D.
Look through the pages there and read the effect descriptions (Animations & Effects). There you can also attach effects to sprites, texts, shapes, buttons, layers and the HUDs (or scenes). What I liked about the SpriteCandy effects is that those effects can also be movements (back and forth, wobble, follow another object), transformations (rotation, scaling), color stuff (alpha and color fading) and on and on.
Have a look at his Blasteroids Delta demo game - it just rocks! The source code is also available (main parts) to look how certain game effects are achieved. It's pretty cool
I agree with the Interface or Abstract class SlickObject to be able to add effects to any SlickSet object. It's also required to allow an effect to manipulate it's "parent" object's instance vars (for example to change it's scale or position or rotation or color or....).
Cheers,
Tommy
_________________
Tommy's Homepage
Play SpiderTrap |
|
| Back to top |
|
|
Jon
Oldbie
Joined: 28 Nov 2006
Posts: 428
|
| Posted: Sat Mar 17, 2007 6:27 am Post subject: |
|
|
| Tommy wrote: | | One question about tile collision: How do you want to implement that? Do you base the TileLayer on the TiledMap class or something different? How do you plan to deal with tile collisions? |
TileLayer will be a utility class like it is in GTGE which will handle its own initialization, rendering and update. It will not contain any facilities at all to load in maps and it won't tie to TiledMap.
About collisions, the way I would efficiently handle collisions is for me to define a special TileMapCollisionStrategy that is optimized for tile map collision checking (i.e. only check the tiles in the immediate vicinity of each Actor). I don't believe that QuadTree would be efficient enough for this in say, a side-scroller, hence the need to specify another strategy.
| Code: |
//Assume that there is a tileMap of type TileLayer
//Assume that there is a tiles of type ActorGroup
CompositeActorGroup allActors = new CompositeActorGroup();
allActors.addGroup(player);
allActors.addGroup(baddies);
CollisionManager tileCollisions = new CollisionManager(allActors, tiles, new TileMapCollisionStrategy(tileMap));
|
tileMap is passed in because the strategy could get easier access to the tile map.
| Tommy wrote: | | What about special tiles like ones that are passable through from below and unpassable from the top (used many times in Jump and run games)? |
CollisionInfo (passed into handleCollision(), a method in Actor) will tell you what side(s) that Actor got collided on, what the other entity involved was, where you can revert to, so you can poll for the side and act accordingly. So for pass from below tiles, you see if it's that kind of tile, then if it is and you collided from top, treat it as a collision, otherwise ignore it.
One way, if you really want to keep things generic, is like this:
| Code: |
public void handleCollision(CollisionInfo col)
{
Actor tile = col.getOtherActor(this);
if(col.collidedFromBottom() && !tile.allowFromBottom())
{
setY(col.revertY());
}
if(col.collidedFromTop() && !tile.allowFromTop())
{
setY(col.revertY());
}
}
|
Not a shining example, but that's the idea. I might even put this in as the standard handling in the Actor class, and then you can just call super to get this basic stuff.
| Tommy wrote: | Eliwood,
the CompositeActorGroup is a cool idea - but still ActorGroups could end up in several CompositeActorGroups at the same time. But that's for later optimization I guess |
A messy but easy optimization would be to maintain a LookupTable each frame and to cache collisions between two entities. Then you'd always consult the table rather than recalculating. You probably wouldn't want to report the same collision multiple times either. |
|
| Back to top |
|
|
Jon
Oldbie
Joined: 28 Nov 2006
Posts: 428
|
| Posted: Mon Mar 19, 2007 8:06 am Post subject: |
|
|
A few people have been asking me about progress on this. I've been working on a Javadoc to show the detailed architecture of all of this.
I don't have an estimate on when it will be up. Remember that I still have Stencyl to tend to (on top of school), so I have a full plate. |
|
| Back to top |
|
|
Dantarion
Joined: 11 Feb 2007
Posts: 92
|
| Posted: Sun Mar 25, 2007 9:18 pm Post subject: |
|
|
Eliwood, I was looking at your ideas an entity management, and they seem a lot more thought out than mine. Do you think it would be hard to write classes that would enable the use of phys2d in games using slickset?
If so, I just might abandon my project, since the only parts of it I like to work on are the physics parts |
|
| Back to top |
|
|
Jon
Oldbie
Joined: 28 Nov 2006
Posts: 428
|
| Posted: Wed Mar 28, 2007 11:12 pm Post subject: |
|
|
I did a preliminary draft of adding collision groups to Phys2D. At first, performance was terrible (laggy and 40 FPS) with a 135 box setup and just one moving box that got pushed into a corner, but then when I turned off the rectangle drawing, performance leaped up to a nice 900 FPS when using an alternate loop scheme that broke free of the 60 FPS.
I'll investigate with images and a normal setup before coming to conclusions about feasibility, but it appears that whatever was happening with the draw routines was dragging things down terribly.
Edit: Turning all drawing back on but shutting off contact drawing jumped the framerate up to 100 FPS. Strange... |
|
| Back to top |
|
|
Dantarion
Joined: 11 Feb 2007
Posts: 92
|
| Posted: Thu Mar 29, 2007 9:12 am Post subject: |
|
|
I would have to see your demo in order to help, but I was able to get about 100 STACKING boxes with 30fps, so 135 static ones and one moving one shouldn't run at 40 fps..
I am really interested in helping with phys2d stuff though |
|
| Back to top |
|
|
Jon
Oldbie
Joined: 28 Nov 2006
Posts: 428
|
| Posted: Thu Mar 29, 2007 8:00 pm Post subject: |
|
|
[Removed]
Last edited by Jon on Sun Apr 29, 2007 7:14 am; edited 1 time in total |
|
| Back to top |
|
|
davedes
Oldbie
Joined: 27 Jan 2007
Posts: 400
|
| Posted: Thu Mar 29, 2007 8:57 pm Post subject: |
|
|
| Hmm i don't really get it.. is it supposed to be zero-gravity? The box floats around as if it were in space. |
|
| Back to top |
|
|
Dantarion
Joined: 11 Feb 2007
Posts: 92
|
| Posted: Thu Mar 29, 2007 9:52 pm Post subject: |
|
|
Eliwood, please dont say you have been judging phys2d performance by making tests based on the phys2d tests?
The thing slowing it down is java2d i think.. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
