http://scratch.mit.edu/projects/15945630/

I decided to develop my collision system into a game! I've set up 10 levels and a scoreboard to track who completed them all the fastest. The game runs pretty slow, but it's still playable on my laptop so it should be fine for most people.

I'll probably post a reply detailing the challenges of doing this among other things at a better time.

Okay, so all the levels in the game were designed in blender like so:

The ball always starts at (0, 0, 0) and has a radius of 1, so you can temporarily place a UV sphere of radius 1 there to get a reference of how big the ball will be (remember to delete this afterwards!). After designing the level you need to triangulate all of the faces, which you can do in edit mode by selecting them all (a key) and pressing Ctrl-T. This is because neither the collision system or renderer support quads, and quads actually wouldn't make any sense for collision.

The face count should be less than 50 for all levels. If it's over that the game goes crazy slow, and has the potential to break the game if at any point it goes under 1 fps (scratch limitation). The renderer on its own can manage around 100 tris at 10fps, however the collision system also has to iterate over all triangles and check collision on all of them so that limit is severely decreased. This could be solved in future by using a 3 dimentional octree to partition the collision model, but the improvement would be quite small compared to the work that would need to be put in.

The model is then exported to .obj format, which can be imported and read into the project via the OBJ list and OBJ converter script:



After you import it like this, you can play it as is… however there won't be any bumpers and the level will be completely black, which isn't very productive or fun to play…



For the colouring I made a simple script which iterates through the triangles and for each highlights it in white asks for a colour in 24-bit hexadecimal form, eg. #FF4000.



Of course, it would be incredibly hard to colour all the triangles while playing the game, so I implemented a special “view mode” which provides a static camera which blocks the game from running. I didn't flesh out this implementation very far, all camera values had to be changed in the code to change the camera angle to get hard to reach triangles. For the custom level system I'll probably implement a simple flying camera to let the user get a good view without changing values in “see inside” mode, which would break cloud variables and render them unable to save their level.

For the level editor, the colour input system could use a simplification too to allow users to choose from the colours the game uses without having to constantly copy them from a list (like i did). Of course, it would also let the user input their own colour for specific triangles if they really wanted a certain triangle to be purple.

The game detects if the player has won by checking if the colour of the last collided triangles are either #36D900 or #BFFF00, the light green colours. This means that it is perfectly possible to fly over a goal if you're not careful.

The bumpers were edited directly in their list, as I felt that writing an editor would take longer than doing it manually for the 4 levels that actually used them. The list was in the form (X1, Y1, Z1, X2, Y2, Z2, X3, Y3, Z3…) and allows any number of bumpers. The bumpers are very laggy however, so I wouldn't reccomend adding more than 5 to a level. For the level editor I'll add an easy to use interface to place them, as I can't think of a way to include their placement in the blender obj.

All of this requires that the game is set up to skip the menu and start on the same level every time, otherwise the level will be erased on the click of the green flag as it will attempt to load the real level stored in the levels list.

Level data is stored in the levels list as a | delimited list, eg:
1|2|3|4|5
8|1|4
6|6|6|7|8|8|5|9
I made a really simple script to store the current level in the levels arrays, and of course a less simple one to read them for use in the game. The level share will probably need a more complicated system to keep the levels all in one entry in a “cloud list” (aka lirex's number list system), probably a two dimensional array delimited by @ and | or something.

Truly amazing work! Your explanation is over my head, but I can understand well enough to see that it's impressive work. What is Blender?

Blender is a tool for editing and creating 3D models.

The explanation above is only for importing levels using the existing scripts I made, not for the drawing or collision steps. I might do a writeup on those later.

Just submitted an update which should improve the framerate a lot on slower machines. If there are any issues with it (falling through stuff etc, that shouldn't happen though), point them out in the comments!

:O I saw this earlier. It's a REALLY awesome idea!

MCAnimator3D wrote:

:O I saw this earlier. It's a REALLY awesome idea!

Thanks! How far did you get?

This is my first time seeing this thread. And although I don't quite understand much of anything that you did, it's obviously outstanding work. I am very happy that I included it in Scratch Games Weekly Vol. 1. It undoubtedly deserved it.

—————–