Tuesday, April 12, 2011

Change of direction

With recent changes in the project the need for code has greatly decreased. Decreased to the point of non-existence actually. This makes my role as single programmer for this project somewhat abundant and I will instead focus on game design, layout, production and other menial tasks. I have also taken full control of the Carnage project-blog, which means all my activity will continue over there. The link is just to the right, please dare make the jump over there. I will see you on the other side.

Oh, and this one? It will stay hibernated for a while until I can decide what to do with it. Most like, there will be other personal design-work unrelated to Carnage on here. Just not yet. Later. Perhaps.

Friday, April 8, 2011

At the crossroads

Joy. Progress made. I have successfully extended some of the classes needed for Carnage. Focus has been on creating functioning pawns with a proper (temporary) mesh along with movement and some very basic game-rules.


Above is an in-game image showing a simple track used for testing code. The individual tiles can be seen as separated by the dark lines. The cars are un-textured meshes that are still being worked on and the text seen is used to debug, along with an editor-log not shown with a lot more detailed info. At the moment of this image I am testing out the navigation using track-nodes.



The small grey icons placed on the track are track nodes. These are used by the cars to navigate around the track, checking where to go, how fast and if other cars are currently occupying a node. The rules of Carnage allow two cars occupying each tile at the end of each turn. With four cars racing we need a system checking if the tile the car will move to is currently occupied, by whom and if it is the destination of the moving car who to ram out of the way to the next tile. I figured this could be done with a system of navigation nodes placed on the track. Each car stores info about what node they are placed on and uses that combined with current speed (decided by inputs from the player during action-phase) to decide where to go next. It works fine as a stand-alone and it should not be any issues connecting this to the player input/main game info.

The amount of work to be done is huge and what worries me most is that I cannot set up a reliable time-plan as I would need to do a lot more research and gain more experience in UDK for it to be even close to realistic. This creates a risk of the project not functioning fully or even lacking vital features at deadline. The often used option of delaying the presentation of this game is non-existent as our deadline is set in solid stone, with the 27th of May as the date of Gotland Game Conference. Cutting features is a valid option but downsizing the game too much will create a less than impressive (and most important, less fun) product. Just going along with it and hoping for the best is insanity as we would then risk having nothing at all to show.

We need to sit down as a group, re-evaluate the risks and rewards of the project and see what is to be done.

Friday, April 1, 2011

Unraveling UDK

Since last post I have been focusing on the UDK and its scripting language UnrealScript. We will not touch the native C++-code running the low-level engines as it is far too complex for me to mess about with alone for such a short project. UnrealScript runs on top of the C++-code and handles most of the gameplay, being based heavily on classes and inheritance. As it is originally built for Unreal Tournament 3 it can be modified to pretty much any sort of first-person shooting game without too much trouble. While you can create basically any sort of game in UDK the more you diverge from the action-shooter the more tinkering needs to be done and it becomes increasingly complex to handle the inheritance-structure.

Since our game is a turn-based strategy game with multiple player-input I will need to decide what parts of the original class-structure we need to use and where to branch off. Things like camera-positioning, actor-creation and placing pawns can most likely be implemented without too much trouble. Adapting the input/player controller and setting up the main game-class to run in game-loops and ignore the event-based setup normally used in games created in UDK will be trickier. As it is we will not be needing complex physics and can probably skip that part completely.

Not researched yet is interface, cut-scenes and sound-management. Ideally I would like to implement networking as well, enabling each player to run a copy of the game and still play together instead of the arcade setup we got going now. A simple AI would also be useful so players don’t need to find three living and breathing opponents for a quick game. As expected there is a long list of features we would like to have in the game but being realistic we will not be able to implement them all to the 27th of May when we are to show the game at Gotland Game Conference.

Thursday, March 24, 2011

A project born

Hello. The intent of this one-way conversation is to give you an insight to my work, thought process and reflections thereof. My name is Joakim Andreasson and I am currently studying Game Design at Gotland University. I am the member of a team of students taking a course focused on game production. My team consists of me(the programmer), three graphic-guys and a producer keeping us in line.

We are working on a project called Carnage. In short, this can be described as a turn-based, fast-paced strategy-game involving cars, explosions and the civilized taunting of opponents. Having the words turn-based and fast-paced describe the same game is perhaps somewhat unexpected but we do feel like it sums up our game pretty well. In this space I will mostly cover my individual work, for more info about Carnage in general you can visit the projects development-diary (www.CarnageTheGame.com).

I have been assigned the role of Lead Programmer in this project. As I am the only programmer in our group this seems like the natural step. Before project-start we sat down and looked at the strengths of our group, the unique points in our concept and what options were available to us. As the Carnage-concept can be adapted for pretty much any game medium it gave us quite a few possible directions regarding the form of the game. The art-people were all very interested in exploring 3D further so that became our main focus. Because of this me and Lead Art, Christoffer Akterin (http://christofferakterin.blogspot.com), sat down and looked at possible 3D game-engines we could use for the project. The first option explored was the Unity 3-engine. I did some basic work with it on my off-time and was somewhat pleased with the results. However, while this looked like quite the powerful tool we soon switched our attention over to the Unreal Engine 3. The main reason for this was that the courses we studied during this time gave us the opportunity to work in UDK (Unreal Development Kit) as part of an assignment. I had no objections as documentation for the Unreal Engine 3 and UDK seemed to be somewhat more accessible than that for Unity 3 and having no previous experience with either engine I had no preset preference. UDK it is then.

This leads up to present day. The project will start in earnest a couple of days from now and it looks to be quite the challenge considering our very small development team. My major task the first weeks is doing research on how to actually translate our game from concept to code in UDK. I hope you will tolerate my mad ramblings and keep an eye on the progress made.