Awesome article. And you used my logo

Whoa. Trippy.

Edit:

Yikes, my avatar is HUGE. This is going to take some getting used to.

The biggest, baddest supercomputer in the world would have trouble figuring that out. Even things like Darpa vehicles with AI pathfinding algorithms to avoid obstacles are still programmed with GPS coordinates and detailed map routes.

Computers are stupid. You need to tell them what to do. Basically, you need those nodes, or pre-mapped routes, or whatever. All game AI is a cheat. So just cheat.

Yeah you could do it by compositing convex polygons, but not a single concave polygon on its own. I don't think Ellipse in the physics engine uses vertices at all, I suspect it's a custom algorithm, since there are probably specific equations for perfectly round objects.

The reason is (not that I'm an expert) that it's much harder to write an efficient collision detection engine if you can't guarantee a convex polygon. I'm not sure the specifics why. I think it also applies to a dynamic shadows engine, but I'm not sure.

Perhaps what's needed is an algorithm to automagically convert complex polys to tris, the way 3D modelling programs do:

<img src="http://i28.tinypic.com/23lz403.png">

Programs like Max and Maya let you make crazy n-sided polygons, but blow the surface it's all converted to triangles.

If you can stick objects together you could do this...

<img src="http://img183.imageshack.us/img183/6965/ajnfkigtd3.png">

I've tried that already, with very poor results. The physics simulation gets hung up on the corners where objects overlap and causes unexpected behavior. Play around with it yourself, you'll see what I mean.

And even if it did work well, that's a rather inefficient way to build a simple object that really only needs ten lines. You've gone from ten vertices in one object to 32 vertices in eight objects.

The short answer is no, physics collisions won't be per pixel, because the collision engine in Newton is substantially different - it operates on convex polygons rather than bitmap masks.

No concave shapes at all? So if I wanted to make this, I wouldn't be able to?

<img src="http://i31.tinypic.com/ajnfki.png">

Also, just out of curiosity, how many vertices does the Ellipse mask have?

Sweet guinea pig of Winnipeg... nice update! Can't wait to try it out.

Thanks, Ashley!

I had the same collision problems with the 3D box object, so I turned collision off on the box and made a simple sprite object that was the same dimensions/position as the box and that now works properly. I guess you could do the same thing with physics objects as well?

No, the collision stuff is completely different for physics objects as it is for plain sprites. Yes, you can detect if a physics object is overlapping a per-pixel collision sprite, but it won't interact with it in a physics simulation.

I see a couple of problems with external event sheets. Internal event sheets in Construct are compiled before running (built into an .exe). If you were to have an external event sheet, either you'd be compiling it at runtime (which would be beside the point of having external event sheets in the first place, and would require a "Construct Lite" type of compiler to be embedded in your game), or you'd be loading it into memory and interpreting it on the fly (which could slow your game down drastically).

Personally I think all of this user-content stuff could be made easily with better support for .ini and .dat type files. If you made an editor for your game to save level info as a separate file, you could just release the editor with the game.

And if you wanted total modability for your game you could store your graphics as external files and AI sequences and such as .ini's.

With .ini type files that information just gets loaded into variables and run by the code already compiled in your exe. It would be way lighter and faster than interpreting Construct-like commands from an external event file.

I hate to be the naysayer, but it just seems like a lot of work for something that could be solved more simply and efficiently.

http://futurepinball.com/

That program looks kind of interesting but there are two things wrong with it:

1. I'd have to learn (and master) yet another dev environment, and one that is rather limited in scope. Plus if I knew Visual Basic (which it uses for game logic scripting) I'd probably just be coding my own games from scratch.

2. It doesn't build an .exe, which means only the niche Future Pinball users would be playing my game. I'd much rather be able to reach a wider audience, and casual players wouldn't be very willing to install a separate program just to run my table.

You couldn't get the gun blast to spew lighting information around it, or the ghosts to emit a faint green, eerie light? These additions feel only necessary.

Ash mentioned he had trouble getting multiple lights up and running. I'm sure he'll get it eventually.

I don't know if it's possible either, but I'd really like to see it. I've been wanting to make a pinball game for some time, which isn't feasible without smooth curves. Well, not a good-looking pinball game anyway.