More robot progress

Development of the robot progressed pretty quickly once I got into it and after about a day or two I had the robot pretty much fully meshed and rigged.

screenie3

I tried to stay true to my original idea of having as many interesting joints as possible so that when he gets fully animated he appears as dynamic as possible. He does have quite a skeletal form which I’m not sure if I am quite happy with, I am considering bolting on some armour plates on areas like his shoulders and upper arms and legs to fill him out a bit, but that will probably be for project 3.

render4

After getting the mesh completed I started to add some colour for variety. I also mocked up a bit of an environment to add a sense of scale (those cubes in the background are intended to represent buildings).

render6

Next I moved on to making some of the other scenes for the performance. I wanted to have a scene where the audience sees the scene from the robot’s point of view, complete with a snazzy GUI. So I mocked something up in Photoshop.

gui

The central reticule would be set up in Quartz to follow the mouse pointer so that during the performance I could move it around. The other elements would be animated to add movement to the scene.

And then I made it in Quartz to test it out.

I’m working on polishing up things and creating a presentation for hand-in tomorrow.

Robot development

And more robot progress!

render2

The robot thus far

I’ve been working on making the model for the robot, so far I’ve only got one of the arms but it is rigged up and I’m liking the look.

An emphasis has been put on making hinges and pistons that look good when animated, this will hopefully give the robot an exciting dynamic look when he’s running around.

screenie1

render1

The plan for project 2+3

For projects 2 and 3, I plan to continue on in a similar vein to my project 1 by creating all of my content digitally; renders from Blender, and generative elements in Quartz.

Project 1 was let down by the static nature of the scene I created so I hope to fix this by creating a much more dynamic environment.

So, the plan is to create a robot character in Blender using a similar style to project 1, animate him and then create a series of scenes focusing on him.

Where to next?

Now that the 2 and 3D versions of the T-alley mazes are up and running I’ve started to spreadsheet players results in the hopes of uncovering some interesting trends and opening up the possibility of doing some nice infographics.

I’m contemplating creating a 4D version of the maze next by having walls that move over time, or by having some of the intersection decisions influence the rest of the maze. I am keeping the fact that we need to have a working game in a couple of months in the back of my mind, so I will try not to spend too much more time on these experiments.

3D trails

The trail for the 3D version of the maze is in on a basic level, once the player finishes the maze, the camera switches to a third person orbital camera so that the player can pan around the maze. The maze itself goes transparent so that the player can see the path they took.

Unfortunately, since the trail the player leaves is a 2D sprite, it doesn’t accurately show the directions the player was facing during the maze run and is therefore largely useless. We might have to create a new trail, but it might be better to simply move onto another experiment.

Picture 5

Success!

I’ve managed to get the timekeeping function on the maze working now so we can start testing players over multiple iterations to see if they get faster.

I also got my girlfriend to try out the working version of the 2D maze which brought on some interesting discoveries that I had not anticipated at all.

Her method for navigating the maze was unlike anything I had seen before, she refused the use the mouse and keyboard simultaneously which resulted in an interesting straight line pattern. The arcs that can be seen at the intersections clearly show when she has switched to using the mouse to look around corners.

Picture 6

She also brought up some other valid points which we have implemented, or will look into implementing into the maze. The mouselook sensitivity was far too high for her, and she preferred not to have Y-axis mouselook enabled.

Image0104

I wanted to have a picture of her up here for reference but she refused, so instead here’s a picture of Hannibal, my girlfriend’s Axolotl.

The new trail.

I’ve been working on the trail that the player leaves while navigating the maze to try and get something which looks a bit nicer and provides helpful and easy to read feedback.

This is it in it’s current iteration, the colours are a bit crazy but they show the functionality of it quite well – my tendency to strafe constantly is visible in the way that the red line (player position) is never in the centre of the green band (direction of rotation).

Picture 5

With a bit more tweaking I should have a version that is compatible with the 3D maze. The problem is that the nature of the 3D maze means that I need to hide he trail from the player and find a way of removing the maze geometry once the player finishes the maze… I might have to dig into the old White-Space code!

Oh and a timekeeping function is coming along too so we can get some races going!

Going crazy for mazes

As an extension of the T-Maze I made earlier, I decided to create a 3D version of it. This new maze operates on the same basis, at each intersection, the player is presented with a number of directions to go (2 in the last maze, 4 in this one) and can instantly see which of the directions is the correct one to choose because they can see the end of the corridor. Basically, this means that dead ends are not obscured by corners.

This maze has the same number of intersections as the previous one (14) but is much more challenging to navigate. I still need to add the trail so that the player can see the path they took.

We are investigating a different method of making trails so that we can get something that looks a bit nicer.

Picture 4

Progress report

I have been looking into literature about mazes and their applications in psychological testing (with rats and mice) to find information which would be useful in developing some tests that I can perform in a game design context.

I hoped that there would be a standardised maze that I could copy and recreate in Unity to base my experiments on, but I couldn’t really find any information on a standard maze. I have been speaking with an honours psychology student who says he will try to get some information for me regarding that.

I recreated a maze I found in some literature about lab rat tests. The layout is called a T-maze, for fairly obvious reasons.

I also set it up so that the player leaves a trail (although they cannot see it themselves until they have completed the maze) which shows the path they took and the direction they were facing.

This is helping to generate ideas about how people navigate mazes, the intention is to get a large sample of people to run the maze and compare their trails to find some common trends.

Picture 2

Picture 3

As can be seen from the second image above, running the maze generates some abstract, generative forms which provide information about how the maze was navigated (it also shows that I have become quite familiar with the maze, although I do make some errors near the end). Interestingly, observing my own trails has lead me to realise that I often move my character in a diagonal direction, and initiate my turns well before the corner itself – this reflects my background in playing FPS games.