Saturday, October 22, 2005

Sensor pads working

Tonight I have tested the sensor pad mockup I made, basically 2 bit of wood and some foam, and it WORKS!. If a user steps lightly on the pad, the person starts walking, when the person steps harder, the person runs! :)

I have also gotten the airstick working, there were some hastles, basically unreal joystick support is dodge, but thats all working now, and it feels pretty good, although we will need to user test over the weekend to tweak the interface, its basically done :)

Thursday, October 20, 2005

Ceiling done

Some quick pictures of the ceiling, 6 hours later :P

Wednesday, October 19, 2005

Room and Underworld progress update

Quick update:

The room is destorying my inner child. Simply put, the amount of fabric to work with is just simply too big, it doesnt fit in a single room (even the workshop). Working on it tomorrow, so will get it fixed. As far as the design is concerned, added 4 curtain rails for support, and also wood for the top to glue to the fabric so it doesnt sag. Still waiting to hear back from bunnings about sponsorship so dont think it will happen.

Sensors are being built atm, basically just 2 bits of wood each side and foam in between for the sensor. Will be testing this tomorrow night.

Airstick has arrived today (heard from our client), so we should be able to give it a test run tomorrow.

Paul has said he may have the calculation program done this week, however I will email him tomorrow about them.

Bought an infared kit today (like the ones that shops have to ding whenever someone enters. Hoping I can hack this apart and attach to an ezio sensor so I can sense when someone has jumped, therefore jumping in the game.

Finally mark is working hard on the underworld, here is some pictures he has sent me earlier:

big weekend ahead, out tomorrow at 8:30 to scour the neighbourhood for things to use in the room, as well as test the sensors, test the IR, test the airstick, finish the underworld, get it all together, set up the room, and start coding :). Hopefully will be ready by monday, even if it requires 0 sleep.

Sunday, October 16, 2005


Consists of
- A corn texture applied to a mesh, duplicated numerous times.
- The mesh is the same used for the gras, only scaled differently. So the performance hit is minimal
- The soil is a model made in 3DSM and a modified/ploughed soil texture applied

Saturday, October 15, 2005


Five minute job.


Avatars and Skins
With the short timespan left, it seems the easiest way to get avatars working in the map is to use existing UT2004 player models, or models others have created and packaged for UT2003/4. The problem however is that there is a severe lack of models that suit a Mayan environment. Most are of aliens, robots and Simpsons characters. However i was able to find 2 models (one male and female) that are at least somewhat suitable, once the skins have been altered. Both skins have had a skin darkened as well.

Female A
The original had a blue dress and blue hair and black boots. I changed her dress to a faded red, made her hair black and replaced the boots with sandles.

Male A
This is a model of the leader of a skinhead clan apparently. The original was covered in various tattoos and wore blue jeans and boots.

- The models have different shaped feet because they are meant to bw wearing boots. Replacing them with a skin texture results in odd looking feet, however it can be masked if the avatar is walking around in the thick grass.
- The models' are made for UT2004, where players hold weapons. The characters come with idle animations (such as the female's standing pose) that may be suiitable, however walking around is in a gun holding position. Some avatar couldperhaps be carrying a bale of corn or a pile of sticks as they walk around.

I have been familiarising myself with the AIScript and ScriptedController systems even further (it's quite a complex system) and have been able to get these custom avatars controlled by them. This means that the characters can walk around the level in a set path, or they can play sounds as they go (talking?) and also talk (play a sound) or change their animation as a player approaches. It is possible to set conditions so the characters will do different actions based on something in the level, however I have not yet tried to get this working, and I'm not sure where and how it could be used in the final game.

I have the new grass in. It looks more realistic (in my opinion) than the other grass, and also sways around. I have also increased the density 5 fold which, due to it all using the same mesh, has little effect on performance.

The Environment
Looking at the Erik linked to has been a fantastic resource in seeing how the environment looks. Contour maps etc shows the temple locations, however these ariel photos show forest growth, fields between the temples etc. They are of the modern day site, however are still good reference to go by.

Also, another fantastic find was a painting by Christopher Evens of a Mayan city. I'm not sure of the accuracy, however it clearly shows the Palace and Pyramid temples in their correct locations. The stone floor surrounding the area is something interesting, and will have to bring it up with the client on Monday. I think it would be a great resource to base the environment on.

The Staff:
I have created a working version of a staff that shoots lightning as per the client's request. The staff is a child class of the lightning gun, with a custom model. The client has stated that the model is not an accurate representation of a Mayan staff, however the model can easily be recreated and imported over the top of the existing model.

The client has also expressed interest in creating a blow-dart style weapon. Any such weapon should be easy to create, by extending the existing weapon classes. The flak cannon is the most suitable, as it can fire a projectile which is affected by gravity. I have asked the client for any information/pictures on what such a weapon may look like so it can be modelled and textured in 3DSM.

Assault Mode working !

Today I have been working on modifying the Unreality game type (see the big update post) to extend the assault mode. What does this mean? Through talks with our client, we have decided that the Assault mode in Unreal 2004 would be our best bet, as it offers the best single player experience in terms of progression. Assault mode gives players a set of objectives, which can then be carried out by the player. Types of objectives are getting to an area, getting close to a particular player or actor, standing in a single place for a period of time, or destroying an object. This means that we can build our game objectives around these categories, and this enables us a lot less coding time. It also means that it "SHOULD" be possible to run a network game between our setup and a normal computer, however due to not having Unreal for Mac (that works) we have not been able to try this yet. Here is a screenshot of what the assault looks like at the moment, we will change all the icons and everything to make it fit in better with the game:

Here is also a screenshot of the game menu (been having problems screenshotting it):

Mark has a series of Avatars up now, and also has created a staff that shoots out lightning. Unfortunately dont have any screenshots of that at the moment, but hopefully will be up soon.

At the moment the HUD is causing all sorts of problems, as can be seen in the screenshot the minimap is there, however I want it to be circular instead of square. At the moment its using the DrawPortal function, however I have been toying with the idea of making as a texture instead of a portal. To do this I created a securitycamera within the level, that followed the player. Then I applied a shader to make it round. However Unreal doesnt seem to support having scriptedtextures placed on the HUD, therefore it is impossible to do. I could have a square that followed the player with the texture, but I believe this is a very dodgy solution so I wont progress with it. Today I will be doing more stuff on Assault mode and also remaking the HUD textures and stuff to fit in with the new SQUARE minimpa :(

Tuesday, October 11, 2005

Plan until submission

Okay with only 12 days until submission, it has come time to write down a plan to stick to until deadline. There are an enourmous amount of things left to be done, so there isn't much more time for stuffing around.


Tuesday 11th - Testing out material and this document

Wednesday 12th - Finalizing the construction of the room and game design documentation

Thursday 13th - Finish game design documentation and begin unrealscript and interaction documentation

Friday 14th - Continue with unrealscript documentation and finish HUD

Saturday 15th - Blog and set game up for assault mode (with objectives)

Sunday 16th - Do professional practice assignment (30%) and set up cube

Monday 17th - Meeting with Erik and finding out whether room can stay up till exhibition and book out projector

Tuesday 18th - Chase up mesh settings for cube and do sensor pad construction

Wednesday 19th - Insert the assets into the game and make anymore that are required

Thursday 20th - Same as thursday + blogging and finalizing unrealscript and interaction documentation as well as making the push sensor work correctly

Friday 21st - Final research into Mayan civilization and begin constructing goals based on the game design doc and the research

Saturday 22nd - Get the cube working fully with the projector

Sunday 23rd - Final testing of the game (adding any code) and making box/manual/faq etc

Monday 24th - Present and finish anything not formally completed

Tuesday 25th - Sleep.

And I think that should cover almost everything.

Tuesday, October 04, 2005


Sorry about the big delay, have been working so hard we haven't had a minute off to blog! (:D). The project is progressing well (although extremely slowly), and is looking like a few 100 hours work to get to a good stage. We are currently using IRC, MSN and whiteboards to collaborate and keep track of our progress, and we have modulated the code so that it is much easier to transfer and update between computers (see code section).

The room setup at the moment is going really well, except for some minor hastles. A budget of 100$ was given to building the room (dimensions 2.5 by 2.2 by 2.2). After many designs and many wasted pieces of paper and dead pens, I decided that there was no feasible way to create a freestanding structure of these dimensions which matched the criteria (portible, sturdy, safe and projector reflectivity) without stealing many housing estate signs. I collaborated with a friend who has had many years experience with structual physics and building things, and we decided that the best way to match all criteria in the budget was to create a structure that used the roof for support. The ceiling in the room where we are to present is tiled, and these tiles can be pushed up so that rope can be attached to the steel that holds the tiles in place.

With this decision done, I then began started designing a solution that incorperated the roof. Something light, portable but also sturdy enough to hold the walls in place was needed as a base structure. I decided on electrical conduate as I could aquire some for free and it met this criteria. I built a structure that was 2.2m by 2.2m in size, with an extra 100mm on either side for support to the ceiling. Although I was unsure how I was going to attach the fabric, this was a start and one that was needed as this side of the project was severly draining energy from the team. I used 10$ worth of 1/4 inch by 2 inch bolts to hold the conduate together. Eventually the structure was complete:

The structure was designed in mind with the roof, and after aquiring some stiff wire, 12 hooks were constructed that would connect the structure to the ceiling.

-------------------- --ceiling
V V V V V V --hooks
--------------- --structure

With the structure complete, I then had to choose a fabric that would be sturdy enough to hang from the structure and not twist or gather, as well as a fabric that would have enough reflectivity for the projection. Through a friend I got a bargin on projection material fabric that satisfied both of these requirements. I then designed the cut for the fabric so that 2 walls and the false ceiling would consist of one piece of fabric, and then the front wall would be a seperate piece. This means that the fabric can be transported without creasing it, and it is also the best way to secure it to the structure. The material looks like:

The cost of the material was 90$, which finished off the given budget. I then bought some acrylic cotton that will be used to seam the material so that it bends at the corners properly without curvature. Excess material is also available to block out any light from outside the room, so that the picture is as vivid as possible.

The mirror has arrived, and myself and Erik tested it out (see previous post). I have also begin testing out the projection screen, and I am hopeful that Pauls measurements will be possible to do through the projector alone, rather then the game itself (which will be much more difficult). I have also tried to hook our PC into the sound equipment in the room we are using, but have so far been unsuccessful. I am hopeful that we can aquire a nice digital surround sound setup which can be places outside the 'room', as our game sound and music will be designed with 5.1 surround sound enabled.

Currently I am hoping that the fabric will be completed and attached to the structure by the end of this week (week 11). I then hope to test out the setup with the mirror and Pauls calculations on friday of week 11. Once this is complete, the structure will be pulled down, and only put up again at the end of week 12. Then that leaves 3 days to get the screen setup perfectly and working with the game.


The interface part of the project has not been progressing very well as of late, but still is the most progressed of all the parts of the project. There are three main parts to the interface, the floor sensors, the 'push' sensor, and the airstick.

At the current time, the airstick has not arrived, although it has apparently been bought. This causes major dramas for our project, as it was anticipated to be the piece of technology that bought the immersion, although if it does not arrive in time for the project it is possible to use a standard mouse. The problem with the standard mouse is that it will make players extremely uncomfortable (as we have found through testing), and will make the effect of the floor sensors lessened.

The floor sensors are almost complete, although there have been some major hastles with them. Firstly due to the age of the EZIO boards that we are using, the time it takes for readings to be taken on the sensors is extremely inefficient. With four sensor readings, there is around 2 seconds of lag, which is not acceptable. However we have discovered that adding multiple EZIO boards will relieve this problem, and so for the final we are hoping to aquire four EZIO boards (at the moment we have two). Another problem is again due to the age of the boards, there is crossover on the connections on the board. This means that when one sensor is pressed, the other sensors also detect a small reading. This means that if a player interacts with the sensors to move forward, then they may also sometimes begin to move left. Again this problem can be removed by using multiple boards. This weekend will also involve creating casings for the analog sensors, so that players have a much larger surface that they can stand on to activate them. This will be done through a foam casing. Once these are complete, the floor pad sensors will be completed. The last stage for this interactive device will be to code into the system 'gestures' where by a player can perform actions such as jumping by performing a set of sensor movements in order. This cannot be completed until four EZIO boards have been acquired (due to the problems with user testing with 2 seconds of lag). The unreal and java code for this has been completed, with the two languages being connected through UDP sockets.

The final part of the interaction is a podium that will contain an analog sensor. This sensor will be used to 'push' things in the virtual world, in particular a stone slab that is situated within the temple. The code for sending this sensors information to the server is complete, however at this time it is unsure whether it will be possible to code. However theoretically it should only require that if the player controller is against an object, then the object will recieve the reading, and will then move accordingly. However due to time constraints this has not been tested yet, as it at a lower priority then the other interactive devices.

Unreal Game and Code:

As stated in the below post, the code for this project has now been modulated so that it is no longer integrated with the UT2004 game itself. We have also created batch files to perform the install of the mod, so that it can be run merely through "UT2004.exe -mod=Unreality". This means that myself and mark can quickly send the game to eachother without having to worry about which files to send. The basic file structure for this mod is:

UT2004 --Root Directory
\-Unreality --Our Modification Directory
\--changelog.txt --A log we have been recording changes to the game
\--compile.bat --A batch file that compiles the source code to unreal and deletes old compilations
\--play.bat --A quick batch file that runs the mod
\--ut2k4mod.ini --An unreal required file that sets the default name, description and URL for the mod
\---UnrealityLogo.bmp --Our loading logo for our MOD
\---Palenke.ut2 --The Palenke Map
\---Underworld.ut2 --The up and coming Underworld map
\---Unreality.utx --HUD textures
\---projectunreal_tex.utx --Textures for the maps and static meshes
\--Static Meshes
\---projectunreal_sm.usx --All 3dsmax models for the map are stored
\--Sounds --Where any sounds will be stored
\--Music --Where any music will be stored
\--Karma --Where any physics modifications will be stored
\--Animation --Where additional animations will be stored
\--Unreality --The compiler directory
\---Source --Source code for the MOD
\----avatarPawn --The extention of the player character model and movement
\----avatarXPlayer --The extention of the players controller
\----HUDUnreality --The HUD for unreality
\----myUDP --The socket connection code for the sensors
\----TestModKey --Interaction controls for the menu
\----TestModMainMenu --The main Menu
\----UnrealityCameraMap --Camera emitters
\----UnrealityGame --Constructor class for the game
\----UnrealityMenu_Load --Custom loading menu
\----UnrealityScoreBoard --Inventory and player action recording (an extention of the HUD)
\---default.ini --Default UT2004 ini file (required)
\---unreality.ini --Custom config file for setting up compile and path locations
\ --Construction file used to set game and map type
\---unreality.log --Custom log file
\---unrealityuser.ini --Custom ini file for binding and alias's used in the mod
\---unreality.u --Compiled source code

This structure means that the entire unreality directory can be safely removed and transferred to a clean install of the game without any problems. Although this layout seems quite simple, learning how each part of the mod (especially the ini and int files work) was extremely difficult and tedious.

The main problem we have found with the structure and coding with unreal is that there is simply no official manual. Although there is a brief reference guide, it doesn't cover any specifics on the language. The best sites we have found are:, and The last reference is the official reference guide, however most pages within the guide require registration, which costs 250,000$US. Although the entire unrealscript code (which controls all of the game minus the native C engine code) is available for browsing, it is extremely big (about 30 meg of source, which is 6 times bigger then the quake 3 source code). Because of the OO coding style, every class written has to extend a pre-existing class, and then has to be executed by the mod in the right way (either from an int, ini or class file). To use this code effectively, a coder must have indepth knowledge of OO code, including typecasting, polymorphism, extending, interfacing and instancing. The code itself is quite java like, and consists mainly of event handlers, functions and condition statements. An object is the main class, which is extended by actor, which is anything in the game. Anything above that is part of the game, including HUD's, Playercontrollers, AI, sound, anything at all. The problem with this is that the OO structure is destroyed because many things are included where they shouldn't be.

To combat these problems, we have found an incredibly useful IDE code interface for unreal (WOTGreal). This interface is excellent as it sorts the classes in heirarchy which can be look at my better. The IDE also includes syntax highlighting and quick compiling.

Another problem is the fact UnrealEd (the editor for unreal) is extremely buggy and likes to be difficult (currupting, not opening and not saving documents). UnrealEd is required for all placement within a map (actors etc), as well as setting properties, event triggers etc. It is also responsible for creating matinee (cutscenes) and any special effects. It is well integrated with unrealscript, however it is very hostile against Mods. UnrealEd is also required to compile any textures, sounds, static meshes (external 3d models) and animations. Although this program is quite effective at what it does, its problems make the workflow much slower then it should be.

At the moment in the game itself, we have completed the menu screen, loading screens, map (palenke) and are currently working on animations, HUD and the underworld map. We are hoping that we are on track, but there is an immense amount of work left to be done.

Although this is only a brief summary of the work we have accomplished so far, writing an entire list of what we have tried and finished (including code) would take days in itself, although we are hoping to have a FAQ to creating modifications for unreal in the final version. We are still looking at game design ideas, and are hoping that our client can give us a solid and scopable game idea (as he is much more knowledgable in the area of Mayan civilization then we are, although we have some ideas that we are trying out). At the moment we are behind shedual, mainly due to the unexpectedly high learning curve of unrealscript, but we are hoping to accomplish what we first stated, that is a fully living breathing interactive and immersive world that helps to educate users in Mayan civilization.