Work on the level editing functionality of the dashboard, initially loading the level from the Unity scene.
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.
My main focus this week was on making the particles look more like real fire.
After the issues last week, my first task was to fix the particles not rising out of the plane at all. After some experimentation I realised that the particles would have to be initialized on the first frame of the animation, even if they didn’t start emitting at that point – just to ensure the dynamics were properly setup for playback.
Next I added an object called ‘FEP_Controller’ (Fire Emission Plane), which controls the wind direction and strength of the fire spreading, allowing the user to key frame these to have more control over the effect.
I then made the wind description looked up from the controller influence the particles in the 3D scene by applying it to the simulation’s nucleus.
I thought I would have a chance to go back to working on the wood blackening effect, and to add the metal glowing interaction, however at this point I am running out of time and want to focus more on making the simulation work properly. With this in mind, my final task will be to have the fire spreading through multiple objects.
My work this week was focused on combining the extra fire grid polygons and surface emitting from the united output, which can be seen in the video below;
The planes are combined two at a time as they are created, the first one starts as the ‘united plane’, then each one after renames the previous and combines with a ‘united plane’ output. The particle emitter is then deleted and recreated on the new ‘united plane’, then linked to the existing particle system. This particle system is set up once during the animation and initialized with some basic colour changing attributes, which give it a fiery effect.
Currently having an issue of the particles not rising at all from the plane, though the inverted gravity in the scene should be pulling them up into the air. My next goal is to fix this.
After this week’s work I now have the grid of fire, which used to output to the console, creating 3D planes representing the subdivisions of the burning plane. I have also been experimenting with using HLSL shaders inside the Maya Viewport 2.0, creating a blackening effect seen on the wood texture in the video.
The shader uses the original texture and a noise filter texture in order to create the blackening effect when a burn value is increased. Parts of the noise texture are interpreted as embers, displayed as red lines through the wood, and parts as blackened.
Each extra polygon is stored in a group within the scene, so that the outliner is not crowded, and to allow easy deletion of all of them the first frame.
The green 3D planes represent which subdivisions are currently alight, and will be combined into one polygon to use as a surface particle emitter for the fire effects, which is my goal for next week.
By the end of yesterday I felt I had a pretty good grasp of the ChilliSource engine, so today I just did some more experimentation with its UI system.
I still didn’t have a game by the end of the jam, but I’m quite happy with having experimented with dialogue systems again, and having an attempt at isometric drawing.
The isometric style was easy to pull off in ChilliSource, as it is a 2D and 3D engine I simply placed the tiles on descending y values, rather than having to hard code the draw order.
I saw this pop up on my Twitter feed, which inspired me & moving forward I’m considering creating a procedural city with Kenny’s isometric assets (he has also provided the 3D source files) for my university Procedural Methods coursework (rather than the procedural terrain I was working on before).
— snollygolly (@snollygolly) March 29, 2015
So far today I’ve been working on the random event dialog system. ChilliSource’s UI system took a bit of experimentation to get working but now that I understand how to use it, it seems very powerful. The event panel was easy to setup & was a nice change from building a UI system from scratch, as I did for Frontier Town‘s dialogue.
Here’s a video of what I have so far;
I’m happy with the way it’s coming together so far, especially the title screen, but in hindsight I should have planned more of the actual gameplay before I began. For now it seems like my entry will be mostly about the dialogue system, with stats increasing depending on the options you pick.
I’m participating in The Meatly Game Jam this weekend as a practice run for the upcoming ChilliSource Game Jam, as I want to get some experience with the engine rather than wrestling with it during the proper jam.
The theme for this jam is “All things TheMeatly: Life as a Game Developer” which is pretty wide open. I’ve decided to make a dialogue based game in which you play as an aspiring game developer, going to game jams and studying to increase your skills. I’ve also been meaning to make a game using Kenney.nl’s isometric city assets, so I’m going to incorporate them into the game. I’m planning for it to be similar to Game Dev Tycoon, but more dialogue based.
The jam started at 16:00, and so far I’ve spent 5 hours experimenting with ChilliSource & making my title screen. A lot of what I have so far is placeholder, including the title, but here’s a screenshot of what it looks like;
This week I’ve been working on getting the basic fire spreading working in a two-dimensional array of grid spaces. The fire spreads strongest in the direction which aligns with the wind, but also spreads (more slowly) against the wind’s push.
The wind’s effect is on each of the four cardinal spreading directions is calculated and cached for spreading each time the wind direction or strength change.
My next steps will be towards displaying the spreading on 3D planes, by creating new geometry in real time to emit particles from.