The sokoboom thread

[philh]

(At some point I'll reorganise the forums to make somewhere more suitable for this to go.)

In order to show off Sokoboom at the freshers' fair, it's going to need polish. This thread is about the work that needs to be done.

- Better level design. Some are good, some are just unfun.
- - A lot of the black hole levels seem to be unfun.
- We shouldn't make the player wait after completing an objective to make sure it's really complete. Solutions?
- - One option: use heuristics to guess whether an objective is stable.
- - Alternatively: fast-forward button.
- - Most complicated: test for stability by copying the physics object, fast-forwarding the new one a few seconds and seeing whether the objective is complete up until then.
- - - Will this be too slow? Physics is considerably faster than rendering, so it can probably be made workable.
- - - Alan, how easy/fast is it to copy the physics object?
- Sound would be a nice touch.
- So would the ability to vary the power of explosions.
- - Could be set either by scroll wheel or duration of click.
- Force from explosions currently transmits through objects. Might shielding introduce new mechanics for levels?

[Alan]

Making the player wait to see if the level is stable is not inherently wrong: most physics games I've played include this.

My opinion is that it's probably a UI issue as much as anything. Don't make the player have to click somewhere: if the level has been stable for x time then they've won. You also probably have x far too high at the moment.

- - Most complicated: test for stability by copying the physics object, fast-forwarding the new one a few seconds and seeing whether the objective is complete up until then.

- Force from explosions currently transmits through objects. Might shielding introduce new mechanics for levels?

Keep it simple!

- Sound would be a nice touch.

One of my new design principles is that there's pretty much no excuse for not having sound. It instantly makes a game 100x more complete.

- So would the ability to vary the power of explosions.
- - Could be set either by scroll wheel or duration of click.

You need to be very careful with this. Far too easy to come up with a system that's unintuitive.

[Robert Goss]

I think we definately have to change that if you have to wait for a while and the level is considered stable (Ie you have to wait) after that time you automatically win, the level shouldn't get considered unstable.

With the black holes I think we should still have some. Defiantely not have objectives of trying to drop things in them. And have them reduced in power.

One thing we need to do (It may now be in the repo) is to fix the explosion code so it isn't offset from where you click. And cap it off so you cant sent things too ridiculously fast. Also we could increase the fall off and cap it so it doesn't affect everything.

Sound really is a must.

Variable power explosion may be a good idea. But I could see it as adding some complexity and sokoboom does have the advantage of reasonably clean gameplay.

In terms of other things to add to it:

• Breakable objects?
• Explode on contact objects?
• Magnetic objects (Switchable?)

It depends on if you want to allow the player to do things that make it impossible to win (Though if this happens the level should automatically restart)

[someone]

I agree with the level ending not requiring youto click the button. Just having a variable timer for the target state depending the level. I can commit my level editor when I get back to my pc.
One thing I do find wrong with the explosion code is that if you click on the object, it uses the offset to the object centre and makes it go flying. Not really sure of the ideal solution but it does need fixing.

Shieldng from the explosions would be an interesting feature.

Also there is that bug where only one black hole works in a level.
The black holes are irritating when they affect everything in the level, they make everything unstable.

The level with the 3 stacked boxes can be failed - I think thats a good level, I think it should have a message saying 'failed' on the screen with press any key to restart. If something like a restart happens suddenly it can confusing. It can be done quite easily by having a goal state call fail if not fulfilled.
For some reason that stack of box still falls over on its own when I last compiled it.

I also think the scoring metric needs to be reviewed. What is better: fewer explosions or less time?
something we never really did decide on before so they are both just in there seperately.
Maybe there should be more emphasis on the scoring?

[philh]

Well, technically it should be possible to stack the boxes up again, if you're careful. I'm not sure if that should be considered a feature of that level or a bug, but I'm leaning towards feature - if the player is dedicated enough to do it, we might as well reward them. (It's easy to stack them against a wall, but moving them to where they need to be is hard. And I guess you need to stack them in the correct order as well...)

In general, a lot of puzzle games don't tell you when you've failed. I don't think it's necessary. Certainly don't automatically restart - they might want to practice a tricky bit or something.

The boxes are prone to moving when they shouldn't. I assume that's an issue with the physics engine, but possibly we could increase friction or something as a workaround?

There should maybe be a lower limit on the r² term of the force equation, but not too low. The player should be able to complete the shelf level in three clicks, and the swapping level in six, for example.

You might have difficulty commiting the level editor, because svn commit isn't working. I've emailed compsoc about it twice now (it's an apache thing that we don't have permissions to deal with) and haven't heard back from them - I guess the next stage is trying to find someone on IRC or something.

[philh]

Okay, svn commmt works again. So we can actually get to work on this.

[someone]

Just moved all my changes from the usb repository ive been using to go to the online repository.
Unfortunately I cant commit and I cant remember which file I need to edit to let me commit.

[Brodders]

Just moved all my changes from the usb repository ive been using to go to the online repository.
Unfortunately I cant commit and I cant remember which file I need to edit to let me commit.

Sorted - you should be able to commit now.

[someone]

Still cant commit. Either its still broken or I have the wrong details. Tried it with someone and Sam Gynn and it still failed.

Also I like the not having to press the button to end the level.

[philh]

There was a problem with the passwords. If you change it from your profile it should work again.

[philh]

Looking at the bomb code:

Code: Select all

      Vector2D offset = (*i)->getPosition() - Vector2D(x,y);
      float strength = power;
      float distSq = offset.lengthSquared();
      
      float scalar = strength / distSq;
      if(scalar > 1000.0f) scalar = 1000.0f; //cap scaar to something sane
   
      Vector2D force = (*i)->getMass() * ( offset * scalar );
      
      offset = Vector2D(0.5,-0.5) * 0.1f; //Randomize
      (*i)->applyImpulse(force, (*i)->getPosition() + offset);

Is this correct? The getMass() looks like it should make mass irrelevant when calculating bomb effects, which seems counterintuitive. Then offset * scalar means the resultant vector will have length proportional to 1/offset.length(), not 1/offset.lengthSquared(). And we don't use the falloff parameter at all. Was that intended for if we wanted force to be proportional to 1/r^x for arbitrary x?

Perhaps we should set a minimum value for distSq rather than a maximum for scalar?

[someone]

Finally managed to commit!
Have fun with the ridiculous amount of changes...
don't think ive broken anything.

[Alan]

Why is the bomb position randomised from the centre of the object?

Surely the bomb should go off near where the mouse is?

The getMass() looks like it should make mass irrelevant when calculating bomb effects, which seems counterintuitive.

Counterintuitive, but possibly more user-friendly. The reason it's there is probably because it was there in my example code, and it was in my code because it means you don't need to recalculate coefficients whenever you change something's size/density.

Then offset * scalar means the resultant vector will have length proportional to 1/offset.length(), not 1/offset.lengthSquared().

I seem to remember this being a conscious decision at the time, but I can't tell you what your thought process was.

[philh]

That's just applying the impulse a short distance away from the centre of the object to give it a small moment. It looks weird when things are flying through the air but not rotating. As it stands though, the rotation is barely noticeable, so perhaps we need a better mechanism for doing that? I don't think just making it more severe would work well. Also I like the idea of the game being deterministic.

I don't suppose the physics library has fluid dynamics? If not, there's probably a way to simulate rotation induced by drag, though I don't have any idea what.

Speaking of the physics library, we'll want to play a sound whenever there's a collision. Is there a callback for doing stuff like that?

[Alan]

That's just applying the impulse a short distance away from the centre of the object to give it a small moment. It looks weird when things are flying through the air but not rotating.

I know what it's doing, but you'd get the same effect by using the mouse position (except the rotation would be realistically calculated by, you know, physics).

Also I like the idea of the game being deterministic.

Determinism is never going to relevant in a game using the mouse.

I don't suppose the physics library has fluid dynamics?

Ha! No. But it's worth pointing out the fluid dynamics is a ridiculous solution to that problem.

Speaking of the physics library, we'll want to play a sound whenever there's a collision. Is there a callback for doing stuff like that?

Have a look at the CollisionListener class: you attach it to a body using body->add(listener). Be careful though: there will be a large number of resting contacts every frame. You probably want to look at the approachSpeed member of the contact object to determine whether to play a sound/how loud a sound to play.