I’ve made another website!
Some of the more interesting features of semblancesolutions.com are:
Normal
Mobile
MechJeff.com
My cousin Jeff needed a site to show off his cool craft creations, so I made him one! If you happen to need a skilled welder, and fabricator and mechanic to build anything you can imagine for your home or business, he’s the man to contact.
With the wonderful Voronoi implementation by Alan Shaw I’ve managed to get the destructible blocks in my game crumbling in an elegant manner. The initial shattering of the breakable blocks splits them into the convex Voronoi regions, subsequent breaks are less complicated.
go to demo
Demo Controls:
WASD=move direction .. SPACEBAR=shoot bullets .. T=tractor beam .. ESC=menu/pause
click-> ‘start new game’, then, click-> ‘load test area’
Other new features include keyframed animation of physical objects, a new wall-hugger enemy type(he’s still buggy), some sounds, exits and entrances, a new control scheme for low gravity maps that uses the mouse to control direction, and numerous other things.
With such a wonderfully destructible environment I hope to put to good use my crazy ray-casting-path-finding experiments. I’m sure there is some overlap with voronoi and path finding here as well.
I’ve made a simple slide show in flash to work with the pods plugin for wordpress. In principle, you can use the slide show in any situation, because it uses a ‘magic’ string to get the images, links etc it needs to load.
The compiled .swf is just under 4kB and uses a config_slideshow.txt file to get itself started.
The slideshow.swf looks for config_slideshow.txt in the same directory (as itself) and loads some configuration variables from it. (Don’t rename slideshow.swf or config_slideshow.txt.) The config_slideshow.txt will look like this:
The format for the magic string the slideshow will read is:
etc…
You can see the magic string uses carrots “^” and “#<br>” to break into usable data. The order of the elements in the magic strings is important, but you may leave an element blank if you like: “^^”
Here is an example with intentional missing images to show how errors are handled:
Here are the files:
Flash slideshow files and source
Still to do:
back/forward buttons. + configure in config_slideshow.txt file.
Fullscreen button. + on/off in config_slideshow.txt file.
Play music .mp3 or midi with the slideshow. +config_slideshow.txt file controlled.
With any luck, I’ll be able to put my pathfinding explorations to good use with this destructable 2D environment.
This screenshot really does not do justice to what is going on here. Polygons are breaking all over the place. Also, loot is dropping.
I made a simple wordpress site for a friend: floralsunshine.com
She was delighted with the way it came out, even though I was rushed into completing most of it in one day!
I’ve recently had some interesting dicussions with my friend John about the possibilities of Augmented reality + video projectors for live events. In addition to my recent research with SwisTrack and Blender3D I’ve jumped on the bandwagon with every other flash developer and tinkered with the FLART toolkit. I havn’t gotten much further than a working compile of the source with a few custom triggered events on my own patterns, but when I get around to cracking open Blender and get a few of my own models and textures exported to .as my I can probably motivate myself to do some more experiments with it.
Still very primative, but more progress has been made.
WASD, spacebar
P to attempt path solution
R casts a ray at the mouse and shows the first sidewalk.
The enemy will stop if it is to far offscreen. It helps if you resize the flash window to make it bigger.
To avoid needless backtracking and cut corners when possible, extra tests are now performed each time a way point is reached. These tests cast more rays at way points further down the list. The furthest way point touched without obstruction will become the next way point and the points in between discarded. Every second or third way point reached will probably need to trigger a completely new path finding solution, because of the time it takes to travel that far.
I’ve added a coefficient of average obstacle size that for now is just a variable, but might (eventually) be set automatically after a few solution attempts. The coefficient helps by hinting when the path should to turn off the ‘sidewalk’. In spaces with small obstacles, you’ll want to get off the sidewalk sooner and the coefficient will be smaller.
It turns out, that a sparse, empty space is ill suited to the ray casting approach, because it relies on bouncing rays off walls. Luckily, featureless spaces are simple in every other way, and often require no path finding whatsoever.
I’ll need to do some observation and tests to determine what order of left or right turns in a row is most likely to make progress towards the destination. I’d like to think that a lot of this can be done at runtime, but I need to be careful not to push this project towards the informed sort of pathfinding. I’m determined to keep the AI in the first person. It will have to learn it’s own space by casting ‘learning rays’. A lot of the tests I’ll need to make will be towards finding the important characteristics of obstacle filled spaces, and hopefully finding a few soft rules to follow.
It’s fun to program a solution with such unpredictable results. As I fly around and press P, I can see the rays cast, but if they were not shown, I’d anthropromophize the behavior of the pathfinding enemy. If the enemy was a bit faster and deadly to touch I think it’d be fun to try outsmart it.
Despite it’s being a gawd-awful mouthful to describe, I’ve attempted to heuristically develop a real time, semi-informed, pathfinding technique using the ray casting in the 2D glaze physics engine for Flash AS3. Pathfinding in games is usually accomplished with a waypoint network or navigation mesh, and a little algorithm called A*. These techniques work great, but I don’t want to bother with constructing nodes for my maps, and I wanted an excuse to mess around with the ray-casting built into glaze, so I approached the problem from, (ahem), a different angle.
The problem is how to get the enemy to the player while the player is moving and obstacles (possibly moving) are in the way.
I’ve gone pretty easy on myself for the requirements of this particular pathfinding problem. The path finding solution can be wrong if the enemy’s behavior will look unexpected, unpredictable and interesting. The path can fail entirely and it can be interpreted that the enemy does not see the player or cannot perceive how to reach it until conditions change. Learning the weaknesses of the pathfinding algorithm becomes part of the challenge of the game.
The first step in my path finder is a ray cast in the direction of the destination. I then use the line perpendicular to the normal of the first obstacle obstructing the ray. This line follows the obstacle like a sidewalk until it encounters another obstacle, where another 2 rays are cast. One ray along the next sidewalk, and the other in the direction of the destination. If the ray cast in the direction of the destination is obstructed, a waypoint is added. This process is repeated a few times until the destination ray is unobstructed or the algorithm gives up. The enemy then follows it’s waypoints to the destination, checking at each waypoint to make sure the player is not in line of sight.
Anyway, here is what a very rudimentary, and buggy start to a heuristic pathfinding algorithm using ray casting looks like:
Keyboard Controls:
Move = W, A, S, D
Shoot = SPACEBAR (if you kill the blue enemy you have to reload)
Press “P” to attempt to get Enemy Pathfinding solution…
Cast ray from ship to mouse = R
Amazingly, walking along the sidewalk and only taking right or left turns can sometimes get you in sight of your destination. More analysis is forthcoming.
To demonstrate my flash skills as well as showcase my other work, I’ve made jaketastic.com into a little operating system-ish application.
jaketastic.com user interface
On the left is the file browser. It can be used to explore all the files and subfolders in the jaketastic.com/browse/ directory. When you click an item in the file browser, it will begin loading in it’s own little feature rich window. You can move this window around, resize, minimize and close it. Tabs appear along the bottom for minimized items.
Because the file browser uses a php service to build the directory listings, content management is a snap. If I want to add an image, flash movie, .flv video, or html to the portfolio, I merely upload it to the browse directory and it instantly appears in the file browser. Furthermore, if I want to add a description to a file, I need only upload a .txt file with the same name to the same directory, and that .txt file will load in the window as well.
Jaketastic.com also allows you to chat with anyone else on the site in real time with the handy chat widget that I’ve made. Just type in a message and press enter and the message appears for everyone to see!
Jaketastic.com uses Amfphp 2.0 and a modified version Strike Remoting for server communications. For video playback, I’ve added a slider and fixed some bugs in FLVPlayerLite.
Bitwise Operations
For those of us without computer science degrees, a lot of the lower level guts of programming often remain a benign mystery until we encounter them in some code we need to borrow. In the Glaze physics engine, layers delegate which collisions will happen between the bodies in the physics simulation. The layer object is a unsigned integer expressed as hexadecemal: “0xffff” The function used to determine if Rigidbodies collide is a bitwise AND.
One needs to grasp hexadeciaml to binary conversion and bitwise operations to control all 32 layers of collisions. I immediately wrote a function to obfuscate these ugly bitwise things and assign a rigid body’s layer without suffering the unintuitive process of converting and comparing. I do appreciate that bitwise comparison is very appropriate for the collision layers, but it is very satisfying for me to spackle over it and never have to deal with it directly again.
Starting down the programming path by way of a flash designer, I have a rather mollycoddled perspective when it comes to coding. I am not very interested in making a compiler, or noodleing with memory management or lower level tinkering… not yet anyway.
