Rusky

I've posted a bug report on the bug tracker about this: 0002819: Box2D is not a good default. Because the bug tracker requires login and I think this topic would benefit from input from the community, I'll reproduce it here, as there's no "future GM versions" forum. It might work better in the GM 8.1 forum though... not sure.

To be clear, I am not opposed to adding Box2D. I merely want to avoid the use of its presence as an excuse to leave the current system alone. The current system, without a doubt, needs improvement, and Mike has already begun ignoring it in favor of Box2D. For example, in 0002686: bounce against certain objects, Mike dismissed a suggestion for improvement by saying "This kind of thing will be addressed when we add Box2D physics in the near future."

---

Integrating Box2D could be nice for a certain class of games, but those games are by no means in the majority. *Any* kind of physics simulator is the wrong default for collision detection and response in GameMaker.

Here's why integrating Box2D would be a mistake:

- Physics simulation is much more complicated to set up and use. Users have to work with number like mass, acceleration, restitution, etc. While this system is very powerful, it is by no means easy or intuitive, and by no means a good fit for most games' physics.

- Physics simulation is too specific to certain kinds of games. GM's current system of direction/speed/gravity/friction is simplistic and has its flaws (lack of information), but the concept *is* extremely useful for the vast majority of games.

- Physics simulation is much more cpu-intensive than a simpler, polygon-based collision *detection* system that gives the *user* enough information to respond intelligently (e.g. distance to/out of obstacle, collision normal vector).

Here's what would be better:

Instead of building in something like Box2D, GM should have a minimal, polygon/vector-based collision detection system that gives the user the most information it can. I would describe the current system as something like "move, and then if we're intersecting something, flail around until we're not." The code running in collision events doesn't know enough.

Using simple and cheap computations (which I'm sure you know of but are nevertheless difficult for a lot of GM's target audience), collision events could fire *before* moving the object into its new position as well as after "teleporting" into another object by directly setting x and/or y.

The collision event could then be provided with, alongside the current "other" object, the normal of the face [about to be] collided with, and the fraction of the current velocity that would move the object just up to "other" without intersecting it or the minimum translation vector to move the object out of "other."

These are my thoughts after developing a lot of custom collision systems in GM in order to work around its current flaws, as well as writing games using Box2D specifically. I hope you'll take them into consideration before adding a full-blown physics simulator to GameMaker.

This game was made for a 24-hour dystopian/monster-themed competition: Loony.

Screenshots:

abubalay.com

Abubalay.com is my personal hobby website, I'll be posting my games and tutorials there. It's got the handful of games I've actually finished and a few articles and tutorials on various subjects. I've also added some engines for people to use.

Latest addition: Rocket Sharks

First of all, I've left the projection to the default value, without even calling d3d_start. Then I'm drawing a textured sphere, rotating around the y axis. I've set a directional light, but it seems to be following the sphere instead of staying in place.

I set up the light with this code in a control object's create event:

d3d_set_lighting(true);
d3d_light_define_direction(0, 0.25, -0.25, -1, c_white);
d3d_light_enable(0, true);

And then I have the sphere being rotated with this code in the draw event (angle is updated every step):

d3d_transform_set_identity();

d3d_transform_add_rotation_y(angle);
d3d_transform_add_translation(x, y, depth);

d3d_model_draw(model, 0, 0, 0, texture);

d3d_transform_set_identity();

The lighting also seems to be affecting each object individually. Objects with different transformations have the light follow them individually. Any ideas?

I'm working on an engine for actor files. The basic idea is to load an actor file that defines all the parts and graphics for something in a game and then load an animation file that goes with the actor (so you can make more than one per actor) that defines how the parts move.

Anyway, the how the files work: I'm using ini files for now, hopefully a different format later. Here is a sample actor file:

[elements]
numelements=6
e1=lefthand
e2=leftfoot
e3=body
e4=head
e5=righthand
e6=rightfoot
[head]
x=0
y=0
sprite=spr_sploing_head
[body]
x=34
y=95
sprite=spr_sploing_body
[lefthand]
x=100
y=110
sprite=spr_sploing_hand
[righthand]
x=-18
y=110
sprite=spr_sploing_hand
[leftfoot]
x=90
y=190
sprite=spr_sploing_foot
[rightfoot]
x=20
y=190
sprite=spr_sploing_foot

The spr_sploing_head stuff is the name of a sprite in the game. Also, I'm probably going to get rid of the part name stuff and just use [e1], [e2], etc. But first I need to get this to work.

Now I need to figure out how to do the animation file. So far, I have:

[frames]
numframes=2
fps=30
actor=sploing
[lefthand]
f1x=0
f1y=0
f2x=10
f2y=10
etc.

It has the frames per second the animation is designed for (the game will probably speed up and slow down animations) and the filename (minus extension) of the actor file it's intended for. The game engine will take those coordinates and then tween between them. It seems like something is weird or missing... Any suggestions?

I'm using data structure grids to store the ini stuff in the game. Besides getting the file format worked out, I need to figure out how to structure the grid and how to draw the actors with their animations.

Here's the files so far: Download