GDW- Post Mordem

Post Mortem 

GOOD

Simple

When we were designing the game, we tried to keep the game as simple as possible. The main reason being that we are students, we have other homework to worry about, as well other matters. Also we got ridiculously incompetent people on the game , so keeping the idea we wanted a simple game made things much easier for us.

Realistic

Our team was much more realistic than it was last year, mainly due. This year, we didn’t aim for a ridiculous high concept in our game, such as having a man-bear-pig inside of it or something like that. Like we said in our previous point, we are students and we have other stuff to worry about. Finally we acknowledged our lack of experience in making games, so tried to copy as much as possible. If we were unsure about how a death animation would occur, we dissect how other games do it.

Game play

Our team recognized none of us were knowledgeable of Shaders, so we focused on the one thing our game had, gameplay. We had much play testing from outside sources, to make sure that the game was just the right difficultly. From this we focused on a sense of progression though out the game, where the player will get stronger as they play. As this occurs, the player will face tougher enemies, giving them a sense of accomplishment.

New Found Motivated

Last year our team members were demotivated, but we found a new way to motivate our team Look at video game industry examples, when your team has failed to meet up with your expectations, your team should take a step back and try to see what your team needs to really work on. An example of this is team at Crystal Dynamics which made Lara Croft, when they stepped back from a full price game to a $20 Downloadable game with Lara Croft: Guardian of Light

BAD

Dealing with incompetence

 If anything, we never noticed how incompetent our team mates were earlier, and when we found out how bad they were, it was too late. If anything we should have tested them earlier, before crunch time came to rely on them.  One example is one of our team members made a hard coded menu of 4k lines, and complained all the way. When we noticed his code started giving us errors, he ditched the team, we should have forced him correct his code earlier on.

Last minute

There was still a lot of last minute work done on the game, even though I tried to stray away from it. We managed to stray away from it 1^st semester, with a focus on enemy AI, and gameplay for the last few days. However with this semester, our assets weren’t finished till the end, and implemented till last minute. Even worse, we went ahead with the idea we can upgrade our SFML from version 1.6 to 2.0 within the last week, bad idea.

No enthusiasm

If anything no one was truly pushing the game to its full potential. Sure fatigue, sleepness, and lack to team sprit did contribute, but no one person truly pushed for a specific vision. For example The art style was never really solidified, as no one really pushed for one style. Other design aspects of the game weren’t touched on, such as boss battles, because there was no style to be inspired from.

Hopefully next year we can learn from this experience and not make these mistakes

UOIT Games Con 2013- Is the winner a truely the winner

For this blog, I'm assuming that you guys have been to UOIT's Games Con 2013. Game con was a good event, however it is easily overshadowed by provincial wide game events, such as Level Up. Many interesting games were shown, however majority of them were not finished.

Despite the many awesome games throughout the convention, there could only be one game of the show, Red Dawn. It won 3 awards throughout the show, best 3rd year game, best game-play, and best game of the show. This is a 3rd year competitive multi player game which involved players controlling a pirate ship to destroy other ships. This could be done in a variety of different manners, from explosives cannonballs, to the close range of scorching flames, or even the satisfaction of a well placed mine.

Looks

If anything the game had achieved the look it was aiming for, looking like Zelda: Windwaker
There was a great deal of toon shading in the game, from the ships, to the waves,and even the pretty flames of your burning ship. Little touches such as wind currents, and the cartoony wave effects added to the feel. Also the waves were probably done with some form of GPU based calculations, since they seemed to be interacting with each ship.

WINNER?

In my opinion yes. It deserved all the awards it got, and if anything the team worked hard for them. Sure the concept is simpler than most of the other game, however they still created what they set out to create. A lot , if not most of the games at Games Con failed to do this, which was is a major problem plaguing many game development programs. The fact is the game came through its development, successfully was an achievement on its own.

If anything the question is do we want a nice looking tech demo, or a full fledged playable game? Your answer will decide if you agree with Red Dawn being the winner.

Level Up!

Going to Level up!

Introduction

Last Wednesday (April 3, 2013) took a step forward in our game development carrier and “Leveled up” in our first game convention. Here we went with only 4 member, with 2 dropping out of the program, we were confident when taking a ride to the Go station. Despite the 1 hour ride and early morning, we  were just excited to go to an event such as this. After getting lost, and going in a circle, we finally arrived at the event itself.

Like a roller coaster ride, the setup of the event was a long climb up the hill, for the fast and furious night of level up. Once we were setup, and the event began, we were exposed to a vivid trip of awesomeness. There were games from the colorful wired shooter, to the amazing game using the CryEngine 3, to the base of other musical games. At 5, there was just so much energy in the air as all the games were up and running to be played, or were they...

The good

There was one unity project which surprised me, Rain forest defense, a game which felt truly developed and ready to be sold. This was a tower defense, featuring a defense again robots using plants. Having played many Tower defense games, I noticed their unique selling right away, the game wasn’t 2D but fully 3D. Also with this came interesting game concepts like line of sight, Despite the fact it was made in unity, it still showed great development, though and effort, if anything what I expected of all unity games. 

Most respectful were most of the teams from Humber college, they were the only other university which made a game from scratch. If anything they were the other university which understood our process and pain, while other universities turned a blind eye. Of the 3 games I visited, they had 2 very interesting premade games, both of which being shooters. One was a top down shooter of the old school kind, literally made with sprites and similar animations/ attack patterns. Amazingly this was a side project, one made with XNA, and done in at the same time as their unity game. Another amazing game was one which was made in from XNA but this time was a third person shooter. From a blind eye it’s a generic shooter, but from a game development project, it was a great working project. Even more amazing the project had Retracing used for hit detection against a wave of 50’s zombies. If anything these 2 games put hope back in for the rest of the games.

The unity

There were half built games, lacking core functionality, all made in unity. There were games which needed jumping, but lacked a jumping function. Some games involved filling some sort of meter, which was non-existent in the HUD. Finally some games weren’t play tested correctly as most of them had some way of breaking. For example one game involved throwing paint at a colour less room to find where u were. Even worse, all these games were made in unity, so they had no excuse other laziness to make a properly fleshed out game.

At George brown, I talked to a student who was part of a program called “game design” which was a 1 year program branching off of game development. They had a bunch of interesting I Pad games ready to be played, some of them 1 player, some 2, so I played one while conversing with a developer. I ask him what many questions about his program, and he said they learn all there was to know about making a game. So I asked if they knew about shaders, he couldn’t comprehend what I just asked him. I just thanked him and left after that.   

The bad

 

There was one Cryengine 3 game, which looked very pretty, but that was all that was good about it. The game attracted much people I gave it shot, being immersed in this beautiful world. Giving us a first person view, it was communicating to me I would get a gun, or a weapons or sort, but I didn’t. Unless they were hiding something, like how they were hiding their objectives in the mist, something felt off here. Sure they used an industry standard engine, which looks pretty as hell, but there was a general lack of gameplay present. This made me question how much work they spent on the game, or was it a result of someone just playing around the Cry engine for about an hour. If anything this felt more like a simulation of walking around a mysterious island, rather than an actual game.  

Conclusion

                As a first time, the event was most defiantly an interesting one, if anything an eye opener. It show how few groups truly knew the concept of “game development”, and how luck the few that do are. Next year I hope to see a larger and better event, if anything I want to ask the students more about their games :P.

               

Toon Shading Part 2- Edge detection

In this blog we are talking about toon shading, its uses and how to create it. This is part 2 of my blog about toon shading, this time we are going into edge detection. For part 1 about cel shading click here.

What is edge dection

Edge detection used when we want to outline a specific object in the scene, whether it be for visual appeal or for game play features. The outline is usual a black line around the object, however sometimes it can be different colors depending on its purpose.

Uses of Edge detection

The first use of edge detection is for enhancing the visual appeal/style of the game. This is gives the game a more comic book or Anime/Manga feeling to it if designed right. In the picture above we are seeing edge detection being applied to borderlands from 2K games and Gearbox studios. Edge detection here allows the NPC and gun to stand out from the environment.

The second use of edge detection would be for gameplay uses, where it would indicate to the player of something important. This would literally highlight the object of interest, and inform/warn the player of this object. In this picture, from Left 4 Dead, a Valve game, we are having this highlight to inform the player of other allied players, so we don't shoot them. However L4D goes beyond that and uses the highlighting as in game feed back to tell the status of their allies. Whether they be yellow for being in danger, or red for being low in health, this is an excellent implementation .

How To Use Edge detection

Ask yourself, how do you detect where edges of objects end in real life? Do we say there is an edge when there is a solid change in colour? If we did that to the program it would detect all the changes in colour, and create edges there like in the picture below. Thats not what we want, despite it looking cool :D

To properly do this we need the normals of each object to help us out. For a quick review, normals are a vector that which is can tell the orientation of the object, and commonly used for lighting. Normals are of the the object are the right way to go, as the program can now properly tell where each object ends, and where a new one begins.

However to do edge detection, we also need to use an FBO, click here for my tutorials on FBOs. The reason being we need the scene's normals, however it is more efficient if we use a shader prior edge detection, which will output the normals of all the objects in the scene. We will apply this shader to the full screen quad, which the FBO is being applied to, after rending the scene to the FBO. This makes it a "post processing of the scene" where we apply the edge detection for all the objects.

Hope you learned a thing or 2 from this, this blog took a deal of effort to write. Note doing this to individual objects, like how we did it for the player in L4D, is a totaly different story.

Toon shading Part 1- Cell shading

 Overview

When I say the words "Toon shading, what comes to mind?"
A cartoon / anime series? A game based off this series? If you though of the images below you are correct!

Toon shading is a 2 step process which involves 2 thing Cell shading, and Edge detection

This week I'll focus on how to do Cell Shading, the 1st part.

Cel shading vs normal shading

Normally with "shading" on the object in the scene, the dark shadow on the object will linearly(gradually) increase as the object. As shown below in the graph, as the object's distance from the light decreases on the object.

However with cell shading we want this type of graph.

This will give us "blocks" of shading on the objects due to the fact its broken up or a "piece wise function. To help with this process we would sample from the picture below to give the cel shading its effect.

And- voila, we are done our with our shader, getting the effect to the image below.

For a continuation of toon shading and edge detection, click here. Sorry I couldn't get any deeper into the code, however time is currently of the essence, hopefully you still get the gist of it.