Need Critique on Tutorial Series on Making Arkanoid-type Game.

[ivan]

Well done! Looks much cleaner and it's certainly a better direction than before.
In your case, I would go one step further and just load the states dynamically:

Code: Select all

local loaded = {}
local current_state = nil

function gamestates.set_state( state_name, ... )
   -- exit the old state
   gamestates.state_event( 'exit' )
   -- check if loaded
   current_state = loaded[state_name]
   if not current_state then
     -- load the new state
     current_state = require(state_name)
     gamestates.loaded[state_name] = current_state
     gamestates.state_event( 'load', ... )
   end
   -- enter new state
   gamestates.state_event( 'enter', ... )
end

Personally I like to restrict the direct access to the state tables (the gobal variables: "menu", "game", etc)
I think these could be "hidden" from the rest of the code - allowing accessing only through the use of API that we already have:
gamestates.set_state("menu", ...)
gamestates.state_event("draw", ...)
You could probably add more functionality if needed:
gamestates.get_previous() -- returning a string

This is just my personal opinion though, the code is fine as it is, so great work there!

[noway]

In your case, I would go one step further and just load the states dynamically:

Yeah, it seems, it would be a better way.
Apart from hiding the gamestates from the global scope, it would also allow to avoid an obscure discussion of module loading order and module predeclaration.
I'll probably try to implement it. Thanks.

[noway]

I've updated "Advanced Gamestates" part to use dynamic gamestates loading.
Apart from that, not much progress during the week.

[ivan]

Hi again!
Look good so far, I think the code is a lot tighter than before.
One thing I noticed and have struggled with myself - is the sharing of data between the different states.
In your case "ball,platform,bricks,walls,collisions" etc are all local data inside the "game" state,
this is totally fine - assuming that these object are not expected to persist once you leave the "game" state.
Another approach is to move these objects into another global, something like:

Code: Select all

simulation = {
  ball = require('ball.lua'),
  paddle = require('paddle.lua'),
  ...
  score = 0
}

Note that you can put other persistent data in that table like the score, etc.
Short-lived data can still be stored inside each state, but storing the persistent data
in another global can make life a whole lot easier.
Sometimes it's good to have a third global for the scene/rendering,
kinda like the Model/View/Controller approach.
The MVC philosophy defines how the different objects are allowed to interact with each other -
for example the 'simulation' (or 'model') objects shouldn't need to know about the gamestates
and preferably shouldn't know about how they are rendered.
For your tutorial it's not really a big deal, but you're on a good path already,
so well done!

[noway]

Another approach is to move these objects into another global, something like:
...

Yes, global variables sometimes can significantly simplify the code.
However, i think, in this case the number of game states and game objects is small enough, so globals are not really necessary.
Still, I agree that for more complicated games globals can be a much better choice (provided some discipline/systematic approach is maintained).

[noway]

It's been awhile since my last post here.
Some progress has been made on the project, though the pace has slowed down significantly.

I've updated the code of the third chapter to use the no-OOP style of the chapters 1 and 2 and replaced HC and hump.gamestates with the ad-hoc solutions described earlier in the tutorial. The parts have been rearranged into more logical sequence. The code mostly works, but has some bugs that I hope to correct while writing the explanations. The drafts are available on the github wiki. The first 3 parts are mostly finished.
1. Better Ball Rebounds
2. Ball Launch From Platform (Two Objects Moving Together)
3. Mouse Controls

I've some doubts about the ball-platform rebound algorithm I use.
There are two choices that I have tried.
The first one is to bind the ball direction after the collision to the distance between the centers of the platform and the ball, i.e. something like:

Code: Select all

ball_rebound_angle = (ball_center.x - platform_center.x) / platform.half_width * max_rebound_angle
ball.speed = ball.speed:len() * vector(  math.sin( ball_rebound_angle ), math.cos( ball_rebound_angle ) ) 

Probably, it is the simplest possible variant, but for me it feels a bit awkward.

The second option is to rotate the ball speed on some angle depending on the distance between the ball and platform centers.

Code: Select all

ball_rotation_angle = (ball_center.x - platform_center.x) / platform.half_width * max_rotation_angle
ball.speed:rotate_inplace( ball_rotation_angle )

.
I use that variant, even though sometimes it is hard to predict the ball direction.

I have a feeling that both variants are a bit unnatural and can be improved.
So, what is the canonical ball-platform rebound algorithm?

[ivan]

Hello again, looks good so far, the first version is clearer.
That's how Breakout plays more or less, of course neither option is considered "realistic" in terms of the physics simulation.
You see, with physics the velocity and mass of both bodies determine the collision response plus coefficients like friction and restitution could also play a role.
There really isn't a "canonical algorithm" it's about how deep your physics simulation needs to be.
For example, Box2D assumes you're dealing with rigid bodies (no deformation) and handles collisions in pairs,
where an impulse is applied to each pair of colliding bodies.
What I'm saying is, Box2D makes vast simplifications too and is still quite suitable for games.
I think the first technique is fine for something like Breakout.

[airstruck]

Most ball and paddle games seem to treat collisions as if the paddle were shaped like the top part of a circle, sort of the shape of a taco shell from the side. If the ball hits the left part of the paddle traveling southeast, it might get reflected back toward the northwest; if it hits far over on the right part it might end up going almost due east, and if it hits the middle the y-velocity would be inverted and it would travel northeast. In some games the paddle has a curved appearance to reflect that behavior.

If you want accurate physics, you could do circle-circle collision and have the paddle actually be part of a large circle that's mostly off the bottom of the screen. Probably overkill for a tutorial, though. Can just as well tweak it until it feels right and go with that.

[noway]

That's how Breakout plays more or less, of course neither option is considered "realistic" in terms of the physics simulation. ...
There really isn't a "canonical algorithm"...

I don't think there is any need in accurate realistic physics in the current version of the game.
Still, for me, both methods I've described result in rebounds that are hard to control.
The direction of the ball after a collision is usually different from the one I would expect, and that makes them feel unnatural and awkward
I don't remember any such feeling from a couple of other arkanoids I've played, and it was much easier to control the direction of the ball precisely.

Most ball and paddle games seem to treat collisions as if the paddle were shaped like the top part of a circle, ...

Indeed, that might work better. I'll test that idea. Thanks.

[noway]

Most ball and paddle games seem to treat collisions as if the paddle were shaped like the top part of a circle,

I've changed the platform-ball collision code to imitate a rebound from a spherical surface. I think, that has helped. Thanks, airstruck.