Every player always spawns with 100 adrenaline. In a CTF setting, the player will have to choose between their current set of weapons and powerups, or death and full adrenaline.
Better have your suicide buttons ready. 😉
Every player always spawns with 100 adrenaline. In a CTF setting, the player will have to choose between their current set of weapons and powerups, or death and full adrenaline.
Better have your suicide buttons ready. 😉
This mutator adds the Fake Flag Combo to the arsenal of combos usable for UT2004 players, in (V)CTF settings. Inspired by a suggestion of head-shot, the combo will show mimic the appearance of a flag carrier in order to confuse the enemy team.
Load this mutator. In order to activate the combo, perform the combination BBFF (back, back, forward, forward). It is the same combination as the necro combo for TAM, chosen since it doesn’t overlap with this one and both combos are support combos in their respective gametypes.
Note that, due to the nature of this combo, a few special rules apply. Interacting with the real flag stops the fake flag combo from working. Therefore, the combo won’t be activated if you’re already carrying the real flag, and picking the real flag up will stop the fake flag combo. In the latter case, the remainder of your adrenaline is saved. The combo will also not work with vehicles, similar to all other combos.
My masther thesis was combined with an internship that was available at Avanade Netherlands. The AR application that was produced as part of the thesis is property of Avanade, which is why I cannot share the code publically. If you’re interested in specific parts of the code or how something works, please contact me personally.
Feel free to download my master thesis.
In this master thesis, we investigate and compare the usability of two interaction concepts for 3D augmented reality applications on handheld mobile devices. Augmented reality applications allow a user to look at the live image of a video camera and enrich the scene with 3D virtual objects. Interaction with the virtual objects requires the user to perform manipulations in 3D space, while common interaction on mobile devices is often touch screen based and therefore in 2D space. Mapping 2D space interactions to 3D space manipulations requires a non-trivial solution. We deal with this issue by mapping the interactions along the physical surface on which the virtual objects are augmented. This solution allows the user to move a virtual object along the physical surface, similar to an object in the real world, using only 2D interactions. %We devised a method to map 2D space interactions to 3D space manipulations, which takes advantage of the physical surface by detecting the location of the ground plane relative to the handheld device. We developed a touch-based and a crosshair-based interface that act according to this principle. The crosshair-based interface was expected to perform better in performance and usability, since it avoids some issues that the touch-based interface suffers from. We compare the performance and usability of these two interfaces by conducting a user study. From the results, we conclude that the touch-based interface outperforms the crosshair-based interface in both performance and usability for a various number of reasons. During the user study we also observe an important behaviour: users tend to keep the device stationary and use it as a window into the augmented reality environment. We present this observation as part of this thesis’ major contributions.
MogMyGear.com was a personal project of mine. It was inspired from the new feature Transmogrification, introduced in patch 4.3 of the MMORPG World of Warcraft. With transmogrification, called ‘mogging’ by the community, a player can change the look of his gear, allowing him to wear what he finds pretty without losing the benefit of his powerful gear. Since a database of cool looking gear didn’t exist yet and I got tired of trying to find matching pieces manually, I decided to create it myself.
In order to view many sets on different kind of races, I had to make some sort of gallery. For that, I needed the pictures of all races wearing good looking gear sets. To find those sets, I had to extract them myself from WoW’s data files.
I modified a version of WoW Model Viewer and used it to extract names and IDs of all the gear present in the data files. From that, sets were generated using multiple algorithms that would match similar named items that follow Blizzard’s gear naming convention. A lot of manual labor was involved to get rid of faulty gear items (such as non-available duplicates and unavailable items), faulty gear sets (matching names but non-matching appearance) and missing gear sets. It took a lot of time, but I managed to extract a total of 1327 sets.
Of all those 1327 sets, I wanted to make a screenshot for each of the twelve races, for each gender and from tree points of view. In other words, the complete gallery would require a total of 95544 screenshots. And of course a thumbnail of each picture, meaning I’d have to produce a total of 191088 images. Luckily I could automate that process. It took my pc half a day to complete the task though.
With nearly 100.000 images, I needed some sort of gallery to display them in an orderly manner. Since I was doing most things from scratch in the project already anyway, I figured I might as well build a website from scratch too. That is how MogMyGear.com came to be. The website was designed after the Ethereals, ghastly people who also provide the transmogrification in-game. The image buttons of the user interface were inspired after WoW’s user interface, replicating the same behaviour. I assumed this would make it more intuitive for people to browse the gallery.
Visit the website: MogMyGear.com
This project was a collaboration between the University Utrecht and the HKU, for which I joined a team of 5 HKU students. The goal was for us to build a game from the ground up to delivery, and experience the whole process of game design. The HKU students were mainly designing the game and I was mainly assisting with technical contributions (i.e. problem solving and performance issues).
Our task was to produce multiple dadaistic games for Fourcelabs, a small game company who focuses on developing pervasive games. Our game design process came forth with fourteen prototypes, of which two were eventually chosen to be fully developed: the Arcrane and Demolition Birds. In the four months we were given to produce the games, we were able to create two games that had a dadaistic and absurdic feel to it. Fourcelabs was very satisfied with this result, especially with their experience of similar jobs for teams that weren’t able to completely finish one game.
Some media displaying the final result. Note that they are all in Dutch.
If you wish to read more about the game design process, scroll down to my Report on Game Design project.
At September the 12th, a group of HKU students and I formed a game design team, which we called Team Dynamo. Our assignment was to produce games with a Dadaistic twist; when you expect something to happen, something else may happen instead, which is often the complete opposite. With this information, we thought of a total of 14 concepts. From these, we made prototypes of the most feasible ones. Four prototypes had potential of becoming a game, of which we chose two to actually make a game of.
Creating the prototypes and games was often a challenging task, requiring proper knowledge of physics and the game engine’s architecture (in our case Unity3D). In the next section, I shall highlight various technical contributions that I’ve done, in order to prove that I’ve been a beneficial asset to the team.
My noteworthy contributions are those related to programming three prototypes and one game.
The first prototype I started to develop was the bobsleigh. The concept was about multiple players sitting inside a physical bobsleigh, using their body weight to steer their virtual bobsleigh into the right corners. The bobsleigh itself would mostly be affected by the physics engine, with the intent to produce an accurate bobsleigh simulation.
I started off with creating a simple sliding block on an equally blocky track, for it was also my firs t experience in working with Unity3D. I tested out various shapes and sizes of the bobsleigh, to see how it affects the way the object acts in a physically simulated environment. In addition, I tested out various track sizes and the properties of the physics engine and the physics of the objects (in Unity3D: PhysicalMaterials). My main objective at the time was to get a good feel of how Unity3D worked, for during this time, my colleagues created a more realistic looking track and bobsleigh than the objects I created from geometric primitives. The new bobsleigh sled visually a lot more realistic through the smoothly curved track, though the physics didn’t exactly perform as expected.
One of the issues with the bobsleigh was that it was sliding too much to the side. I was able to solve this by setting the friction of the skates to match that of a real skate: very low friction along the skate, but very high friction perpendicular of the skate. There were more issues, such as the bobsleigh toppling rather easily and the bobsleigh not rotating along the track, but the team leader decided that the time was best spent working on another prototype. Since the bobsleigh game never made it into an actual game, the prototype was never developed further.
The fishing game was the second prototype I started development on. The concept wasn’t as worked out as other concepts; no Dadaistic traits were present and the gameplay was simply to fish up fish. There were some ideas about using computer hardware to throw at fish, causing certain effects on them depending on the piece of hardware, but the concept hasn’t been worked out up to that point.
The prototype I created was pond with a boat in it. The fish were spawned at random points in the pond. To make it appear as if a fish is swimming, I picked a random target destination inside the pond’s perimeter and made the fish swim towards it. Upon reaching the destination, a new one is chosen. At certain intervals, a random fish was picked to bite the player’s bait. Baited fish could be reeled in by pressing up; a fully reeled in fish awarded a point, while letting go prematurely made you lose the fish.
The technically more interesting part would’ve been the turning of the fish when it is swimming, and to create a physically accurate representation of reeling in a fish. However, it was unsure if this concept was going to make the cut. Therefore it was decided that we would spend no more effort on this concept until we were sure, and I started working on yet another prototype. Later it was decided that this concept wasn’t interesting enough to be turned into a game.
Schracen is a combination of “schreeuwen” (“screaming”) and “racen”. The concept was about having two players cooperate at controlling a car by screaming at their steering wheel, which holds a microphone. Depending on the volume of the players’ voice relative to each other, the car steers to a certain side.
It was my job to create a prototype where a car could be steered in an environment. This would then later be connected to a steering based two input volumes. I familiarized myself with the car related physics of Unity3D. The construction of a car that is correctly physically simulated is rather complicated and it took me some time to fully understand it, but I was able to construct a simple car that can be driven around eventually. However, development on this concept stopped when we noticed that there was too much delay between screaming into a microphone and actually registering it. Another reason was feasibility, which also applied to the bobsleigh prototype: it requires building an interesting looking environment, which likely could not be finished in time
The work on the car was not lost however. I was able to reuse it for testing purposes for the bird game.
The bird game changed a lot since its first concept. It started off as a single player game where the player would fly around a city. The objective was to fly as far as possible with the limited resources you had. The concept later slightly changed to the game being about an obese eagle being trapped on top of a corporate building. His energy is limited and upon spending it all, he gets a cardiac arrest and crashes down. The objective was to cause as much damage as possible when crashing into objects.
For this purpose, a destructible city was created. During testing, we noticed that the destroyed city with all kind of objects floating through the space was a rather trippy experience. This coincidental result, and the additional interaction of the bird with the objects, actually lined up with the desires of the employer concerning the feel of the game. From this experience we created a new concept: it would be a two-player game, where each player tags objects (including whole buildings) by colliding with them. Tagged objects get the tagging bird’s color, and get the ability to tag smaller objects by colliding with them.
The colliding of the bird with the objects and the objects with each other was one of my technical contributions.
The physics of the city objects falling apart was something that needed to work and look good, for the game relied on that. The city designer created the objects to be separate entities consisting of sub-entities; this allowed me to attach a script to the parent object, and make the object (such as a car) break apart when collision with any child occurs. As mentioned at the end of the Schracen section, I used the car to test several physics setups. Generated colliders, a feature of Unity3D when importing meshes, caused unrealistic physics simulation and was therefore unusable. Instead, the scripted creation of non-convex MeshColliders turned out to produce good effects. The resulting script allowed for any object to become a FallApartObject by attaching the FallApartScript to the parent object (which also added the MeshColliders and child scripts that where necessary).
Since the city consisted of hundreds of objects, I decided to group them all under a single City object, and attach a script that would attach the FallApartScript to all of the objects. This allowed for further iterations of the city to be able to fall apart by attaching a single script to the City object, which handled all modifications on its own at startup.
The physics collision between the objects and the bird was a tough one. Since the bird has a specific control mechanism to allow accurate steering by the player, physics simulation on the bird is not possible. Tests in which the bird was affected, the bird would become uncontrollable due to the forces the physics simulation applied to it. The physics engine of Unity3D is a little odd in dealing with physics between simulated and non-simulated objects, but the issue was eventually solved by using triggers. The downside of using triggers is that no contact points are generated, so instead I made the bird apply a force based on the current direction of the bird. An additional advantage of this method is that the player is able to aim the objects he collides with.
As the project progressed, the city that was being designed for the game expanded greatly. The last iterations of the game featured thousands of individual objects (such as car doors), with the final one containing over 2500 objects. When testing these versions it became apparent that when the larger part of the city was physically simulated, the physics engine had to perform so many calculations that it grinded to a halt, and that we could express the framerate in second per frame. We feared that Unity3D was unable to cope with our rich decorated world. However, I was able to recover a good framerate after applying two solutions.
The first solution was the use of physics layers. I wasn’t aware of this feature in Unity3D before this issue, but it solved the bulk of our framerate problems. Objects in the game can be assigned to a certain layer. The layer is useful for identification of the class of the object, but more importantly is also used for determining if objects belonging to a layer can physically interact with object of another layer. Combining all possibilities yields a Layer Collision Matrix, which is shown on the right. As can be seen there, some layers have their ‘can collide with’-box unticked. These layers contain objects that are tiny compared to the buildings that are present in the game, and therefore do not require accurate physical simulation. After turning off the collisions between these layers, the framerate rose to a reasonable level. However, it wasn’t sufficient to solve the issue; when nearly all objects were physically simulated, the player still experienced lag. Since the built-in profiler didn’t give good hints on what was holding down the framerate, I went searching for more solutions.
This solution solved our framerate problems. Our finely created architecture uses empty objects to group other objects. This is a recommended procedure by the creators of Unity3D, since groups or folders to visually structure objects placed in the game do not exist. But this practice introduces a new problem: whenever a child object moves, its effect on the parent is calculated. What is kept track of I’m unsure, but there is some administration going on, even when the parent is an empty game object that is never affected by anything. And since this game can have various thousands of objects moving around, lots of useless recalculations are made every frame.
The actual solution was simple: we needed our City object to keep all objects grouped under, but after starting the game, it has become redundant. Using a small script at startup that calls an existing function called detachChildren() and then deleting the empty and childless City object, the framerate of the game has become excellent.
Using the above two solutions, the game is able to simulate 2500+ objects in real-time, while maintaining a high degree of realistic behavior. It was not necessary to reduce the amount of objects present in the city for the sake of framerate, which would have made the game a lot less interesting to play. I even reckon that the game would have failed to deliver if it would have been the case, because being able to create a great clutter of objects was a primary goal for this game.
There was one issue that has kept bugging us during the entire production of the game, but never got around to fixing it: each time the game was shut down, the library used for reading the Kinect crashed. After the game got at the final stage and the rest of the team was polishing it up, I decided to try and solve this issue.
The library we used for reading the Kinect is called Tinkerer and it came with a wrapper for Unity3D. After searching through the error logs and stack trace, I came to the conclusion that the error lied inside the library. The documentation of the library did not speak of specific shutdown preparations or other functions required being run in order to shut the library down in a clean way. Neither could I find a solution on the internet. Since the final deadline was closing in soon, we decided to use a workaround: the library would simply not be shut down any more. The library is run the first time, and can then be used for consecutive games. It even gave the game a performance advantage: since the library was never terminated, our game could launch quicker.
The bird game was successfully finished, and was renamed to Demolition Birds. The Arcrane, a four-player competitive crane game was also successfully produced by our team. Both games were presented to FourceLabs on Friday the 16th of November, 2011. The head of FourceLabs, who is experienced at being a client for HKU projects, commended the team on producing two working games that met quality requirements.
Personally, I found the experience of working with HKU students invaluable. Design is a completely different world in the universe of IT. Working together with designers learned me a lot about what is possible and how design materializes. I would never be able to do it myself, which is perhaps the reason why I value this experience so high.
For the team, I reckon I was useful as well. My technical knowledge allowed to team to make decisions and overcome problems that may have otherwise unnecessarily caused delays or lesser results.
The team itself was a joy to work in. The team members are kind and joyful people with a passion for what they do. I’m glad I was placed in this team to give my contributions, and would wholeheartedly recommend other master students to do their experimentation project in such a collaboration. The experience of working together with people with such different perspectives and skills is something you will definitely benefit from in future projects. For this reason, I brand it invaluable.
This is a modification of the UT2004 Rocket Launcher, using cute ducklings as its explosive ammunition. The weapon has its own custom ammo, ammo pickups and matching quack sounds for shooting and reloading. The weapon skin is yellow to match the duck’s color and as a reference to the Rocket Launcher’s skin pre-release, which was yellow.
Download this weapon and rain devastation upon your enemies with deadly ducklings!
I’d like to thank 4WD for providing the duckling’s mesh and sounds, and thank dynikz and supercasper for testing the weapon.
Advanced war technology has made it possible to harness the devastating power of the orbital Ion Cannon into the Portable Ion Cannon. This weapon can, unlike its predecessor, be used indoors to vaporize your enemies.
This weapon is inspired by Mr. Evil’s Personal Ion Cannon for UT2003. It was however incompatible with UT2004, which uses different code for the Ion Cannon.
I programmed this weapon so that the Ion Cannon can be used indoors, and I must say that the result provides a very gratifying experience.
This weapon was created for the purpose of using it in specific maps. Instead of using a seperate file, the weapon is included in the map’s file for the sake of convenience.
The following maps contain the Portable Ion Cannon:
If you wish to use the Portable Ion Cannon in your map, please download one of the above maps and open it in the Unreal Editor. This will load the weapon in myLevel. Then, open your own map and use the weapon in your map, and the weapon will be included in your map’s myLevel.
This mutator allows any player to start a serverside demo, something that only reserved for server admins. By simply issuing a command, the serverside demo recording is started.
To start a demo, type: mutate demorec. You will be notified with a message if the demo starts.
How to install
To install this mutator on your server, extract the zip file into its UT2004 directory. You do not have to add the mutator to ServerPackages, nor have this mutator’s uz2-file on your redirect server.
If you wish, you can change the demo’s file name mask in ServerDemorecAccessor.ini. It follows the same format of DemoRecording.DemoMask. If no mask is specified, it defaults to DemoRecording.DemoMask (found in User.ini).
This mutator was made to fix an inconsistency with the AVRiL, which, upon firing, only applies a knockback to the player when he’s playing offline. Loading this mutator will make the knockback apply to online play as well.
The mutator features an option to only apply a knockback when the play is mid-air, to prevent him from being knocked off of ledges.
Players can take advantage of the knockback and use it for trickjumping. Here is a small demonstration of the possibilities:[sc:youtube id=”8gW_tEZRaS0″]
The above video shows that this mutator can cause gameplay balance issues. I refer you to the release thread on Vehicle Masters for discussion on this subject.
Game Engine Programming was a master course I followed at the University Utrecht. It taught me how to code in C++ and program a game engine from basic architecture (game loop, design patterns) to code and network optimization. For the course we had make two assignments I wish to display here.
For the first assignment Daan Niphuis and me teamed up to implement a simple game engine to make a 2D dungeon crawler game. The requirements included the ability to load map files, two player support, a locked gate that leads to the next level and rooms where the gate key randomly spawns. We made a short video of the result. If you want to read the command line, then please turn up the quality to 720p.[sc:youtube id=”_6yJ8r8ZARI”]
For the second assignment Jessica Siewert joined our team, and we had to implement a more advanced game engine using Ogre3D. We decided to create a 3D ballgame where the goal is to bump the enemy off the platform, with several powerups scattered around the play field for more interesting play. The implementation of the physics engine Bullit was a challenge (the course Game Physics was only given in the next semester) but we pulled it off. We also made a short video of this game.[sc:youtube id=”he5mH-_Bgnc”]