Showing posts with label UDK. Show all posts
Showing posts with label UDK. Show all posts

Wednesday, 14 March 2012

The Toils of Everyday Life

My last post is sadly more than a month old and I have not had the time to post anything until now. Much has changed and some things are still the same as ever.

First of all the second semester at the Games Academy is finished, the second game design project handed in and now I have about two or three weeks just for myself. The project was better received as the first one but there were some problems that could have prevented us from handing in a working game,  fortunately we had a working build from the night before. The problems were the results of sleep deprivation during crunch time. I was working on finishing up the path finding in the UDK and must have deleted a vertex of a blocking volume. The result was that the player start was not working any more and the game did not even start properly after that. It was not really my fault having worked three days in a row with only about two hours of sleep, so we couldn't show the very last version of the game but the reception was good nonetheless. Making mistakes like that could have been prevented with some better planing and coordination throughout the whole project but that is something we all had to learn.

Another thing that changed is the level design assignment but it was not finished in a way that I could hand it in. The UDK killed my work of about a week one day before deadline and as a result I could not make the required screen shots and decided to not hand in anything at all which brings me to the things that did not change at all in the last year. I am still not able to keep a schedule for more than three days and I am easily distracted by unimportant things like new episodes of TV series I follow or a game I have not played to the point where I could do it in my sleep. As the second semester progressed my class attendance decreased and my "sick days" increased. It was harder to get up in the morning and easier to skip a class or two. It might sound like another case of ADD but there are things that I can do for hours without any problems but these are things that I chose myself and that I consider fun i.e. there is my Minecraft server that I can play on, forget the world outside and just relax. Maybe I have to contact a psychologist and ask what my problem could be.

Making plans for the next semester seams kind of futile because I know that I will not put the required work into the preparations as is needed for presenting a game concept of my own. As the next semester is the start of my three semester programming course I might fresh up my programming skills a bit and try working through some tutorials on the net.

In past posts I promised some updates on various topics but as far as I can see at the moment I will not post updates for those posts and I will try to not promise things that I cannot deliver in the future... which does not mean that this blog is dead it simply means that I will keep my irregular updates as before whenever I have both the time and the energy to post anything.

Tuesday, 7 February 2012

Student Project II - Some Small Update

In the last post regarding the project I stated that we used some assets from Gears of War but after putting them inside the level we were unable to create a working game build any more. We looked over every aspect of the game that had changed alongside the "new" assets but could not find anything wrong that would indicate a solution to the problem. We asked around other students and even some teachers until one of the teachers looked at our packages and noticed the Gears of War packages. He suggested removing the GoW assets and try building again. It worked!

Even if the editor is able to use packages from licensed games the game build might not work with them. He even said that packages saved with other versions of the UDK might not work properly or cause problems so we have to create new packages if we would change the UDK version.

As a result, we have no corpses in the level at the moment and the artists had to create their own sand sack barriers. Maybe we will use parts of our character or creature models as corpses later on...

Another aspect that changed is the HUD, it now only contains the cross hair and the ammunition indicator. Some text for the objectives will be implemented in the next few days and after that the HUD will be final and only the level lighting and the character model implementation (the model itself is finished and has most of its animations already) has to be done before the final polish.

Level Design 01 - Dragon Hunter's Camp - Introduction

Apart from the project, classes continue as the second semester progresses and one of them was quite interesting, Level Design. In the first semester we had a level design class but it was mostly theory and quest design basics. It was OK but not as engaging as the new class where we have to design a region in a land we created in small groups. The cool part is that we have to build an map in the UDK that fits into that region. The result is to be a detailed description of the region and some screen-shots that show the level at its best but I also want to build a playable level that we can later combine into a small game spanning the all the levels my team mates and me build. The task was given to us a week ago and we have until the 15th of march to finish our work so we have a little bit over a month in all for the whole task.

The group I worked with consisted of four students and we chose a world one of my fellow students envisioned for a fantasy book he is writing. His story plays in a vast desert area in the south of the continent so we tried to split the hero's journey into four parts so that each of us can design a specific part of that journey. Unfortunately, designing four desert levels and writing about the same region four times was not what the teacher or even we wanted so we just took the world and each of us chose a different region to define and build a level in. I started working on a desert road along an oasis but quickly realized that building a level there would be either boring (a vast empty desert plain with a small green spot around some watering hole) or even impractical as a functional level (because the player would see the end of the level without something blocking his view and what could block the view in a desert plain?!) so I decided to take another region far in the north with mountains and thick forests (a lot of things that can block the view and movement of the player). There is one particular range of mountains that was catching my eye, one with a population of dragons and dragon hunters nearby.

My own goal now is to design a level with mountains, forests, a small village and a dragon hunter's camp inside a crevice or some caves. The village and the camp has to be protected from dragon attacks and there should be dragon traps and defence and scout positions along the mountains.
Since I am no artist I will use as much of the original UDK assets as possible and try to find some free models on the internet to help me out. Maybe I will even try to build some simple assets by myself...

The UDK was a complete mystery to me at the beginning of the last semester and I had only little time on weekends to test out some of the features it provides so it will be quite a challenge to build a whole level by myself and make it look good enough for a descend mark. Working with it for the game design project is a huge help but for example the terrain editor was totally new to me.

All in all I will try to post updates as often as possible...

Thursday, 26 January 2012

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.

Wednesday, 11 January 2012

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.

Wednesday, 9 November 2011

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...

Sunday, 12 June 2011

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.

Sunday, 17 April 2011

UDK vs. Unity and Unity Tutorials

In my previous post I mentioned the fact that I work on a project that uses the Unity Engine and that there are many good tutorials out there, so here are some of them:
 Unity is a toolkit that is powerful yet easy to learn, so everyone who wants to create his own game someday could have a good start with Unity.

Ok, I might sound like an advertisement, but I was surprised myself after having worked with the UDK and failing miserably in getting something other than a 3D Shooter in the end. The UDK is designed for 3D games with high end graphics(textures, shaders etc.). It is possible to create other types of games with it but most mechanics have to be changed or implemented from scratch. Unity on the other hand is more free form with more focus on portability to different gaming platforms than the UDK. The graphics may not be high end but are not outdated either. So designing games with one engine or the other depends on the designer's focus and the style of game play he prefers.