Game Ideas 01: First Person Exploration Adventure - Phaeton

First of all, I thought about writing up some of my ideas for games that I might develop some day or just use them as a basis for new ideas.

The idea of a first person exploration adventure was poking around my head for some time now because I think it would be a game that I would play the hell out of... but as someone who just finished a game design course at a game design school here, I know that designing a game for myself is not something I should do from a game designer's point of view. As a game designer I should be looking at a game idea that could sell and that has a huge target group. Sorry but I don't like the idea of just designing games that sell and that are fashioned for the masses. The problem with these kind of games is that they are not really innovative but build on too many proven concepts to be original. I think that these games and that approach of designing games are wrong and smother innovation in the field of games. The idea of going indie is not so appealing either because more and more indie developer think of making games as art and design something that is either nice to look at but without any gameplay or that is so simple that it is fun for a few moments and boring in the long run. But enough with the ranting about the state of games at the moment...

Ok, back to the idea part: What is a first person exploration adventure?
It is a game not unlike a RPG but without all the character stuff, the classes and the micromanagement. The player has all the freedom to do what he/she wants without sticking to a predetermined play style. There are games out there that give that experience to a point. One of them is Minecraft which give an ever expending world and a small set of tools to the player with which he can do whatever he wants. A problem with Minecraft is the lack of goal and lack of guidance that many players want for their games but as an free-form exploration game Minecraft shines like no other. Another game that could fit the "genre" is Amnesia but my experience with it is limited so I am not so sure about it. Apart from that is the setting that is not one I would prefer as I am no fan of survival horror or any kind of horror for that matter. To clarify the "genre" a bit, I thought about the old Myst games and changed the puzzles to be more "in-game" than just some "mini games" like you can see in most action adventures nowadays, write a story that is a background and part of the game as well and have a goal that the player can see but reach in his own time. So in conclusion it would be a game where the player character walks around a set of areas, finds clues to proceed to new areas, solves puzzles and experiences an engaging story without shooting or killing anything.

And what is the difference to an action adventure?
Well, first off, it is in first person because the first person perspective is as far as I'm concerned the perspective with the best immersion in the game world.Second, the emphasise is on exploration and not on killing stuff or doing mind blowing acrobatics in split seconds. There is no time limit and nothing that pushes the player to rush through the game world. Everything inside the game areas could be a hint to proceed further so the player has to have enough time to have a thorough look around.Another difference is the fact that the story is one of the most important parts of the game.I already mentioned Myst as an example but thing of more free movement and the chance to alter the story by being able to choose different paths to solve a puzzle and having that choice influence the story (that's why I mentioned RPGs as an example because most modern rpgs advertise with this feature). So much for the "genre".

The title says "Phaeton", so let me explain what Phaeton is.
It is a Science Fiction world some friends and I created as a world for pen & paper role playing. It uses our galaxy but in about 4500 years, so a lot of things changed in that time and mankind noticed that they are indeed not alone in the universe and that there are a lot of other species out there. One of these species are the Raccequa, a kind of amphibian that needs a lot of water to survive, which enslaved most of the galaxy and ruled over them for about 2000 years. The massive expansion and internal struggles lead to the fall of the ruling caste and to a rebellion that freed most species resulting in the formation of an intergalactic union which brought equality and temporary peace to the galaxy.

The background story for the game is:
The player character is a mix between a smuggler, a private investigator and security guard who owns a small ship and preforms odd jobs to get by. One day he picks up a distress call and find a large cruiser drifting through space near an asteroid belt. Driven by curiosity and the distress call he docks and gets on board the larger vessel, just to find that the reactor seems off-line and no life signs could be detected aboard. From his point of entry he starts his investigation into the whereabouts of the crew and the distress call. By looking around for clues and reading diary entries he finds in crew quarters he can find what happened on the ship and proceed to the bridge to find the source of the distress call.

Much more I will not reveal by now because I am willing to make that game someday and telling the whole story here would spoil too much...

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.

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

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