fversnel / poortjes Goto Github PK

Continuing the theme of object composition, being able to nest game objects into each other will be a very valuable tool. Nested (child) objects would move, rotate and scale along with the parent, and exist in the parent's local coordinate space. This implies the need for a transformation stack, where transforms can be pushed and popped so transformation logic can be expressed in local coordinate spaces. Luckily, processing already has this functionality built in:

applyMatrix()
popMatrix()
printMatrix()
pushMatrix()
resetMatrix()
rotate()
rotateX()
rotateY()
rotateZ()
scale()
shearX()
shearY()
translate()

(source: http://processing.org/reference/)

Hierarchical gameobject not only provide spatial organization, but also logical organization. A single gameobject with 20 components is a lot harder to comprehend and maintain than a gameobject with several child objects that each have several components on them. In this sense they work somewhat like layers in a graphics editing package.

It would be a good idea to get a comprehensive 2d/3d vector class to represent aspects such as scale, position, force, speed, etc. These are all inherently related physical concepts, and having each in a separate class will make it really hard to calculate with them. The concept of vectors was essentially invented to represent these things in the most elegant way possible.

Processing has a ready-made PVector class that could be used. It has most of the essential methods like addition and multiplication, and also the dot and cross products which will doubtlessly be needed for calculating things like reflections.

The position, rotation and scale components for each gameobject could be represented in a single transformation matrix, speeding up a lot of operations. Even disregarding matrix representation, if both scale and position are represented as vector quantities, it might be handy grouping them under a single moniker, along with rotation.

An somewhat extreme example is Unity's Transform component: http://unity3d.com/support/documentation/ScriptReference/Transform.html

While much more complex than needed for Poortjes, it does demonstrate some useful concepts and conveniences.

Propose a design for wall collision and make sure that:

• Collidables can never move through walls.
• Prevent them from moving through the wall without any other side-effects in their movement to allow for smooth gameplay.

Instead of implementing listener to listen to ActionEvent it is much nicer (and type-safe) to listen to specific events like CollisionEvent, Gametick etc.

Using large backbuffers causes performance issues. Use hardware accelerated graphics instead.

Hardware acceleration using standard Java Graphics 2D:
http://today.java.net/pub/a/today/2004/11/12/graphics2d.html

Hardware acceleration through Processing using OPENGL:
http://alex.seeholzer.de/?p=37
http://processing.org/reference/libraries/opengl/

Propose a design for Game Object animation.

Would be awesome :)

When rotating an object with a height that is bigger than its width (and vice versa) the scaling isn't applied on the rotated model but always on the initial rotation (0 radians) of the model, resulting in the objects height beign applied to its width.