Sunday, 22 November 2009

Famous Five - Development diary #2

Another week has gone by, and the deadline is closer than ever : just about 2 weeks to finish the game off, and an extra week for tweaking and playtesting...

What's new ?

As a matter of fact, quite a lot. I implemented the CSDTalk (dialogue system) into the game, and am really happy with the result, as it contains all the features I needed initially, thus saving me a lot of time and pain designing my own system. Some further modifications were brought to the GUI design in order to make it more appropriate for the game : it is not perfect, but it will do for now.

I also spent some time tweaking my custom components (task manager, QT events/Contextual actions, making them more "Unreal friendly" by allowing the user to easily link them to the existing components and mechanisms provided by the engine, such as events, or triggers, without having to go through an awfull lot of pain of inheriting and speciliazing the classes for each and every behaviour needed.

The mechanics being pretty much completed, I have spend quite a lot of time both on making the final levels, and scripting (see below). The levels consist of two main sections :
  • The hills, with the circus and the Five's camping site. The overall feel I was looking for was a nice warm day, with green fields and plenty of colours (flowers, red tents, etc.), and I am quite happy with the result so far. The major part of the level is done, but I am yet to finish off the circus, and add more variety in terms of objects and textures.
  • The cave, with its dark humid, desaturated environment (in contrast with the first level). This is where the two criminals keep their treasure. This level is actually a lot harder to make than what I would have thought. The thing being : Unreal engine 2 is not really meant for natural environment, and thus it is quite hard to produce a convincing cave without a lot of tweaking and cheating with static meshes and so on. I am not entirely sure of the design of this particular level, however, my aim is to make it into some sort of maze and extend from the original novel.
Finally, I had some fun with scripting, and actually using the components I spent weeks designing and implementing, and I have to say : I am glad I did. In a matter of a few hours, I managed to set up the first few minutes of my game, with a really basic tutorial, dialogues, items, and so on, and it seems to be working without any major glitches.

What's next ?

Considering how little time we have to finish off our project, my focus will be on scripting and making the game fun and interesting.

Although I did plan a few puzzles, I realized after seeing other people's work that my idea of making an interactive story was probably not going to be suitable or be fun enough, and that I need to add in a lot more mini-games or things for the player to do, even though it might defer from the original novel.

This being said, I will be spending quite a lot of time next week actually planning the new mini-games, and reorganizing the game flow to make it more appealing to the player.

In the meantime, I intend to work a bit on some AI, in order to make the game more lifelike, with characters walking around the circus, have a more responsive Timmy the dog, and so on...

I have included a few screenshots of my progress so far to show the scripting in action, as well as the hill level. Enjoy!!


Thursday, 12 November 2009

Famous Five - Development diary #1

Here goes the first development diary for my Famous Five game prototype...

To describe the project in a few words : the game is meant to be a total conversion of Unreal Tournament 2004, starting with a FPS engine, and turning it into a nice adventure game based on one of Enyd Blyton's famous novels.

For this particular assignment, I chose to make a game based on the book "Five go off in a caravan", because of the plot, but also because I quite liked the idea of the circus, and thought it would make an interesting atmosphere.

What have I done so far?

Initially, I went with the idea of making it more like an interactive story, and try and stay true to the original story rather than loosely basing it on the story, with lots of useless irelevant elements as you would find in usual adventure games. This being said, I had to rework my initial game design document in order to make the game more interesting, and thus went on adding secondary objectives, which bring the game closer to its rivals, without ruining the initial plot with meaningless tasks.

I am now on the 7th week of making the game, and it is coming along quite nicely. My emphasis during theses past few weeks was set on designing and implementing the various custom game mechanics into the engine, and linking them up in a comfortable fashion, as well as making it user friendly within the editor. Some of these features include :
  • A task system, which handles all sorts of tasks (collecting objects, talking to people, going somewhere, etc.) in a dynamic way, being easily editable within the editor, as well as extendable if unusual tasks would have to be added.
  • A controller system to handle the Xbox360 controller : although it is quite easy to map buttons and axes of a joystick in Unreal, I felt it did not provide enough control on the state of the input, which is why I went on creating a custom controller system which would handle states (pressed, on press, released and on release), as well as axes in a normalized and more convenient way (it is more convenient to use "LeftStick" than "JoyX" ).
  • An inventory system, coupled with an item system, which define objects that can be carried by the player, and used throughout the game.

What have I worked on this week?

However, this last week, I have spent my time implement my so called "Quick time event system" (although after I think about it "Contextual action system" is a more appropriate term), which makes the interactions within the game by providing the player with a contextual control during actions. Some examples might include tapping buttons to push an object, pressing a combination of buttons mapped onto a specific animation or cutscene to perform certain actions, and so on. This system makes the game more interesting in the way that it is more interactive than pressing a single "use" button to do every single thing, as well as being easier to grasp, being provided with contextual icons which tell the player what to press, and when.

The remaining of my time was spent on minor "bonus" features I had thought of, but not planned for the demo. A particular example of that is post processing filters. Although there are no vertex or pixel shaders in Unreal 2004, it is very easy to fake it by making use of a quad in front of the camera, and mapping it with scriptable textures.

Below is a screenshot of what I was able to achieve in a few hours, showing two post processing filters.

The first one is a fake "depth of field", which is in some way a hack. In fact it was just a matter of rendering the viewport on a small texture, and then stretching it to the screen after having applied an alpha mask to blend it with the normal viewport. As a result of this, you get a simple but nice looking blur effect on the edges, which can be modulated with the size of the texture (the smaller the texture, the more blured the picture gets).

The second filter is a "sepia filter". This effect consists in displaying an animated alpha texture on top of the screen, giving it a slight yellowish tint, as well as grain. The overall result is quite convincing, however, it was not exactly what I intended to have, and will require some more work. What I was aiming for, was a picture similar to what you got in movies in the 50's, with a slightly desaturated picture, and lots of noise and irregularities on the picture.

This is it for this week, but more is to come in the following week!!

What next ?

I am just one step from finishing the core mechanics, meaning that as for next week, I should be able to start building the final level, and sticking all the assets, as well as scripting the game using my custom system. As a matter of fact the last remaining component to be added, is the dialogue system, which will support dialogue trees. This system should be heavily based on the existing CSD talk system, meaning this particular element should not be taking to much time to implement. This being done, as said above, I will move on to building the actual game, and coding the various items, and behaviours as I go along, as well as making extra required assets.

As a little treat, here is a little comparison shot of the default display, and the post-processed display. Note that this does not represent the filters that well, as it does not show the animation and motion of the screen which contributes to amplify the effects.

Sunday, 25 October 2009

Biosphere - Personal project


This entry might not be very relevant to any of our university work, however, I though it would be a good idea to show what I was up to during my spare time, and maybe get some feedback.

As the title states it, this post is about my ongoing personal project (one of the many unachieved-projects I have been working on for the past few years), which I have called "Biosphere". Initially, the idea came from the 1st year Game Design module, when we had to design a cooperative game, and start brainstorming for a couple of ideas. Although this particular one did not get through, I kept it aside in my mind for the following weeks, until the holidays came.

From there, and with plenty of free time on my hands (although not so much when I started working on the side), I decided to start working on it, with the idea of making it both a good exercise (improving my programming/design skills, writing various documents, etc), as well as having something not necessarily related to uni, which I could put in my port folio, and demonstrate my motivation in working in the games industry.

Biosphere is a 2D space colonization game, made in C++, which I am designing with an emphasis on architecture, modularity (having modular renderers, input systems, etc...) and reusability (the game is just a demonstration product for my engine).

Considering the small amount of uni work we are getting right now ( although some people might feel different about it), I am able to move on with my project pretty quickly, and I am quite happy with the result I am having for the moment. I do not know how it will go from there, priority being for uni work, but I will try and keep working on it as much as possible.

Anyway, for those of you who are still interested, here is the link to a blog I have set up especially for this project a couple of months ago. The blog depicts the game, contains hand-made artwork, and also has development diaries describing my progress, and the features to come. Feel free to leave comments, questions, and/or critics, that is what it is there for!!

Tuesday, 13 October 2009

Console Dev - Week 2 - Machine Cycle

The original Xbox's ISA

Because the Xbox uses an Intel Pentium III processor, its ISA is not very different from what is generally found in computers. The CPU uses the x86 instruction set, which is described in detail in the following link :

x86 instruction listing (Wiki)

The corresponding disassembly code can be obtained using the free software IDA Pro Freeware v4.3 or Ollydbg. However, not having managed to read an original Xbox cd successfully with a computer dvd-rom (Xbox cds are read from the outside->in, whereas normal dvd-rom read from the inside->out), here is a sample code of a strlen function written in x86 assembly code, found on the internet, with added comments to explain what I believe is going on, based on the code, the registers and the instruction set:


section .text
global my_strlen
my_strlen:
push ebp
//pushes the data onto the ebp register ( stack base pointer for current frame )

mov ebp, esp //moves the data from esp (stack base pointer for top frame) into ebp
push ebx //pushes the data onto the base register
push ecx //pushes the data onto the counter register

mov ebx, [ebp+8] //moves the data in the ebp register at location 8 (8 bits?) onto the base register
mov ecx, 0 //sets the counter to zero

.L1:
mov eax, [ebx]
//put the adress of the base register into the accumulator
cmp byte [ebx], 0 //compares the single byte in ebx with zero (checks whether the character is empty or not?)
jz .L2 //"jump on zero", meaning if the comparison is false, go to L2...

inc ebx //otherwise, increment the base register by 1 (go to next character ?)
inc ecx //increment the counter by 1 (one more character in the string)
jmp .L1 //go back to L1 and repeat
.L2:
dec ecx
//decrements the counter by one (correction)
mov eax, ecx //put the result into the accumulator

pop ecx //pop data from the counter (reset it ?)

leave
ret

The code above is not perfect, but it allows us to see how the x86 instructions work, and how the various registers are used. The same principle is also applied, in a much larger scale that is, with the Xbox, with the added compiled C/C++ files on top of the low level assembly code, which then makes it able to run games...

Other sources :

http://www.geocities.com/thestarman3/asm/ - Additional resources for x86 code

http://www.linuxforums.org/forum/linux-programming-scripting/76566-x86-assembly-strlen-implementation.html - Original strlen x86 code

http://en.wikipedia.org/wiki/X86 - more information on x86 concerning registers, etc.