Presented at the Abertay Graduate Showcase today, which marks the end of my time at university
The showcase is also open from 12pm-4pm each day until the 15th of May, so go check out all the awesome projects if you get the chance!
Some more work on the UI & main menu, mostly back end stuff to do with the actual modification part
(Art belongs to UberEnt & Planetary Annihilation)
Some small UI tweaks today, now if the user has Planetary Annihilation installed the application will use resources from there instead.
(Art belongs to UberEnt & Planetary Annihilation)
Working on the UI in my war application for selecting upgrade tech after battles.
(Icon and panel art belong to UberEnt & Planetary Annihilation)
Progress with the actual modification part, now when players build something they will construct their unique version instead of the default. This may not seem like much but it forms the foundation of the concept, as it allows each player to have separate statistics and units.
(notice that the tower’s name has been appended with a 0, as I was the first player)
I recently started playing Planetary Annihilation: Titans (PA) multiplayer with some mates & have been really enjoying it.
As with any enjoyable PC game I quickly started looking into the modding scene, to improve our experience with preexisting mods and look into creating mods for the game personally. I discovered that PA actually has a notable mod community (though fairly small in number), which was strongly encouraged by Uber Entertainment (being listed initially in their Kickstarter as “Advanced Modding features”).
I’ve decided to try and make my own multiplayer version of the game’s Galactic War campaign mode. In this singleplayer mode the player moves through a galaxy map playing AI skirmishes and unlocking new technologies (e.g. new units or buffs) for each victory. My current concept is an external galaxy map featuring the functionality of the campaign and allowing for new technologies to be unlocked, which I have created a small prototype of in the C# game framework Otter (as pictured above). This external application will edit the base .JSON files describing each unit and export them into the game.
The major problem I foresee at the moment is that most of the unit .JSON files are not unique per player (excluding the unique commander units), which would cause any technology unlocked to be shared among all players. My current low-tech solution to this is to make a copy of each unit per player and then alter their build menu UI to reflect this.
You can follow the project here:
Work on the level editing functionality of the dashboard, initially loading the level from the Unity scene.
Heatmaps, now loading actual data from the game! In this example I jumped around the map to form the M shape.
My own take on Bossa Studios’ Surgeon Simulator, a medieval surgery demo using a Leap Motion Controller. Made in 48 hours for a casual jam.
First iteration of heatmap visualisation in the tool, currently just experimenting with fake data to achieve the right appearance.
Last week I began work on my honours project, this week I plan to move forward with more level editor functionality.
My finalised honours project idea focuses on creating an analytically-supported level editor for use alongside a prototype game. The level editor will export to XML format which should allow the editor to be used easily with many games, rather than being designed specifically for one game project.
Started testing out the new Unity multiplayer system today.
I made a little physics sandbox with player interaction inspired by Citizen Burger Disorder, namely that the player has two hands which can independently raycast forward and pickup physics objects.
The new UNet networking system is much improved from the old implementation which I tried out a couple of years ago, as it is now integrated more closely with the scene object and component system rather than purely code based.
I got a comment from Aitem who rightly pointed out that there was no way to exit the game. There is now!
I also took this opportunity to add the actual credits menu, which contains the details for the music and fonts used.
On another note; There are 4 days left of the jam!
I feel like I should be more worried about that than I am, normally at this point I am just starting or certainly have a long way to go. This year I started at a normal time and kept working on it, and I’m really happy with what I have as a result.
Recorded instructions, new minigame; Buzz Wire
I’ve been working on using the built in record/playback functionality of the Leap HandController, which has allowed me to record gestures to be played at the start of each unique minigame. This will make the game much more playable, no longer requiring me to be present to explain each section. This was something I kept encountering while play testing with other members of Abertay Game Development Society, if I left them without instruction some of the minigames would confuse players.
I also found after play testing feedback that the game was still much to hard (after all it started off as an effort to beat Dziek at his own game), which makes the experience a lot less fun. The minigames now start off very easy, to introduce the mechanics. These are later built upon to create more challenging sections.
I also added a new ‘Buzz Wire’ minigame, based on the common guide-a-loop-along-a-wire-without-touching-it games (pictured above, real-world example below).
Finally I started polishing up the menu; now it has a theme better fitting the rest of the game.
Win conditions, particle effects, other minor changes
After showing the game off at the Abertay Game Development Society again a few nights ago, I got some more valuable feedback about how I could improve the game. The main comments were;
Most of the game foundation is functional now, leaving me to;
Implemented the first iteration on hot-seat multiplayer today.
The main menu now allows the users to select how many players there are (up to four), who are each represented differently when they play. There are currently four characters; Weird Business, Bling Bling, Ruby Slippers, Unknown.
I also experimented a little with using a gesture to return to the main menu, which would be easy to carry out but not accidentally be performed during gameplay. I went for a ‘timeout’ style one-hand-perpendicular-to-the-other gesture, which should be unambiguous.
Today I worked on adding a couple more minigames and polishing up the game aesthetic.
One of the new minigames is the Target Practice mode shown above. Players shape their hands as guns and imitate the recoil on a gun in order to fire.
I decided to go with an art style similar to the one I used last year with Breakfast Simulator, a flat coloured cel-shaded aesthetic. I also replaced the default Arial font with something with a carnival style to better fit the theme.
After showing the game off to a few friends at the Abertay Game Development Society and watching their fumblings, I realised that many of the gestures for the minigames needed to be clearer. Initially I had the gun recoil as a gesture straight backwards away from the scene, whereas many people expected to fire either by imitating the hammer with their thumb press or by recoiling at an angle. Overall the feedback was very positive & I hope to have made the experience more accessible before presenting it to them again next week.
I also set up the Github repository today;
I’ve decided to enter the Leap Motion 3D Jam again this year; the jam lasts 6 weeks and is only 2 weeks through, so I still have plenty of time to work on my submission. Last year I spent a few days working on a Oculus Rift DK2/Leap Motion Controller experience and created Breakfast Simulator. Overall I’m happy with what I accomplished; it was my first experience with developing/using any virtual reality technology, so I spent most of my time playing around in the sandbox kitchen I created. This year however, I’ve decided to forgo VR and have a larger focus on actual gameplay.
With this in mind, I have developed a simple prototype for a WarioWare style game (i.e. a multiplayer collection of quick minigames) which I can expand and polish easily. Due to the limitations of the Leap, I plan to implement a hot-seat style multiplayer mode (i.e. players take turns to complete each minigame). Players will have infinite retries on each game until one of the players completes it, at which point the remaining users will have one last chance to succeed at it before moving on.
Here is a video of my day one prototype progress;
Just a quick update today, implemented the team selection menu & chose some appropriate clothing to identify the teams.
I ran into a bug which caused the client and server to become unresponsive, so I’ll be looking into that tomorrow.
I’ve also been trawling the forums for references of plugins changing weapon variables. After a while I stumbled across someone with a similar question; they wanted to know how to change the types of ammo a weapon would accept. The general consensus of the replies seems to be that these variables have client-side counterparts which plugins cannot currently change, which lines up with what I was experiencing. This means that I’ll have to make do with the weapons as they are now, which is a workable if a bit disappointing. After Garry’s Mod I can only assume that Facepunch do have plans for an official modding API or at least more support in the future.
I realised yesterday, after creating the basic loadout system and testing it with the Soldier class, that for the plugin to be functional I would have to edit the base game variables of weapons and ammo to alter fire rates and damage.
With this in mind today I have been exploring similar plugins which edit base game values, such as Stack Size Controller and ItemConfig. Reading through Stack Size Controller gave me a good base knowledge on how to achieve this, which ItemConfig built on – being the more complex of the two. I couldn’t find any examples of plugins modifying weaponry specifically, so I spent a lot of time printing out the various Components each GameObject possessed and trying to work out which was which.
At the end of the day I’m still hitting a wall with trying to have changes to weaponry, so I’ll be leaving this for a bit and working on team colours tomorrow.
Started looking into modding Rust today.
While reading through the Rust devblogs and community updates I discovered a few server-side mods which caught my attention, and so I decided to have a closer look at the tools available. I’v decided to use the Oxide modding API for now; as it seems to have been in development consistently longer than the other options, and allows for plugins created using C#. I also found that Garry added a “community entity” to Rust, which allows modders to send GUI JSON code through remote procedure calls to the clients. This opens a lot of possibilities for modding Rust with in-depth plugins which can communicate without spamming the chat window, as I had previously thought my options would be limited to.
With this being my final year of studying Computer Games Technology I’ll be working on a games programming related honours project, and later writing a dissertation about it. I will be posting updates here as I progress with the project.
The main outcome I want for this year is to have a quality game prototype to add to my portfolio. The project must have a technical focus to allow me to research & document my findings, and so my first goal is to decide what this focus will be. Here are my current thoughts;
This week I finalised the simulation by adding functionality for the fire to spread between multiple planes.
The fire spreading information is stored in an array of objects with a MAX_OBJECT count. Each fire spreading plane in the scene is initialized with a unique ‘fireID’ attribute which describes the index of the array to lookup when simulating the fire. Each object has a separate particle system, however they are all linked to the same nucleus and so all share the same wind and gravity forces.
I ran into a problem with all the fire objects all igniting in the same way at the same time, despite having different array elements describing them. After looking up similar issues, I found that it was due to the way I was creating the two-dimensional arrays, which meant all the objects would share the inner array information.
Collisions events are fired when the blue (less frequent) particles collide with a rigid body. When this happens, the mesh the body belongs to is looked up and then the closest face to the collision is set alight and the simulation starts. The main, visual fire particles have collision turned off due to the number of them, in an attempt to counteract any slowdown caused by the simulation as I am targeting real time game applications.