Parallel Universes

Idea number three.

You have a basic avatar, and a room with several objects in it. One of them is a Universe Traversal Chamber. Entering the Chamber will transport you to a random parallel universe, where things change. Colours, shapes positions etc of objects will change, as well as the laws of physics (gravity most notably).

For this to be entertaining, there should be a wide variety of ways in which the environment can procedurally change.

Images and their Secrets

This is idea number two. The core idea involves reading in an image (possibly room for Google Images API) and then generating a few 'species' on the image which will feed off it's colour information. The image will lose saturation as it is eaten, and the species will evolve/adapt various traits based on the colours they have been devouring. When coming into contact with each other, they will fight, and the outcome of battle will be determined by their traits.

It suggests that images have a secret hidden world of activity going on behind the scenes.

Arms Race sketch

This just illustrates the basic loop of:

1. Losing side asks for help
2. Design them a weapon
3. Watch battle simulation
4. Get money if they win
5. Losing side asks for help

Pixel Guns

An idea of the presentation of the guns for Arms Race. Each pixel means something, like black for metal exterior, blue for power, greys for pistons/moving parts, orange for explosive charge, brown for projectile, etc. This is how the device is designed simultaneously in form and function.

Light Reading

I have some other ideas in the works, but they are all spin-offs of my original concept at this point. Here is some light reading I am going through for inspiration and general interest.

• http://en.wikipedia.org/wiki/Arms_race
• http://en.wikipedia.org/wiki/Evolutionary_arms_race
• http://en.wikipedia.org/wiki/Red_Queen%27s_Hypothesis
• http://en.wikipedia.org/wiki/Firearm_actions
• http://www.howstuffworks.com/machine-gun.htm

The idea of an evolutionary arms race particularly caught my eye, this would be a great spin-off point resulting in a fairly different outcome. 

Project 4: Arms Race

I've been kicking around the idea of a 2D game in which the player can design their own weapons. Through placing blocks of various materials in various configurations, the player effectively draws their 2D lo-fi gun while also defining its function. This is part of a wider series of experimental construction-based gameplay ideas I am getting increasingly excited about and would much rather work on.

So why not start investigating a portion of this within the framework of this course?

An interesting concept built itself in my head as I rode the train, about a scenario in which the player is an arms dealer. An evil arms dealer, profiting from a war between two sides, both of which are customers. One side will ask for a great weapon to slay their enemies with, and the player can design them a weapon. Then a simple simulation is displayed showing the two sides fighting, one using your weapon. The losing side will then come to you requesting a weapon that will defeat their enemies. This cycle repeats ad infinitum.

Just to highlight the ethical questionability, the player will earn cash each time their weapon brings victory.

There are quite a few things to consider to make this feasible in the timeframe:

• lo-fi graphics for everything
• bare minimum animation
• simple AI and setup for the war simulation
• simplify available pieces and functions for gun construction, while allowing for a reasonable amount of creativity in form and function
• physics for bullets should be very simple

This is idea 1 anyway.

Dress-ups

Two aesthetic modes I have settled on (in lieu of a lovely outline mode) are Industrial Iron and Modern Gloss.

These show that the language of machines has not changed as much as we might think since the industrial age, they are still parts within parts.

This will be my final result unless I can manage to get something like Gouraud shading implemented before hand-in. So happy with the results!

Parts are made of parts

The recursion is working! Boy did that take some time.

The hardest thing was getting the model to transform so that the selected object occupies the exact same space as it's container once did. This is necessary to facilitate the hand-over from mini-machina to master-machina, where all the transforms are reset but the machina is now drawn relative to the world rather than its master. I knew the transforms necessary to get the mini in it's place, so I thought I could just apply the reverse transformations to the master object and hey presto. But no. After much hair pulling, it turns out that the solution requires applying the reverse transformations in a different order. Some IF statements sorted that out.

Lerp() came to my aid in getting the transforms to ease out, which has a cool effect. It doesn't finish perfectly, but certainly does the job.

The transparency really completes the effect, fading out all the other pieces till there is only the new machina.

In my original design, the user would click on an mini-machina to travel to it and look inside it. Picking in 3D space seems doable, from the example I found here, but I decided to cut the feature due to time constraint. It isn't crucial to my project really, so it's just a 'nice to have', even though I was interested to try it. Instead, the mini-machina is picked randomly when you middle-click, and it only triggers if the object is exploded far enough (trying to minimise clipping and confusion).

A controlled explosion is a good explosion

Finally got around to sorting the explosion of parts along more axes than just X. Taking some angles of parts from Blender helped again, but I needed to sort out some vectors. In hindsight 3D vectors were what I needed, but since I had consciously made the parts on only two planes (xy and zy) I didn't really have to solve this, just do 2D vectors and swap the planes around when needed.

Luckily I had a handy vector function from my previous assignment that takes a point, angle and magnitude and gives you back the new point (this is super handy, why do PVectors not do this?). I think I'll write a version that can handle 3D also, then put it into a nifty Utils class or module that I can import into later projects.

The motion is not properly hierarchical, because the class structure stupidly is not either (man my class structure is overly simple) but I managed to cheat a bit for that too, since only a few parts really needed to act relatively.

Oh, and the direction-based mouse code I have been proud of and using for a while now has been superceded! Turns out the normalisation of the direction information (so that it's either 1 or -1 regardless of how far you actually travelled) was a dumb thing to do. Because of frame rate, the mouse moves further than 1 pixel per frame, so the values you are modifying (like rotation of the model) because proportional to the time spent moving the mouse, rather than how far you moved it. The end result is control that feels muddy and sluggish, since moving the mouse the same distance will not always yield the same outcome. I had written a bunch more code and introduced several global variables to get around this normalisation for my current project before I realised that simply taking it out fixes everything. Facepalm.

Offspring

I have added the ability for the model to generate smaller versions of itself inside its shell, at the predetermined points. My Blender model actually has all these mini versions in place, and I adapted the mini version object's position/rotation/scale data directly from Blender and it worked like a charm.

The interior parts are chosen at random, as are some other parts, to provide some variety between versions. Mostly it is swapping out a 'filled' spot (something installed) for a 'plugged' spot (something could go here but isn't installed, so there is a space filler) or simply an empty space.

The way I avoid infinite recursion while building these things is to only fill the interior with mini parts when the object is first exploded, which can only happen to the 'master' or top level object. There is a bit of trickery with the front slots, as they are visible even without exploding, so I have dummy objects in there that are replaced seamlessly (*ahem*) with actual mini parts when the object is exploded.

Mouse controls for rotating the model along two axes are now in, along with explode control. RMB and LMB drag respectively. Right now it works based on proximity of the mouse from the screen's centre, but this doesn't create intuitive behaviour since clicking and dragging in a new place causes the mode to snap to the appropriate orientation suddenly. It also requires much more precise mouse positioning. I want to improve it to a method I have used in the past, where the difference between mouseX and previousMouseX is used to determine mouse drag direction, and that is in turn used to modify the value. This means the position of the mouse is irrelevant, just the direction of its movement is important.

An NPR in the hand is worth two in the bush

This Non-Photo-realistic Renderer for Processing was developed as part of a Master's thesis by Katrin Lang. The results look spiffy! GLSL seems the way forward, but there simply is no time to learn it, at least for this project.

The two example programs given with the library are not encouraging. One does sort-of work but is really complex and has terrible performance (probably a high-poly mesh though), and the simpler one doesn't display properly. Even less encouraging is this line, next to the most recent available download:

May 30, 2009 | Fixed some issues that caused the library to use a ridiculous amount of RAM. Unfortunately, I seem to have introduced another bug that causes the library not to work on Windows.

Hmmm.

I've looked at his methods and could probably implement a Processing version of the wireframe contours method given enough time (and using the OBJLoader's interface to the model data). But alas. No time. 

Final model done

The final model pieces are done and I have them imported and exploding (on the x-axis only for a quick test). Looks super awesome! Not really close to the outline/blueprints aesthetic I really want, but still awesome to see it working.

OBJLoader working

I got hold of the OBJLoader library by Saito, Matt Ditton and Ekene Ijeoma and got it working!

Preliminary tests were positive, but I did pull my hair out over OBJ export settings for a while once I turned off the stroke and noticed that the triangles up top were messing up. Turns out that the best way to ensure compatibility is to triangulate your model at export, and also tell OBJLoader to read the model as triangles instead of quads or polygons. Which makes sense, really.

Using libraries with processing.py isn't too bad, the import syntax is just a little weirder (somehow there is no 'import something.thing.*') and you need to find the processing.py/libraries folder to chuck it in. Not sure where this folder is on the school Macs though, I did look once and got lost. Never fear, home PC to the rescue.

Note the gap up top where triangles should be...

Sketches

I have decided to go with the 3D option, but use Blender to pre-model pieces and intelligently arrange them in Processing. 3D geometry generation is a major thing to get to grips with, and there are many things even beyond basic meshes that I very much want to do, like bolts! How would you drill a nice hole in a mesh for a bolt? Doing my own boolean mesh operations seems a little outside scope. So, pre-modelled geometry it is. I remember something about OBJ importing support in Processing, so I must test that soon.

Here are my sketches so far.

Project 3 - The Beginning

Late into the project as it may be, I recently remembered a random idea I had a year or so ago that would be perfect for this project: procedurally generated machines. The scope of such an idea is pretty large, so here is how I narrowed it down to use the ideas of hierarchy:

• A 2D mechanical machine, made up of procedurally assembled moving parts like pistons and wheels. Clicking on a region would zoom in, and when a part became large enough it would be replaced by a collection of smaller parts that did the same job.

Advantages with this one include dynamic motion possibilities, 2D is fairly simple and everything can be made from scratch in Processing. Disadvantages are potentially flat composition colour-wise, difficulty of resolving motion, difficulty of preventing parts overlap and difficulty of zooming in/replacing/culling unnecessary parts.

• A 3D machine that does not move, but instead expands into an exploded view to reveal all its parts. Clicking on a part will zoom in on that part and erase the others, then that part can be exploded, and so on. Ideally 3D forms will be generated in Processing to suit.

Advantages include no need to solve motion issues, impressive interactivity available with 3D, awesomeness of exploded views. Disadvantages include severe difficulty in generating 3D geometry for the purposes I want.

I will need to investigate further to see if I can come up with any theoretical methods for approaching these problems, starting with sketching. I also need to explore the exact aesthetics qualities I am looking for.

My inspirations for machine aesthetics (and my love for exploded views) come most recently from the game Portal 2 and also from the Iron Man credits.

Portal 2

Iron Man credits

I would love to do some sort of edge detection shading just to cap off the blueprints feels. From studying the Iron Man credits further though, this is not a trivial thing to get right. They seem to be drawing edges where only one face is visible, rather than just getting an overall outline, so a simpler hack where a flat coloured version of a shape is drawn a bit larger and behind the real shape won't achieve this level of detail. I may have to look into GLSL or something...

HexDraw

Messing with making a little drawing app that lets you draw with hexagons.

Why is it so fun to make things that have no chance of becoming my final project? Never mind, I forgive myself since making awesome stuff is pretty much the meaning of life.