Student Project II - Making the Level more pretty

After the last milestone we desided to change the storage area a bit and to add blood decals as well as some corpses. The corpse models are taken from Gears of War but we have no intentions to publish the game or even make money with it, so it is okay to use some models that could be used in non-commercial projects.

Before:

This is a screen shot before the rearranging of boxes and adding of gore.

After:

The first view of the new arrangement

A view back to the entrance with the big hangar door that is rusted shut

Blood spatters in the floor and the exit barely visible in the distance

A view of the exit and the carnage in front of it.

Some blood and a destroyed lamp.

The last stand from another angle.

The last stand position and the aftermath.

Gore and blood splatter on boxes and shipping containers.

The entrance of the area with new lamp and shipping containers.

The last stand position with a lot of blood and gore.

As you can see, it looks more like a battle took place as the empty hall before. According to the story, all the security troops died or mutated so there have to be mutilated corpses, blood and bullet holes all around. It adds a lot to the atmosphere of the game and there are even some destroyed lamps that shoot sparks in many directions. Speaking of sparks, I started working with Unreal Cascade, the particle system editor in the UDK, and created some particle systems including sparks, floating dust and some puffs of smoke. It is an interesting tool to work with and offers many different options to play around with. I will post some screens of cool particle effects in the future.

Links for UDK

As I said in an earlier post here are some links to tutorials and useful information regarding the UDK:

http://wdksoftware.nl/UDK/

http://www.chrisalbeluhn.com

http://www.polycount.com/forum/showthread.php?t=90931

http://www.unrealmaster.com/tutorials/

http://phill.inksworth.com/tut.php

http://www.youtube.com/user/lorendroll?feature=watch

http://chrisholden.net/tutor/tutors.htm

http://www.moddb.com/groups/udk-developers-group/tutorials
http://www.hourences.com/tutorials/
http://awforsythe.com/405/?p=144
http://www.youtube.com/watch?v=ROkHmMEWHU8
http://udn.epicgames.com/Three/LevelStreamingHowTo.html

These are some of the tutorials I watched in the last weeks, maybe someone else finds them useful as well.

Student Project II - Background Story and Progress Report

The project is well under way and we have our second milestone in a few days.

The name is Helios and the background story is of a virus outbreak in a futuristic research facility.

The facility is owned by a paramilitary organization that does weapons research for the highest bidder. One of the experiments backfires and in a section of the facility a researcher is accidentally infected by a virus becoming patient zero. The mutated virus spreads quickly among the workers and they are turned into mindless monsters that attack everything in sight. The facilities security troops try to contain the situation but are defenceless against the virus.

The organization creates a soldier that is immune to the virus and sends him inside the facility to assess the situation and find some way to counteract the virus. The player takes up the role of said soldier and has to complete some objectives inside the facility.

The facility consists of three "rooms" connected by small hallways. The first room is a storage area filled with crates and shipping containers. The second room or set of rooms is a mix of laboratories and office space. The third and last room is the reactor or generator room.

A kind of theme is the conflict of fire and ice, the virus is fuelled by heat and the player's weapons shoot a kind of coolant that freezes the infected so they are easier to destroy.

Here are some screen shots of the progress so far:

It is one of the hallways connecting the rooms. Our HUD is mostly finished and the camera follows the player as it should do. The hallway is mostly empty at the moment but will be filled with crates and signs of fighting and destruction. All the assets apart from the UDK-robot are our own.

Here we have the storage area where monsters could lurk behind every corner. The big boxes are not final yet and it is also far to clean.

This is a look back into the second hallway (after the storage area) just before entering the laboratories.

This is the second block-out for the laboratories still with checker board textures and without much to see actually. The layout was changed just some days ago, so everything has to be rearranged. The stairs on the right lead to the office area and something like a cafeteria but the door are not ready yet and there is nothing there to see for now.

A screen shot of the generator room will follow soon.

Most of the progress is not visible in screen shots and the levels are unfortunately far from finished but there is still time.

So long.

Student Project II - Introduction

The second semester at the Games Academy has just started and I am in a new team with not just game designers but artists, programmers and a producer, which is a different feeling than the first project where all members were game designers. The teams are bigger now (up to 10 people), so the need for a producer is higher than before though without one problems will arise even in a team of five.

We will work on a third-person shooter in the Unreal Engine 3. For ease of work we will use the UDK and try to use as much of our own assets as we manage and than use some UDK-Assets for dressing it up a bit better.

I will not give much more details about the game for now because I have to check with the rest of the team but I will post some links to tutorials or tips on working with the UDK in later posts. For now I will share a link to a blog we started during a scripting class on Unreal Script, unfortunately it is mostly in German but the links on it are in English so it won't be too hard to understand.

If I get the OK, I will post more info on the project but as said, it is not my decision...

Development Blog: The Magic of Innocence - Reacquainting myself with the Toolset

The last update was on the 31th of march and I had a lot of other work to do that prevented me from working on the mod. Since then I have also learned a lot about game design and I will try to find a way to implement what I learned into the mod making it better and more interesting.

First there were some bugs in it that I will try to fix and then I will work on the next part of the story and the implementation of it but after so long I have to reacquaint myself again with the Toolset and the needed tutorials for companions and custom classes.

I am not making any promises to finish anything soon but I will work on it nevertheless.

Student Project - Post Mortem

It is about a month after the completion of the first student project for the Games Academy. I had some time to think about the whole process and have to say that even on a team with five people work can be hard to coordinate. We had no producer in our team who would try to keep the team together and the project on track and we had no one to try to do that job and the result was that we changed the engine without checking the new one and just because some team members thought that some features were not to their liking. The engine switch resulted in a massive crunch time and some small sparks flying but fortunately we could work out a way to finish a playable version and there were only small difficulties between some team members. They will not work together again but they are not trying to kill each other.

The project itself is playable but not bug free (just like some rushed commercial titles) so we are not really disappointed with it but with better management we could have delivered a better game with all the features we had planned to implement and also without bugs.

It was the first  student project I worked on and even though not everything went according to plan I have learned a lot. In an earlier post I said the the first project is doomed to fail but that was just some students in higher semesters trying to ease our minds. As a matter of fact it was mostly about the teamwork and learning to keep a schedule than really delivering a great game. We managed just that and are content if not happy with it.

In the previous two posts I talked about engines for 2D games and after having worked with Torque2D I have to say that it was a bad decision to switch to it because there are some kinks (or bugs) in the engine that are not really fixed and the whole documentation was outdated and in some cases just wrong. So working with it was mostly tapping in the dark and hoping to find the right command and that the engine logic was compatible to my own. After some research I found out that Torque2D had no real support anymore and that there were two different 2D engine based on the Torque engine and we did choose the wrong one. The other one uses XLA and therefore has a lot of tutorials and is up-to-date but using c# is a little bit more complicated than TorqueScript because it is much more powerful and more object-oriented which could have been a problem for the second programmer (not sure though).

The biggest problem was and always will be communication between the team members. Not just the coordination of work but smaller day-to-day problems that could ruin the working relationship in the long run.

As a conclusion I could say that the next project will be better and that I will not make the same mistakes as before but I have to be realistic and just try to do a better job next time and if something is amiss I will talk to my new teammates...

2D Engines or 3D Engines for 2D Projects

After spending some time with the development of a 2D game for PC or maybe other platforms I had time to test out some engines that we have access to for free at home or with student licences in school.

For rapid prototyping the Game Maker is the first choice but it has problems with complex mechanics and collusion detection.

Working with Sprites and only 2D objects makes the use of an engine like Unity3D or even the UDK more tedious than helpful because these engines are designed for 3D gameplay and 3D meshes. To tell them otherwise via code is a lot of work and the result is not always desirable. 2.5D on the other hand is more easy to accomplish because the engine already knows how to handle 3D meshes and the "2D gameplay" is possible with some camera tricks.

Using an 2D engine like Torque2D is the better choice for Sprites, 2D objects and 2D gameplay. I am just starting to work with it so I will hold my praises for the moment, maybe it is easy, maybe not...

As for scripting languages most engines today use some kind of c++ related syntax and operators so the switch between different engines is not so difficult, in some cases the code is even transferable between them if not too much engine specific code is being used.

Student Project - Engines a Plenty

And another game engine to learn and to master...

After having some trouble with imprecise collision detection and too much hassle with gravity on jump mechanics we decided to change the game engine for our student project. Previously we used Unity3D but it being an 3D engine and we wanting to make a 2D game resulted in a lot of headache for all of us but mostly me 'cause I had to tame the beast and failed miserably.

In the beginning of the planning phase there was the option to use the Game Maker but we decided against it because it could produce nice prototypes but making good games with it seemed impossible. A better engine had to do the job. Unfortunately, I decided that Unity would be a good alternative and we ran with it as long as we could before realizing that it was too much for us beginners.

One of our teachers mention another engine that we could use that is more powerful than the Game Maker but not a 3D engine that needs too much fixing. He was talking about Torque2D. So we now try our luck with that engine.

My preliminary tests show that the engine is capable of providing the mechanics we want and that it is manageable to change the engine at our current development stage.

All the artwork has to be resized anyway so the conversion in file type that is needed is not that much of a problem. The scripts have to be rewritten with the new engine code in mind but there were just about 50 lines of code combined so no problem there as well.

Student Project - Progress Report and some Disillusion towards small Projects

The project is deep in production and we are experiencing some difficulties I thought would be avoidable in a project that small and with so few people involved.

Being almost the only one with programming experience was clear for me from the beginning but the amount of work I have to do to get some "simple" mechanics to work properly has me overwhelmed and stumbling at times. Fortunately there is another team member with programming skills that helped out at these times and I could take a step back and reassess the situation.

Another disillusion I experienced was the fact that even in a team with five people work can stagnate and a good "leadership" is needed. I put leadership in parenthesis because it is more the internal communication the team lead lacks as the skill to lead others in the right direction or the right goal. We are all just students at a game design school and we don't know any better. Some students in higher semesters said the first project is doomed to fail and the failure serves as a learning experience for future projects. We joked about it and tried to optimize the concept to avoid any pitfalls and make it a game that we can actually make in the given time frame but with all the courses and now even some exams we somehow lost track of our schedule and have fallen behind. I took too much time to research features of Unity and other interesting aspects of game development.

The idea or vision of our game is clear to everyone but there is no additional game design that everyone knows and that is constantly updated to see the real progress we made so far.

Our project is still a work in progress and I don't know how far we are with the other aspects like level design or graphics because I just lost track of the overall progress but most of the core features on the scripting side are implemented and need to be tested, tweaked and finalized for me to move on to other aspects of the game that need some coding.

The Need to Change my Expectations towards Unity

After working with Unity and trying to implement the core features of the game project I am working on, I have to change my previous statement that Unity is comfortable and easy to work with to an extend.

When I first imported the graphics provided by our artist he noticed that they looked rather bland and there were some lines that he was sure were not in the original files. The files were Photoshop CS 2 files and the importer inside Unity had some problems with them. After some tweaking the colours could be corrected but not the lines, maybe there is an image format that we could use that is imported correctly into Unity but as we are not working with the final graphics too much tweaking would be just a waste of time.

Another aspect of Unity that bugs me a lot is the movement of objects by script. Simple movement in one axis posses no threat at all and is easily implemented but creating a jump, that looks good in 2D and is at the same time "physics confirm" meaning it feels right in the given environment, seemed almost impossible at first and without using a set of external scripts. These scripts are included as a standard package with Unity but I wanted to avoid using scripts that provide functionality that is not needed for the project. Unfortunately it was only possible to achieve a suitable jump movement by using said scripts and add my movement scripts on top of them.

As a conclusion I was to hasty to praise Unity as I did but I learned a lot in the process and will test more before jumping on someone's "band wagon" in the future.