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.
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).
…are all important questions that you ask yourself before entering another exciting and action-packed ImpactO match. Yesterday the team had some great fights among each other that we would like to share by showing you this video.
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 🙂
It’s been a long time since last I posted anything and I apologize.
The main theme of the team’s blog posts the past weeks has been “killing your darlings”, and unfortunately I cannot break that theme.
Since I established that I was behind schedule in my last blog post I’ve tried to up my effort by putting in extra hours, making free time non-existent. But longer hours doesn’t always mean more progress, especially if you are cutting down on sleep and exercise. The stressful schedule made me forget to take care of myself which resulted in me coming down with the flu.
Thanks to a Teamviewer connection between my school and home computer I’ve had a way to work from home, but I’ve mostly spent the last few days recuperating.
I got back to work today (not fully recovered yet) and I’m now refining my pressing time schedule which has now gone over to the Texturing phase. Most of my models are UV mapped at this moment and several test bakes have been done, but there is still a lot of tweaking to be done.
These unfortunate events have put more assets on the wishlist and with a little less than 2 weeks to go I’m now focusing all my remaining time on those assets that are of highest priority.
Well… it has been a long time since we last posted an entry in the “video of the week” section. The reasons might be plenty, however some reasons might be very tight schedule and the fact that we wanted to have a good-looking robot controller before the next video. Anyways, here you are. Sit tight and enjoy! 🙂
The music included in the video is composed by Emil Hedemalm and is not a work created by Team ImpactO
Estimate time is always hard, especially when it comes to cg, new problems often occur and smaller tasks are forgotten when planing. A teacher once told me a mathematical solution for planing. Take the estimated time and multiply it by pi and you will get closer to the truth. I guess that is correct, think of uv mapping for example, simple objects can turn pretty complex. Its even harder when Maya has a bug not showing the right normal direction after duplicating an object. It took a while to figure out why my baked maps looked bad. The solution was to combine and split meshes.
The GUI has taken shape, and a new logo. It can be hard to keep stuff minimalistic and clean but i think i succeeded. It makes a good contrast with the messy 3d background. The menu will be 2.5 which will give some cool parallax.The blue glows bleeds over the surrounding buttons which is a problem for the raycast when pressing the buttons. the solution was making small invisible hit-boxes, so u don’t hit multiple buttons at the same time.
One map baked, i just wanted to show the render time , my computer seams to be slower then the rest, ancient dual core…
“When you understand something, then you can find the math to express that understanding. The math doesn’t provide the understanding.” – Lamport
Lately I have been working with analyzing different ways to calculate, update and track user skill depending on different pre and post parameters. The first question I asked myself was: what is actually player skill? This might seem like a question with only one answer, but if you think about it you will soon notice that you can twist it in many different ways; e.g. is the player that helps the team (true sportsmanship) the best player, or is it the single player with most kills that should earn that title? As I have been working and studying a lot in the area of game design I soon realized that the number of answers to this question is a function that depends on the complexity for the game. That is, in a game like chess the answer to the question might be trivial and depends only on the winning and losing condition of the particular match.
During my research I came across the TrueSkill algorithm, which is a skill based ranking system for Xbox Live developed at Microsoft Research. For long (far too long in my opinion) the Elo ranking system has been widely used and modified for different kinds of games and today many refer to the word “Elo” when talking about how skilled and experienced they are. However, the Elo system comes with many flaws, such as not taking team composition into account (and you already know that teams are a big part of our game).
So, what is the TrueSkill algorithm and how does it work? Well, to put it really really simple it takes two different factors into consideration:
The mean (average) value which is often represented by the Greek letter μ (mu)
The standard deviation, represented by the Greek letter σ (sigma). This indicates the systems uncertainty of the player.
If a player got a high sigma this means that the system is unsure about that particular player and in the same way a low sigma means that the system is pretty safe about the players skill level. This means that a player with high mu and high sigma isn’t certainly going to be merged with other players with high skill, but instead depends on the conservative skill value that is a composition of both the player’s mu and sigma value.
These two diagrams illustrate two players:
Eric with a pretty high μ and low σ (the system is sure about this player)
Natalia with a quite the same μ but much higher σ than Eric.
After Natalia won the match we see that Eric’s skill curve remains almost the same but Natalia’s curve has been both narrower and taller, which means that the system has been surer about the skill of Natalia.