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.
I finished what I set out to do. To create a playable character in a prototype game, that could move around the level and transform between two states.
But I didn’t get the quality I wanted. Mainly because I had to decide if I was going to do just the things I wrote in my proposal really well, or do everything that needed to be done for the game to feel more complete. I decided to do as much as possible for the game. But still try to prioritize the animations I had to complete to look the best.
Over time I had to increase the speed and mobility of the character to almost double the original speed, to make it easier to survive and cap the “battery” . But since I only increased the animation speed in Unity. It degraded the look of the animations.
Like I wrote in one of my earlier posts, I implemented some of the character controller myself as well. Mostly because Felix who was in charge of the network syncing didn’t have time to also research how to implement the animations through Mecanim. After the base of the controller was working, he could sync it over the network.
The last week I was more or less done, i felt that tweaking the animations even more was not worth it before I remade them to fit the new speed (Alter the original animation instead of the playback speed in Unity).
So instead I helped out on some other things that needed to be done: UI elements, particles, texturing, etc.
If I did this project again I wouldn’t have changed much. The only thing would probably to have more people, so I could focus on my specialization. For the future, I will keep practicing my animation and rigging skills. But since I also enjoyed the implementation part of this project. So I will add programming to that list.
The level was presented at the GradShow in the form of a fully playable game prototype.
People who tried our game enjoyed the progress we have made during the last 8 weeks and had high hopes for ImpactO’s future endeavors.
Personally I did not reach the goal of what I had set out to do, but I am very happy with our end result as a group. I covered my part of this group project by delivering a functional level that can show the players the future potential of the game, but I didn’t have enough time to delve deep into more advanced modular, texturing and lighting techniques. The time frame only allowed me to reach a certain level of detail and made me pull back on the amount of props. In retrospect I would have liked to put more love and care into some models and textures, but as both a level designer and an environmental artist I had to prioritize the gameplay over my own creative ambitions, in favor of the group.
The planning got revised many during the project as the constant evolution of the level was a very time consuming process. Game tests were a good way for both the group and for myself to get a broader perspective on our work and we have all learned a lot. The Unity4 engine have been a very nice tool to work with and it is a big part of our successful workflow.
In the future I will keep on focusing on asset creation with the hope of being able to put more time and effort into each individual model. The level will go through some small changes the next couple of weeks, but the general layout will stay the same until the time when we are going to compete in the Swedish Game Awards.
The HUD is taking shape after allot of ideas and opinions from the group. The biggest lesson off all this is that the perfect HUD probably does not exist. I made a bunch of different layouts and we asked around the campus what people thought and everyone had different opinions. This means that in the future, our game will probably have some sort of customization for the HUD, so everyone gets what he or she wants. As for now the player will have to settle with my wow inspired layout.
The GUI will have to display following: hp, energy, ammo and cooldowns and without using to much of the screen area. you can see in the picture that the GUI is really minimalistic and clean for the moment. The stripes under the numbers are the cooldowns. The half circles are life and energy reinforced by the three-digit number in the button right and left. The remaining three numbers are the right, left and middle ammo count, for things like rockets and boosts. I hope it makes sense and that you like it.
Alright… our Milestone 3 presentation was successfull and we would like to show you our new video, illustrating all projects included and a special surprise at the end of the video 🙂 It is only one week left until our Grad Show presentation, which means that the team is working their a**es of in order to finish in time.
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!
Last week was the worst so far. I tried to bake light maps for my low polly but everything just went wrong. My idea was basically to batch bake Ao and my global lights from final gather to my high polly models and later transfer the color to my low poly models. Turn out it is not as easy is you may think. Why would I want to to this you may ask, well it would simply produce a better quality ao/lightmap. The reason for that is because my parts are “floating” and crossing each other, they are not connected with planes to one solid mesh . The problem occur when planes are perpendicular, the ray casts misses the infinite thin planes. At least I think that is the problem. You can see the image below the errors that occur with floating parts, the ao is missing.
So when trying to bake lights these problems occur:
I have no uv maps for my high polly models, so the color have to be bakes in to the vertices of my high poly models. But when I’m trying to do a “transfer map” with the diffuse color, to the lowpoly, the program is only sampling from the grey lambert texture and not the vertices.
When I want to export my models to Meshlab or xnormal for a vertex to texture color transfer, the vertices color won’t follow. Neither with fbx or obj file exports.
Xnormal crashes when trying to read an fbx file.
When trying to bake a lightmap directly to the low pollys texture with transfer maps with the highpolly as source, the program often crashes. And on top of that the transfer maps bake light doesn’t seem to support raytrace shadows or lightmaps, only diffuse.
Prelight bake looks horrible because it doesn’t support raytrace shadows, only lightmaps.
I have moves on with the texturing and making a new hud. I hope that I will find a solution for the lightbake problem otherwise I will have use the unity lights. That a waste because I have used large textures for making light bake possible.
My Light that i wish to bake to my textures.
My optimized mesh.
my nicely hacked mesh for baking light to the vertices(hight poly).
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.