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.

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 27^th 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.

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 27^th of May when we are to show the game at Gotland Game Conference.