The project is now “done” in the sence that the final demo has been presented for teachers, students and companies at the Gradshow that was held March 25th. We got a lot of positive feedback (and some constructive criticism) that we took to heart. But most importantly the people who tried our game had a lot of fun!
For now, everyone on the team is out doing their thesis work but we do polish the game / fix bugs on our spare time for the SGA event later this year. If you havent already, be sure to check us out at http://gameawards.se/competition_entries/852 .
Conclusion wise I think I speak for everyone when I say that we are quite proud of what we’ve accomplished in the short time span of the project, and we had a very good time doing so! The team will meet up again this summer so be sure to visit our facebook and other social medias for more frequent updates!
And as always, dont be shy on sending us an email or a chat message if you want to get in touch with us.
Milestone 3 is upon us, and today we are going to present our game for teachers friends and colleagues. We still have one week of polish until the gradshow at March 25th, which we will utilize to put some effort into elbowing out the last few bugs and presenting a quality prototype for everyone to enjoy.
Here is my short demo of the character customization currently in the game.
Allright, so my work got a bit delayed due to illness but the level generator is now up and running complete with height differences and special track pieces.
I designed a system where whoever designs the track parts can mark where the track piece connects to the rest of the track and which other tiles it occupies. The system then finds valid locations for all special pieces and randomly assigns pieces that fits into the track.
I made a custom user interface to make it fairly easy for a level designer to mark the tiles which the track piece occupies.
The level generator now also supports several options to customize which features the customized level will have, like how straight the track should strive to be or over how large an area the level should be generated which affects the average track length.
And finally I uploaded a small video showing of the level generator in action and a short run of a level in-game.
So the character customization is pretty much done I guess. I’m currently working on the testing area where the users should be able to test out their gear locally before finding a match. I’ve been having a hard time focusing on my own specialization project as more and more issues come up and are presented in the main project.
Sounds should be added, weapons that need tweaking, xml readers that need rework are just the tip of the iceberg of what I’ve been up to this week. I’m not entirely satisfied with the current system that I’ve implemented but it works and produces most of what I was after at the start of the project.
The player can now choose from 4 different weapons in the categories:
This category allows the player to equip a passive bonues modifier to your character. The two available ones at the moment give you either +20% impact damage or a flat +20 hp and +10 shields. This opens up for more tactical choices when playing with your friends where you might want the one carrying the flag to have more hit points while your friends go for more damage to keep the enemy away from you.
These are going to be your main offensive weapons! Right now you can equip each slot with either a mine dispenser that places explosive proximity mines. Or you can choose a rocket launcher that fires explosive rockets that deals aoe damage upon impact.
This is the slot that lets you improve your movement on the battlefield. Right now you can choose to equip it with a turbo that increases both your maximum allowed speed and increases your speed over 2 seconds. This is great to give you that extra speed to increase your impact damage and catch up to enemies.
For the graphical portion of the customization system, you can for now select the color of your character for the deathmatch and race mode. You can also choose the appearance of your character by selecting from different textures available to you.
For the robot… Well, lets just say that the hats that you’ve seen in the earlier videos have found a new home!
The client-side prediction in our game is pretty good at the moment, previously I didn’t have any smoothing for correcting the rotation but merely snapped it to the value. This did lead to a pretty annoying jitter for the clients, with smoothing it is much less of a problem. Another thing I’ve started looking into is what the clients can simulate to improve their predictions. Since we make use of “Hollywood physics” where the resulting energy of a collision is somewhat bigger than it should be ( for player-on-player collisions we double the energy ), previously only the server did this and as a result the clients prediction could fall off. In hindsight there really was no good reason to keep this server side only, so now the clients run it as well. I’m will do a check to see if there is any similar stuff elsewhere in the code.
One thing I have been thinking about is the necessity to store and replay the input, what the input does is mainly alter the rotation or velocity in some manner. One could simply save these changes instead, but I guess an update from the server about your state some time back could alter what the input would do. For example maybe you can’t jump because of some debuff.
And then there is the latency, so far it has mainly been used in a LAN environment. We did make a small test with Unity’s network emulation set to dial-up which means a bunch of added latency and dropped packets, and things worked but the test wasn’t very scientific to say the least. More thorough testing will be required before releasing the game into the wild.
It has been quite some time since my last post about the matchmaking progress, so I guess it is time to let you know how the progress flows. What I have been working on during the last week is to calculate the match quality of any given game including two or more teams. This was not all that easy but I had a lot of help from the Gaussian distribution library. The match quality is calculated from 0% – 100% where 100% is the best possible scenario and describes that it is almost 100% possibility that the match will end in a draw (which is the scenario that we are looking for). It has to be noted that my matchmaking library only will calculate the best possible match quality for the members that has waited in the queue the longest time.
When enough users have been put into the queue the system will select the players that have waited longest and pick a host among them. Only players that can ping the game server on the specific game port will be chosen from; this is because users might be behind a firewall and won’t be capable of hosting a multiplayer game. Afterwards a message will be sent to the server to setup the server with the given settings who will, after successfully created the server, send a message back about the status. The matchmaking server will then inform the rest of the waiting players that it is OK to join the newly created server.
Furthermore I have been struggling with the update of the player skill points. This update depends on the overall skill of the player but also the system’s uncertainty about the player’s skill (sigma). The skill update follows the same algorithm as can be experimented with the following calculator:
Today was our first screening of the game for people outside the school and “friend” circuit. We were invited to Balderskolan where we set up shop and students of different ages with a variety of experience with games, got to try out an early pre alpha build of Impacto. It was a rough start when we set up the computers and a couple of technical difficulties postponed the testing an hour, but at least it worked out!
We got a lot of good feedback from the testers, and they seemed to enjoy the game very much once they got used to the controls. We had many close games that ended with only a few points seperating the teams at the end, and after the first match the players became really good, which shows the game can be played by anyone, but at the same time the ones who have played a couple of times have a greater skill than newer players. This is for me a great part of any good game. Skill progression is a vital part in games that have longevity and are played more then a couple of times.
We also had help from one of the second year CG students Fredrik Ortmon that helped finish the battery which is the “flag” in our HTF/CTF game mode. A big thanks to him! It looks really great both on it’s own and when attached to the robot.
Now theres 1 week left until MS3 and 2 weeks until the gradshow. Needless to say we are all really hoping that we can present something extraordinary for the gradshow and something good for MS3
The last 2 weeks most of my time has been devoted to the game and less so to my own project. On the bright side the client-side prediction that I’ve spent some more time refining is progress on both fronts, and the same can be said for many other things. Still, there is a lot of things that I would have liked to finished by now when it comes to syncing rigid bodies, compression and prioritization being the biggest things on my list. Hopefully I will be able to find some time to get those 2 done properly
As my teammate Peter posted earlier “killing your darlings” is sometimes a necessary evil that needs to be done to progress.
For most of the week I struggled with my procedural level generator implementing height differences in the track. I figured I’d just extend my grid to a third dimension and only allow the pathfinding to go diagonally down or up in its current travel direction. I obviously didn’t think this through enough as it lead to several problems with the pathfinding generating impossible paths for the track and I eventually found myself writing code to counteract every possible weird behaviour that could occur. This was far from optimal and I figured that simple is best so I killed my darlings and tackled the problem with a different approach.
I figured that there was actually no need for a third dimension in my grid. The third dimension only made things more complicated than they needed to be and didn’t really add anything to my system. Instead I decided to generate the track as before on a two dimensional grid and afterwards generate height differences along the path. I did this by randomly adding a slope or a hill on valid points along the track if a suitable position for a counter-slope/hill could be found further along the track and then raising or lowering every cell between these positions. This approach was both easier to implement and was faster codewise as it didn’t require as much special cases as the previous attempt.
So… as it stands now the level generator now supports both height differences and crossing over itself both on different levels and on the same. Unfortunally I am currently in the process of making new trackpieces that will both be more fun and fit better in ImpactO so I won’t be showing the new features until next update where I also hope to have support for special track pieces implemented.
I have been very busy lately working hard on many things at once. I’ve been mainly occupied with things that doesnt have that much presentability value at the moment. I redid the sound system to let our sound guy Mikael Bauer freely edit sounds of his choice and instantly load them in to the game by the click of a button. No more restarting the game or sending sound files back and forth for us to test them out! This in turns makes the process alot smoother for him and us.
I’ve also been working alot on my separate project trying to create a stand alone version for others so they can use my Character Customization system for their own purposes. Needless to say this is a big undertaking and I’ve met some hardships along the way such as trying to make the system idiot proof while still keeping alot of freedom in it.
In the main project, I have managed to fully integrate the customization of weapons and a simple color wheel selector for the players that lets the player spawn over the network with their own weapons of choice. This opens up a whole lot of new possibilities when it comes to the game mechanics and we have to tweak numbers almost every game test so things don’t become overpowered.
One of the hardest things when thinking about design, has lately been to keep the incentive of players knocking into each other. With a variety of new weapons available to the players the game has started to drift abit away from the original idea of just knocking into your opponents, smashing them to pieces. This will probably get better once we start to implement some more melee weapons as opposed to only ranged ones.