Worklog

So I have made some incremental progress, in between all the ignoring this project I've been busy with.

Where were we last? I confess I have no idea, as I am typing this offline for later pasting up. Note to self: go to the pub, alone, with a laptop and no internet connection - you'll get hella shit done.

So recently I have made a proper helmet for all my electronics junk to fit within. I spraypainted the visor black (though it's coming off worryingly easily when it gets scraped), I put headphones in the ear protectors ( although they're a little too nice for such a role, and the left is in the right, and vice versa. thus leading to this), and I put all the wiring duct taped to the top inside of the helmet. I taped the vibration motors in place, and - voila - a lack of sensation on the sides. Evidently my head is the wrong shape. After much fannying, I gave up and went home.

Many days later, I returned, and did the obvious thing - push the motors out with padding. This also helps cushion the helmet itself from the vibrations, which is a good thing. Still, you can hear more than feel the motors. I don't really have a solution, but it's a pain. Not Ideal. The helmet is also a little uncomfortable after a while, but no more so than some uncomfortable earphones. Ergonomics matters, kids! Still, it's functional, and can now be offered to people without fear and worry on their part. (It's still outlandish, don't worry - but it doesn't look like it'll electrocute you anymore.)

To make the helmet more diegetic (fuck, that Nordic Larp book is worming into my brain), I need to spreaypaint it like a knight's helmet. KNIGHTMARE, indeed (never saw that as a kid, but that's what people say to me). Silver spray should do it? 

Anyway, platform is nearing final shape, and is at least good enough to go on with. I'ma offer it out as a gaming platform for people at the jam - be nice to see if someone can think of something cool for it. Cooler, and quicker than this long-ass project. :<

Software side, software side, I made some lovely progress last night. Testing at the hackspace produced a cry of "I don't know what the fuck is happening", and while I can reliably get to the other end, I must admit to being lost, pulling on a thread doing it. Takes too much commitment to a dull bad place to get through - no reward. Too little feedback does not a joyful experience make. This could be maybe transformed with lore, and I'll make that do some heavy work, but lore is not a place I am experienced with, so I will slap on everything else I can to make this stupid concept* work. 

To that end, last night I pimped up the sound most splendidly. The issue people were having was a lack of a sense of location. Sure, there's the siren giving you one thread to follow, but that's not enough to position you, just to drag you through. So I have added a deep roar at the entrance, a hidden source of wind deeper in, and ever so many drips and echoey areas to navigate through. As well, I've been further simplifying the level down, it's harder to get lost, and there's fewer obstacles to avoid. Possibly too far, but everything is easy enough to drag around to modify if it comes to that. And "too accessible" isn't a problem I currently suffer from.

I've also just now reworked my trigger-using scripts, and they appear a little more comprehensible this time. I did just rewrite this code out of laziness and disgust at the thought of understanding the stuff I wrote before, but I think it counts as a win. The Gorgons now no longer use UnitySteer, they just naively march towards you. But that's basically all I had got them doing before, and they're a lot more comprehensible now, so again, an uneasy win. They also only start chasing you once you stumble into their trigger area. With a sufficiently light density, you shouldn't end up with too many chasing you. I'm hesitant to develop the Gorgons too much until I'm happy navigation is possible.

What next? Work on the whole "make it more comprehensible". Polish and feedback. Working out a script to play at the start, and at the end - to make the plot comprehensible. Adding footsteps - the biggest necessity for making movement comprehensible. Once you can move and feel okay, once the game is boring, then we can add some shit to shoot! And then make that shit comprehensible. After that? Die of old age, I guess.

(*what concept? just "an FPS type game you can play with your eyes shut" or with tactile/audio only feedback, I guess.)

========================

I want to make this a comprehensible game. I know a few developers (*cough* increpare) who are happy making interesting, incomprehensible pieces. That's cool, the struggle for meaning is something I get off on. And maybe there's the old effect where game makers make games too hard due to their own practice - Increpare perhaps makes the meaning too inaccessible, because he knows it. Partly, I like games that everyone can play - I don't want to appeal to a niche. And also - this is an experiemnt in one direction, and not one I am confident of. If I have to mix my medicine with sugar to make it go down, then I'll make the sugar as sweet as possible. I wish I made more things, so each could be flimsier.


20 January 2011

Work Log

At some point in the week, I killed the maze I was happily getting stuck in. There's a lesson here about saving your work. But it's okay, I wasn't going to use it.

So - I have a featureless plain. You can wander with WASD and turn with the mouse (no looking up or down, I've decided). There are many cylinders, and a couple of cubes ( cylinders are better than cubes, I've decided, as the edges aren't as sharp. Sharp edges are hard to interpret.). One of the cubes plays "The Hangover Song" from Midsummer (a play with songs)*. If you have to listen to something repeatedly, it ought to be pleasurable in and of itself. You can wander this desolate videogame plain and try to find the musical cube, if you like. You can try to avoid the cylinders (though you'll eventually slide past if you walk into them long enough - another advantage). There's no failure and no success programmed in, but it's still a weird and engaging experience.

(Game idea : game set on a a featureless videogame plain. No idea what the gameplay would be. Maybe a distant, hard to spot hole to which you could plunge to your death. It's important this game has cool weapons.)

I set up the ability to pulse all the motors independently of the obstacles. This even works off an AnimationCurve so it is a sweet-fancy pulse. Next is to set the conversion between distance and intensity to use one (and - totes not an issue, but - don't repeat commands if they haven't changed). Tuning this I'm not quite sure how to do, but I'm sure hard work and guesswork will provide.

I've also made some decisions about the game. In it, you save a singing maiden, besieged by Gorgons. You can slay the Gorgons (with a bow and arrow?), they can kill you with their touch. You can hear them and sense them. You have to navigate through the maze and out again.

So : enemies, maiden, slaying and dying. And the game feeling vaugely okay.

* Gordon McIntyre, if you're reading this, triggered by an errant Google Alert, hello. You're a lovely man, and your songs often seem to express my own inner life better than I can. Anyone else - I recommend the play, Ballboy, him.


(The Hangover Song)


09 November 2010

Work Log

Once again, a worklog from the nightbus home from the Hackspace.

Lots of progress today, far too much for the little work I put in. Reducing the timeout on the reads from 500 ms to 10 ms has made the whole thing more responsive - still takes a few seconds to start up, but it only hung once in a day of hacking. The problems I was facing controlling the analog PWM stuff was due to having the wrong software on the Arduino - stupid stuff, but thrilling to have it fall so easily today. I wrote some stupid simple wrapper stuff for the serial stuff, which now lets you merely say VibrationScript.SetVibrate( int motor, float vibration). Hook it up to turn on on when hoping click and ah! I never get bored of physical actions being performed by a computer. A click = a buzz! How delightfully arbitrary.

And now all the hard technical stuff was suddenly out the way. I quickly and painlessly (painlessly enough) added raycasts -- at this point writing I fell asleep. Since it's now a week later, I'm going to post this as is.

But basically, the interesting technical bit is done. Now I need to make the game (or rather invent the game) and tune it to feel right. Which is rather exciting.


06 November 2010

Headband Work Log - A Single LED Turns On

So! Progress has been made! I didn't expect this, but here we are.

The COM11 thing is resolved - Device Manager turns out to be remarkably intuitive and powerful, and let me reassign whatever-the-fuck it was on COM5 to COM11, and COM5 has now been set to be my Arduino board. So that's happy, even if it is a gotcha for running on any other machine. But fuck it, there's only one headband, how much can portability matter? (I fully expect to eat these words)

The other problem was Mono hating to do things with this Firmata library. My first thought was "Fucking threads, how do they work?". After understanding them a little more, I concluded they were most likely not to blame. Instead, I decided to blame it on Mono's SerialPorts module sucking big floppy donkey dick. More precisely, asking for port.BytesToRead on Windows will crash your program. Luckily Unity's crash report contains the Editor.Log, so I could painfully add debug statements and narrow down the problem. Then followed rewriting of the Firmata library code I had scavenged before. Before, the code was like this:

while(port.isOpen){
	if (port.BytesToRead){
		lock(this){
			int data = port.ReadByte();
			//do a buncha stuff with data
		}
	}
}

Now it's like this:

while(port.isOpen){
	lock(this){
		try{
			int data = port.ReadByte();
			//do the same buncha stuff
		}
		catch(TimeoutException) {
			continue;
		}
	}
}

Which has the downsides of being a bit more retarded, and persisting the lock for stupid quantities of time. But has the upside of not crashing Unity to the ground every time it is run.

I also edited the constructors so that they default to not auto-starting the port. Unity seems to have the wonderful knack of calling constructors when in the Editor, so the serial connection was running every time, not just when the game was started. Now they only autostart when I pass in that option in Start() (Unity runs this when an object is first run in the gameworld.)

I also spent like an hour wondering why the existing headband vibrate-near-a-wall functionality which I wanted to show off wasn't wondering. Eventually I realized I was loading up an old, retarded version of the sketch. Good work, George! I also soldered a vibraton motor back on, as it had come loose. The wires coming from them are really thin, they don't have much strength in themselves. The whole prototype is flakey - wires fall out all the time. It's also an intimidating thing to put on someone's head. I'm all about accessibility, and I will admit that the way it looks now, it don't look inviting. Also, for non virtual-world use, it needs a battery pack.

Anyway, the Firmata-in-mono part seems to be working to some extent (there was some time before I got the baud rate the same on both ends). I have turned an LED on and off. And then when I tried to turn it on again, Unity appears to have died...

So, what next? Well, first thing, future George, is to set the timeout of waiting for a byte to be crazy short. It'll make that thread a lot snappier, and hence block the port for shorter periods of time. Next is to actually encapsulate the vibrating-a-patch-of-head thing, so I can forget this serial stuff exists.

Oh, and, Tim who made Firmata.NET? Thank you for doing that. It's not your fault Mono is occasionally poopy. (Oh, and thank you Mono authors. I totally get why SerialPorts is a bit poopy, and I know that I should really go in and fix it. The trouble is, I can't change what runs within Unity, so this proper fix will only help me years from now... which doesn't seem as fun as moaning.)

(modified Firmata.NET)


21 October 2010

Work Log

So tonight I went to London Hackspace, and as well as drinking beer and chatting, and suchlike, I worked on this headband project. You know, one of the two that I promised myself I'd finish, but the one that doesn't yet grind painfully at my soul.

The plan of attack is to get Unity talking to the Arduino board. The sensor reading isn't going to be used, so all I have to do is set some pins to output PWM (and no maxbotic setup logic to worry about!). As it happens, the bodged together protocol I wrote lets you read but not yet write. But anyway it's shonky, and standards are awesome, so lets rip it out and replace it. So now the Arduino board is running Firmata. Firmata has it's own protocol that I'm not particularly enthusiastic about writing, so I found Firmata.NET, a class for talking it in .NET.

(Although! First, I banged my head getting serproxy working. Serproxy lets you read and write TCP and have it come out through a serial port. Useful if you wanna use Flash, although a better solution is to not. Turns out the configuration file was slightly more magical than I expected, and there was no readme bundled to tell me that net_port7, for example, meant com7, not the 7th port I told it about. Also, I had to find a patched version for it to talk to com10 and above. Given on my PC anything lower than com11 is reserved... also, I had to fuck about getting telnet to work on Windows. The Windows CLI - eternally unloved. Anyway, it worked, and I was about to write some ugly Arduino code to read rotation vals when I decided to abandon all that and do it all in Unity with someone else's protocol and C code, ie Firmata.)

So I managed to get Unity to accept Firmata.NET and import (it's not import in C#, it's something else) it from an actual game object. But not open a connection to COM11. After some fiddling with opening it myself using system.io.ports.serialport, I concluded* that COM11 wasn't going to work. Reshuffle my serial ports in device manager, and hey presto! I can now reliably crash Unity!

Writing up these notes it occurs to me that window's warning that another program is bound into COM5 may be a clue. Anyway, at this point I stopped.

Next time! I guess either I fix my ports up good, or return to serproxy. I wonder if I'll ever get the GPS my laptop supposedly has working. It's just sitting there on sweet sweet COM6...

After that, I make Unity do sensible encapsulated vibratey things, hook it up to raycasters, mount them on a first person controller. And make a game/world to wander through.

*read on the internet.


19 October 2010