How To: Interactive Kiosks-Part1

You will want to go into the typical setup for a Scaleform movie before you proceed. I have added a couple components to help simplify development on my end. One key element I have added is the following function call, which is going to be fleshed out in the second part when we get to the UnrealScript end of things.

Inside button onRelease event

ExternalInterface.call(
	"onRelease",
	this.getName(),
	this.getMSG());

First, we need a second element – the mouse interaction swf. This one is much simpler. Create a new file, clear the stage and set the resolution to 1×1 pixel. There is a problem with getting the mouse interaction over to the kiosk, when it’s using a render target, so we use this SWF rendered at full screen to forward the input along.

You can find more information on working with Scaleform, the Clik (or whatever it’s called) library or the interaction between these elements and your UnrealScript driven game elsewhere, but if you have questions feel free to ask. I am always around and typically get back to people in a few hours or a day. Go ahead and publish these two and import them into your *.upk

GFxMoviePlayer Extensions

Alright we have two SWFs imported and now we need to start pulling things together. Open up your editor and lets get to work. Lets start on the MousePlayer.

Inside BTGFxMousePlayer.uc

class BTGFxMousePlayer extends GFxMoviePlayer
Config(BetterTech);

var SwfMovie MouseSWF;

function bool Start(optional bool StartPaused = false)
{
	local bool Result;

	SetMovieInfo(MouseSWF);

	Result = Super.Start(StartPaused);
	Advance(0);

	return Result;
}

defaultproperties
{
	MouseSWF = SwfMovie'BTFlash.MousePixel'

	bCaptureInput = true;
}

MouseSWF is the reference to the SWF we created previously. Start sets up the SWF and sets things in motion.  We need to add two more features to it before we move on though. First we need to be able to enable and disablemouse input, and secondly we need to pass the input along to the kiosk. This is primarily because when the SWF is run at full screen and we allow input capturing it passes it around to all of them, this can (obviously) lead to some very irritating situations.

Instead we will pause the ones we aren’t going to be using and we will add an interface to provide the contract we can depend upon. We will start with the interface. The GFxMoviePlayer has a very useful function that we will require implemented:

Inside iGFxButtonFilterer.uc

interface iGFxButtonFilterer;

event bool FilterButtonInput(int ControllerId,
	name ButtonName,
	EInputEvent InputEvent);

Back in our mouse player class we need to add a couple elements to be able to use an element that is implementing this interface.

Inside BTGFxMousePlayer.uc

var iGFxButtonFilterer Filterer;

event bool FilterButtonInput(int ControllerId,
	name ButtonName,
	EInputEvent InputEvent)
{
	if (Filterer != none)
		return Filterer.FilterButtonInput(
			ControllerId,
			ButtonName,
			InputEvent);

	`log(ButtonName);

	return true;
}

function SetFilterer(iGFxButtonFilterer p)
{
	Filterer = p;
}

This is the way we are able to hook in the current kiosk as well as pass the input to it in a reasonably dependable way. The final piece of the mouse puzzle is enabling and disabling input:

Inside BTGFxMousePlayer.uc

function EnableMouseInput()
{
	if (bMovieIsOpen)
		SetPause(true);
	else
		Start();
}

function DisableMouseInput()
{
	SetPause(false);

	if (bMovieIsOpen)
		Close(false);
}

This does, however, shore up our mouseplayer. As you can see things are pretty straight forward. Pausing when we don’t care for it, and opening it up when we do. But where do we instantiate it?

Tomorrow I will get into the GFxMoviePlayer for the kiosk, and setting up the kiosk, then ill even add a couple pieces of input on how to trigger the interaction with the kiosk.

I have been up to great good over the last week or so, and tremendously so over the past 3 days. I have replaced the theme here a bit, but that’s bound to change again in the coming weeks. Lets get into the meat and potatoes of the changes within the game.

In my down time I have been playing with TCPLink, a class that allows TCP networking calls to be made from my game, to virtually anything else I choose. I have put together a POC that is able to POST, just as an HTML form does, to my webserver and retrieve information at my will. In the coming week ill add the persistence layer and start a job to reset it every few days (so I can screw things up properly and still be able to revert to the original game state).

As things stand I think that this is the first step in making something really amazing. There are a few games that I have played (Minecraft, and some MMOs) which would really benefit from a certain level of persistence across all servers. I am now able to provide a certain amount of it for BetterTech, and so begins the whole process. In other words, when you join a BetterTech Server it will have to have registered with my own, and you will be able to take your character where you choose.

One tricky bitch of a segment was the content of the actual POST request. Hopefully i can help lighten someone elses load.

function int SendText(string s)
{
	return super.SendText(s $ chr(13) $ chr(10));
}

event Opened()
{
	SendText("POST /" $ Page $ " HTTP/1.0");
	SendText("Host: " $ Host);

	if (Data != "")
	{
		SendText("Content-Type: application/x-www-form-urlencoded");
		SendText("Content-Length: " $ len(Data) $ chr(13) $ chr(10));
		SendText(Data);
	}

	SendText("Connection: Close" $ chr(13) $ chr(10));
}

One element that is still in the works is this kiosk…

It features its own render texture which should, in theory, allow users to interact with each kiosk separately. I have to figure out the interaction layer still though. One option is to only grab the numpad keys, allowing pager code type interaction to be implemented, and emulating a true ATM pretty closely. The second, more powerful, option is to grab all input, including projecting the mouse location into the kiosk. I think this would be more free, but it is also much more involved and would definitely move this out of the realm of proof of concept.

I am also getting considerable response from people interested in testing and helping the project out! Thank you all for your emails. I’ve already answered a couple. I will likely be looking for 5 or so testers to help out confirming and hardening the codebase. Especially with the addition of a webserver to the list it is important that things are developed in a secure fashion. If you are also interested in helping out with the testing team I would love to hear from you. Please shoot me an email at bob@gneu.org. I am always around =)