Week 13 & 14 (10 & 11th week of work):

Upon my return to Newport, I quickly set to work finishing off the new texture for the enemy model, using the grain filter at varying settings to simulate the mottled look of the fabrics on the character, as well as painting highlights onto the visor and plastic components:

A Comparison of the “materialess” texture to the one with materials added. The most visible applications of materials on the green segments, the visor, and the plastic armour segments.

Admittedly, this week onward saw a reduction in time I devoted to the project. Most of the content that had or could be prepared by the designers had been completed, and what work was left was programming tasks. Also, my time on the project and fixing the problems I had encountered had been at the cost of other commitments that needed to be caught up on. I regret not being able to help our programmers out more, but the programming they are working on is beyond my scope of understanding.

I made the final few animations for the enemy (including a “working” animation Lloyd requested for when the enemies were working at the consoles on the airships). It was during this time however, that I discovered some fundamental flaws in the designs (namely an error setting up controls on one arm, and an inability to twist the hands of the character, which meant I could not turn the fingers to be properly facing the console). Also, the texture problem that had occurred before had appeared again on the animation files, and I did not know how to fix the problem without inadvertently deleting the Presenting the problems to Hannah, she explained that time had sadly run out really to work on anything else, and to now cut our losses and polish up what we could, though I was relieved to hear that the way the animations work in Torque (with a .dts model file and several .dsq animation files) means that the deforming animations on the animations will be ignored, as they will instead use the texture on the static base model, which had already been fixed.

I also finally managed to fix the problem that was preventing the enemy from exporting correctly by restarting the adding of the collision meshes, using Hannah’s Chrono model as a reference. In engine the model was fine, though the Torque engine I was using for my tests in the university lab was crashing when the model’s collision mesh made contact with anything. This however was also happening with Hannah’s Chrono model, which I knew from our presentations was working fine in our build, so I decided that this error was likely something to do with that particular install of Torque, likely to do with our models not being optimised for the pre-made game example (one of the examples that come packaged with Torque) that I was inserting them into.

My final piece of work was in week 14, which saw me texture Harry’s fortress model; a relatively quick procedure (especially thanks to a “difference cloud” filter that I found created a nice looking mottled metal surface effect) and I got it ready for export by the weeks end:

Unfortunately, some sort of error in the fortress model meant that attempts to bring the model into Engine failed (it would appear as an empty box, much like the enemy model did before) and so could not be put into engine. There was no time to work out what had happened, and an attempt to fix it in the same way i did the enemy model failed, forcing me to abandon the model and leave it as an unused asset.

This concluded my work for the “Save The Fortress” project. It was a pity to have to leave the project unfinished, especially as I had admittedly become quite attached to the concepts and ideas behind it, but time had caught up with us and forced our hand. I have had a lovely time working alongside the team, who had proven themselves as a capable workers and good companions throughout. I did notice several majors problems in my work practices and mild ones practices of the group mechanics that I could make note of for future projects, which had been a primary point of this module in the first place; a simulation of a real design house environment to prepare students for the industry. I certainly feel it has achieved this, and I am already confident that several of the skills and tips I have learnt on this project will help me in my upcoming third year assignment.

Easter Break (Week 10-12):

Was mostly devoted to another piece of university work (a large essay piece) that had to be completed shortly after our return, so I was unable to work much on the Save the Fortress project.

Week 9:

The final pre-Easter week saw much of the group preparing for our presentation and prepping the final build, but I was asked to continue working with the enemy model and thus did so. Seeing the project coming together within the presentation however was quite pleasing, and the group had a chance to see the fruits of their labour, especially Chrono, who had earned a name for himself as the first character from any group (to my knowledge) to get into engine animated.

However, Hannah, who was testing Chrono in engine at the time, did notice that Torque was not really achieving the cell-shaded graphical effect we intended with the project, and at the moment all of the textures were looking overtly bright. She managed to lower some of the light settings, but we also made the decision to add material surfaces to our textures (such as denim or wood) to help lessen the “Lego-like” (to borrow Hannah’s term) appearance. Our plan was to complete this over the Easter break and so return with them in late April.

For the enemy, Harry felt that his texture for him had been a little messy, and so asked me to make a new one. However, a slight miscommunication meant that I UV mapped the wrong character (the guard), and so had to rush in as mush as I could of the UV map for the enemy before I headed off home.

Week 8:

With week 8 I began weight painting the new model, which this time proved much easier and finally worked, allowing animation to finally begin! The texture Harry completed was added…

…And I began immediately…
…and found a bug…

The texture was deforming whenever I tried to move the model around. Mentioning this to Harry, who had much more experience than myself in modelling in Maya, he said he’d take a look and get back to me. While he was doing so, I continued to work on the asset list (which people had felt did not contain enough information, and so looked to deepen) for the project and on some of the other coursework due in around that time. As I finished these he had found the issue, which was my not delete the history of the model. I had stopped doing this as I had found deleting the history of a weighted model would wipe the weighting, meaning the modeller would need to start over. Harry however managed to find a way around this and fixed the bug, allowing me to continue the animating.

An example of the animations being made with the model.

Week 7:

By this time thoughts were beginning to turn to assembling a final build for our presentation before Easter. Until now our completed content was separated amongst several different builds and we had never actually brought it together. This meant that completing any unfinished material was top priority…including our enemy model.

Unfortunately all attempts to correct the weight problems on the model had failed; with the legs how they were, the system would never be able to make the correction, and the way the model had been constructed meant that moving the legs into a new position was proving just as impossible. Therefore, the decision was made to remake the model from scratch in a straighter more outstretched pose, so as to make weight painting and animating possible. Fortunately, as I had already created the first model in the past, I was able to speed though production of the new model, and had the base model rigged and ready for texturing and weighting by the end of the week:

A quick test of the model to check it works in Torque engine.

Prior to the rigging, Harry also asked me to make sure the model was scaled for the project, as he had noticed it to be far too big in the past. For this I downloaded Hannah’s Chrono model, and used it as a scale, comparing also to an older diagram drawn nearer the start of the project that compared the sizes of our three characters:

Also, I was asked to produce an asset list by Brendan; a list of all the elements that had to appear in the game for it to work, along with their file name and any properties that may be important. I worked on the first version of this on an evening over the weekend and uploaded it to the site. As with the questions list, i suspected that this would be a file i updated over the course of the project.

Week 6:

With completion of the model’s texture at the beginning of the week, I was able to focus on and finish the weight painting of the model. However, it was during this that a serious problem presented itself. The model was hunched over, with the knees bent in its idle pose instead of straight. This meant the vertices were all closely packed together and the computer was unable to properly apply the weighting and physics to the engine. Attempts to move the legs would horribly deform the stomach of the model, which would make it useless for our game. Throughout the week and on into the next, I repeatedly tried to manually re-weight the model amongst my other tasks.

Teusday’s meeting saw Brendan task me with producing the model for Chrono’s timepistol. As with the enemy character, I was given a model to use as reference, and aimed to keep to this image as closely as possible (though I did explain to Brendan that modelling the wires would considerably add to the poly-count for very little aesthetic value, and so we agreed to remove them).

My first model of the timepistol kept faithful to the model, including the smoothed handle (which was added by selecting the relevant faces, arranging them manually into a curve-like shape, and then using the smooth command). However, Harry was quick to remind me of the need for keeping polycount to a minimum (in fact this timepistol model had more polys then his finished model for the fortress!). He also explained that as Chrono’s hand would be covering the handle at almost all times, and it would be a very small model anyway, there was little need for such a highly detailed finish. I therefore created a second lower-poly version of the model that was more suitable, and once cleared with the team went on to texture it:

Week 5

With the model successfully completed and polished (triangulating the mesh so it’s compatible with torque, shaving unneeded faces etc) attention turned to rigging the model with a skeleton of IK joints to prepare the model for animating, and to lay out the UV Map for texturing the model. Again the group had prior experience using both of these features, so production began smoothly (though in the tutorials provided by our tutors and technician I did find several features concerning both tools that I had not known of previously).


It was during the rigging that I found problems with getting the model to move correctly. When moving the hand forward, the elbow would not bend but instead lock in a straight line and follow the hand. Also if bending the arm inward the elbow would move vertically as opposed to horizontally.



Showing the problem to Harry, he suggested redoing the rig with a bend in the elbow, which would guide the joint in deciding which way to bend during animations. Further problems when shown to our technician Charlie were found to be my fault; I was unaware of the need to orient the joints on the model or of the need to weight paint the vertices of the model. Tutorials were planned for these features, but our group was making good progress and had reached the point of using the features before they tutorials were scheduled. Charlie however kindly guided us through the process. I completed the rigging, though the weighting had to be finished off next week.

Mapping the model was also made much easier thanks to a method introduced to me by Harry. Originally I have used the “automatic mapping” feature, which though quick and effective prevents much organisation of the map. Harry’s alternative uses the “planar mapping” feature, where the mapping is done according to a specific camera that can be angled by the player, and I could select which faces of the model to map onto the UV, and I could move the camera to different angles for different faces. Though a much slower method compared to automatic mapping, it allows far greater organisation of the UV Map, and allowed me to size elements myself, making high-detail parts on the UV map larger, making painting of the texture far easier. In the case of this model, as some textures were one solid colour, Harry showed how I could make these UVs very small on the UV Map, allowing me to paint them solidly with just a small square of colour. This gave me far more room to place the higher detail parts of the map.





While doing this, Harry asked if I could help him brainstorming the design for the fortress weather control device for Chrono to use in the end part of the project. He showed me some ideas he had come up with, which looked good, but they all made the control device out to look like a weapon, and I put forward the idea of alternatively making it look more like it was a normal, peaceful device that could just be used like a weapon, and idea he thought might be interesting. He also wanted the weapon to have some kind of close combat tool; a chainsaw or a laser, in case ships got too close to the cannon. As it was a weather device, I suggested a high pressure water cannon (inspired by the use of such a weapon by metal gear REY in Metal Gear Solid 2).

The first set of designs I devised were on a similar vein to his own; a sleek, high tech look made of simple models (any complex shapes would be represented through the texture). He liked them, but he felt a more “nature-esque” design would suit the model, so we looked to flowers as a possibility. He also thought it would make sense for water to have a role in the design in some way. Though this design direction was not used in the end due to time and poly limitations the brainstorming together I’m sure help.

Week 4:

Week 4 saw the beginning of production of the Enemy character model. Hannah provided a coloured image and ‘T-pose’ sketches of the character design for me to use as reference for creating the model:

Model production in Maya was greatly eased by the use of the “image plane” feature a colleague showed me, which allows a flat image to be inserted into the workspace. I was then able to insert a sphere into the workspace and manipulate the vertices of the model to line them up with the model and sculpt the model out of the sphere, which was added to using the extrusion feature to sculpt the limbs and extremities of the model.

As the design was (except the radio antenna) a symmetrical model, I decided to create one-half of the model, and then use the ‘mirror’ feature in Maya to clone the other half and merge the two together.

Testing the finished mesh in the Torque engine.

As production of the model continued, I also began considerations concerning the character animations for the project, focusing on matters of how the body moves in real life when walking, running or jumping etc. This was then compiled into a word file and posted up on the site for the team to refer to as needed. Our course has seen us undertake many animation-based modules (namely one in the first year), and use of Maya in previous work meant the team had a solid understanding of animation within Maya.

Week 3:

Week three was designated as the point that we were to begin our production stage, with many members of the group shifting their main focus to the construction of assets in Maya for importing into the Torque engine, while the rest focused their attention on finishing off the concept art. I was tasked with conceptualising the tempora opponents for Chrono to fight during the game, a task I wanted to complete quickly, as Hannah was in the process of creating the final design art pieces and “T-Pose” sheets for all characters. Fortunately I was able to look back on my earlier brainstorming ideas to form the foundation of my ideas.
I had always imagined tempora as a very old group, and considered the idea of their agents being very old themselves, kept alive through artificial means (magical or technological). My main inspiration for this approach came, once again from a games workshop source; in this case the Warhammer 40’000 universe, where several of the famous characters are still alive well beyond natural age, maintained by archaic, cybernetic implants, gene therapy, or magical assistance. I imagined Tempora’s agents to have systems that were much less archaic and bulky than the examples in 40K, but I nevertheless found myself drawn to the warhammer approach of making the Tempora’s skin extremely pale and wrinkled to show their unnatural life, and so incorporated this into my designs.

In addition to the inspiration from Warhammer, I looked for examples of an elderly face, so as to collect ideas as to the bone structure, skin complexion, and facial expression, all of which I found can vary quite widely between different people, and is sometimes quite a degree different to the facial structures of a younger person.

My idea for these enemies was that, physically frailer than most enemies, they rely on technology and perhaps even magic to complete operations, so lots of systems and equipment would likely be visible on their form. Hannah had also made a request for characters to have some kind of mask or some such to obscure their faces (namely the eyes) slightly, so that a model can be used multiple times without the cloning being noticeable.

However, it noticed that my design, though interesting, would require a lot of modelling, and as their face was mostly exposed each elder would likely have to be a different model. So I decided to reconsider these ‘elders’ as a kind of “sub-boss” for the game; Chrono would only encounter two or three in a level, and design other, more generic enemies for Chrono to commonly encounter. This is what inspired a slight modification to the original concept and the introduction of Tempora “initiates”; younger Tempora agents (visible on the far left of the concepts) who would operate in groups, coordinated by an elder. Initiates would focus on direct physical attacks, having younger more agile bodies than the elders, and less trusted with the advanced technology or magic’s that the elders used. These could wear masks to cover themselves, or perhaps the storyline could explain them to be clones created purely to serve the elders, thus allowing them to look alike in-game.

With regards to personalities, i imagined the eldars as being somewhat remeniscent of the classic sterotypical "old strict schoolteacher", bossing others around and snapping at Chrono as they unleash thei attacks with such curses as "Pretulent child!" or "Brat!". The Initiates, meanwhile, would be more like the stereotypical bully or "chav/townie" sort of character; making sneery remarks and showing off all the time while teasing Chrono, which i felt would give the player more satisfaction when he defeats them.

---

Unfortunately, some technical issues with E-Mail meant the images did no make it to Hannah till the Thursday (I had intended to get them in Wednesday), and during the wait she had found herself considering ideas of her own for the enemies. When she did receive my concepts, she really loved the ideas, but felt that they were “a little too serious” (which I am highly prone too, as ‘nitty-gritty’ games are my focus), and may feel out of place in the highly cartoony world being devised. I did not mind this, and I found myself quite drawn to her design for the enemies too – large, black creatures – and her idea of them attempting to masquerade alongside the guards I had designed earlier (which they fail at as their bodies are far too big for the uniforms). We therefore decided to go with that idea instead and scrap the Eldar/Initiate idea. I found myself quite liking the designs however, and so may make use of them in a later game concept.

Week 2 part 1:

Cave Concept: for my concept of our fortress environment, i decided to develop the cave concept i had brainstormed earlier, as i felt my other concepts were quite commonly seen in media, and the idea of a cave system becomming a fortress was rarer compared to them. With Harry's examples of the artistic style being used, i was able to try and present my design as close to that art style as i could, so as to give Hannah and Brendan an idea of how the final product would look where it considered. I admit my art skill is by far my weakest area (especially compared to my colleagues) but i was able to nevetheless present the ideas with the peice effectively;

Concept for Cave environment

Additional concept work of items to be placed in the environment. I intended these for modelling later, so the modellers would have reference when creating the in-game assets.

With my concept pitch, i tried to also think of the actual events within the level and the wider storyline (explained below). Recalling that our game was meant to be based off of a TV show, i made references to tie the game in with the series, making up elements and concepts to be elements from the series:

"Chasing the Tempora Boss through a portal, Chrono has found himself in a large network of caverns and tunnels. Several makeshift bridges, ladders and sets of lights have been erected here, and it soon becomes clear that an unknown faction has converted the network into a base of some kind. However, Tempora has apparently launched an attack on the base, a concept that confuses Chrono, as Tempora surely could’ve simply gone back to before the base was built and wipe out its creators. Shortly after jumping in, Chrono finds a woman being chased by Tempora agents. Defeating the agents, she reveals what is happening; the facility is the central base of the Timeless; a resistance group of ex-Tempora (whom Chrono has encountered, and both locked horns with and helped, several times in the series) who are trying to stop their former comrades, and have developed advanced temporal technology of their own to combat Tempora’s (including a time machine of their own). However, the database that houses all of their research is currently at the centre of the facility. Temporal shielding has prevented Tempora from simply beaming into the chamber and stealing up, but they have now breached the base through a gap made in the jamming field by a turncoat, and the Boss is now fighting his way towards the database. Chrono must hold off the Boss and Tempora until the Resistance can evacuate the database using the time machine."

Storyline Concepts:
To coincide with my level concept, i attempted to fill in the gaps in the storyline of the overall peice to present to Hannah. As with much of my work, i wanted to look at the deeper reasonings behined the actions of characters; why was Tempora doing what they were doing? How did Chrono react to their acitivity? My storyline idea attempted to explain all of these, and flesh out the background of the show that our game continued from:

Tempora is a secret organisation formed by a government in the future. Using a technology known as a time beacon, Tempora’s agents were able to go back to any previous time and change history allowing that government to seize control of the entire planet. They maintain a constant Virgil in their world, any resistance simply wiped from existence whenever it crops up.

The teenager who has come nickname himself “Chrono” however, while sneaking around a hidden tempora facility he stumbled into, came into possession of an old “Time glove” (the gauntlet-like multi-tool that Tempora agents use to communicate with their high command and to assist them in the field). Accidentally activating the gauntlet, he was pulled into the past by a automated beacon, which are used to summon tempora agents to particular time periods; the standard agents themselves cannot control this process, only trigger portals to leave the timeline and wait for a beacon to pull them in, to prevent rebellion within Tempora’s ranks, as only the higher up leaders can actually jump of their own accord.

Ever since Chrono has been unstuck from the timeline, sabotaging Tempora’s activities and seeking to find a way to stop Tempora from ever starting and so restore the true timeline. Of course he is unfortunately at their mercy in a way, as he can only go to time periods where Tempora’s beacons are summoning their agents. As he is unstuck from time, Tempora has found that they cannot simply go back in time and kill him. When they tried this in the series (by running a younger chrono over with a car), they only succeeded in killing off his history; the “prime” chrono is still alive, as he is unstuck from time, while an “alternate” Chrono died (he in fact witnessed his own death).

Week 2 part 2:

Charlie Jade Reference:
During conceptualising, i found inspiration from the American\South African TV series Charlie Jade, which is set in Cape Town and looks at alternate realities and a character who travels between them. Though a slightly different theme, i did feel that dimensional travel as a concept shares many similairites with our time-travelling, and so felt the artistic methods used in the series to represent it could be adapted into our own work.

Being set in the same location in each universe, the series prevents the three from looking alike by giving each its own colour pallette. 'Alphaverse' (the character's futuristic dysotopian dimension) features a prodominant green tint over most objects, with the sky a murky green on most occasions. 'Betaverse' (our dimension) meanwhile, replaces that tint with a blue one, while the final 'Gammaverse' (a utopian dimension) lacks a predominant tint and uses the natural colours of the environment and objects (though at times with the colours strengthened to stand out). Though there are some major cosmetic changes between the universes, other elements remain the same, thus the colour difference allows veiwers to be constantly aware of which universe they are in.
I am very interested in adapting this concept for our project, perhaps as Chrono is warping in at the beginning of the project and the shift is happening between the Pirate time and the time the level is set in, or perhaps in-game to represent time affects during the level. Hannah found this interesting, but the current project plan lacks any need for them. There may be a chance later on to incorperate them though, so i shall keep them avalible.

Group Meeting:
Week 2's Teusday meeting saw the entire team able to gather for the first time, and we also welcomed a new member due to the disbanding of another of the project teams. All designers took this oppitunity to present their concepts (which had been put up on our website prior to the meet). Discussing all concepts, it was found that a concept presented by Hannah herself (of a floating island with a weather control system atop it, which Tempora seeked to attack) was most preferred by the majority of the team, and the decision was thus made to make this our central project instead of the wild west concept. Elements from other projects were incorperated into this one (such as Lloyd's pirate ship concepts, which became the ships in use by Tempora in their attack on the floating station).

Fortress Guard Designs:
With our final project now clear, team members were given new assingments for fleshing out the concepts of the level. I was asked to complete designs for the Guards who would be attempting to protect the station from Tempora.
I found inspiration in my design from the sleek, generally simply decorated nature of uniforms in science fiction shows such as Star Trek and Babylon 5, and decided upon a one-peice jumpsuit design such as those in Star Trek. I realised that my design would naturally need to suit the interior design of the fortress itself, which Harry was designing at the time, so i decided to complete a preliminary concept first, and then refine the concept later when Harry's fortress design was avalible for reference:

My origional desing for the guards were inspired by my own previous ideas for the fortress itself as a 'tech-organic' structure; organic in shape, design and most materials but containing electronics and systems at the same time. I therefore saw the personell on the station as very environmentally-minded (perhaps even mildly "eco-warrior-esque'), and reflected this in the design of the guards by researching examples of envionment and nature and collecting examples of colours one would expect to find in nature:

Among the more interesting references i consulted for this research was the "Woold Elf" faction of the Warhammer boardgame universe run by Games Workshop. I found the art for their faction and the colours chosen within highly inspiring and well suited to my guards; in a way, my guards were almost "wannabe-wood-elves";

---

The above concepts were submitted to the group for reveiw, and were well received. However, as planned, upon Harry's completion of the fortress idea, which turned out to be a more technological, science-lab-esque design with a predominantly white colour scheme, i felt the need to refine my design to better suit the new environment. I wanted to keep the eco-freindly pallette of the guards but blend them in with Harry's fortress, so made white the dominant colour of their suit, keeping the green a secondary patch colour, which were then handed to Hannah for the final character design in the proper style;

Week 1:

With the beginning of our first true project week, Art lead Harry decided upon a style to take the project down; a style inspired by the Japanese Animation "Tekkon Kin Kreet":

In further discussion, he also expressed interest in, instead of Tekkon Kin Kreet's traditional anime art approach, adopting a more westernised "Saturday Morning Cartoon" feel to the project, using simple but effective designs and texturing throughout. This was presented during out meeting this Teusday, along with our other ideas.

This meeting (which was the first gathering of all the designers, though due to appaling weather that week none of the Programmers, who are based on another campus, were able to attend the meeting) was a chance for the tutors to come to understand our base ideas and see the direction the project was heading down. We found that with our many ideas, there was none that particularly stood out at the time, so made the decision to each continue developing ideas alone and have another meeting on that Friday. However, we did set out the first set of assingments for members of the group. We decided that we would need to compile an "Frequently Asked Questions" list to hand to the programmers, to help us understand aspects of the Torque engine we would be building the game in, which none of the designers had used (and some, including myself, hadn't even heard of!). I compiled a list of nine starting questions and then handed it over to Hannah, who was acting as liason between us and the programmers. We will be adding more questions to, and removing asnwered ones from, this list as we continue further into the project.

---

By Friday's meeting (to which a representative of the programming team was able to attend), we had begun to finalise our concepts. Harry presented to the group his concept of a "wild west-esque" science fiction environment; fictional yet containing several of the symbolisms people would relate to the wild west (such as traditional hats, deserts and stiruped boots). I found myself falling in love with this idea, as i felt it would make a novel and very atmospheric concept that would stand out and appeal to the audience well, as it would likely be starkly different to the general market. It was the first concept we considered for the final, and the group discussion focused on fleshing out the game within that world, based on the specifications outlind in the brief, which called for a three-section level; the approach to the fortress through the seige, arrival at the fortress, and then defence of the fortress from the Tempora seige. Concepts passed between two ideas; a settlement serving as the "fortress", and a train (the latter being suggested as a less cliche'd idea, and inspired somewhat by the infamous great train robbery).

Eventually, we debated combining the ideas to form two possible paths; one where the train is being used by Tempora to invade the settlement (in which case the settlement is the fortress), or one where Tempora are departing the settlement via the train (in which case the train would be the fortress). We considered several possible trains; a steam train, sci-fi train, even an "air train". I put foward the concept of an oversized land train, possibly anti-gravity driven, inspired by a level in the FPS game Unreal Tournament 2004.

In the end however, we found that there was not a full consensus on the idea, and in the end decided to consider alternatives instead. Again, the group decided to part and come up with alternatives in their own time, and to present them Teusday.

Week 0:

With this project, we were fortunate to be told what our teams where and given our briefs the Thursday of the week before the projects were actually scheduled to begin, giving us a good opportunity to get to know one-another and read over our given brief. I have been assigned to Team E ‘Save the Fortress’ as a game designer working under a lead designer. I was delighted to find that my team consisted of group members whom I have seen on the course to be hard working and full of ideas, so I am looking forward to this project and how it turns out.

First meet up:
The brief given is made out to be that of a franchise game, based off of a fictional American TV show called ‘Time Warp’. The Main character, a teenager named Chrono able to jump through time, is fighting an organisation known as ‘Tempora’ and their time-based plans. The game was aimed for a young male teen audience. Our objective was to make a level for this game named ‘Save the Fortress’, in which the player must reach and then defend a ‘fortification’ and a relic within from Tempora’s forces. In the course of the level, we had to introduce the player to using cover effectively in game, shooting multiple targets at once, and on an additional feature that we were to devise ourselves.

Meeting up as a group for the first time, several decisions were made jointly and agreed on by Brendan, our producer. It was agreed that Realism was to be avoided, as many of us have previously found that attempting to achieve realism drags projects out, and we do not really have the time available for such a concept. A cartoon style, we felt, would better suit both the target audience of the piece and allow us to achieve an identical product quality to a realism-based style while avoiding the problems inherent with that approach.

We also decided that we wanted to try to incorporate alternatives to the normal “blood and guts” shooting effects found in most modern games, which would mean weapons that defeated the opposition in ways other than killing, as is commonly found in cartoony games that wish to add a comedic element (such as a gun causing enemies to dance, and one causing them to become chickens, in Insomniac Games’s Ratchet and Clank series). Many concepts were put forward (such as an age-based gun that de-ages or overages the target, and a concept of my own of a weapon that pulled the target out of time, transporting them a special ‘prison’ area, inspired by a similar concept for a “Chrono Prison” considered but dropped from Command and Conquer; Red Alert 2).

As with my previous projects, I recommended that instead of all trying to devise the whole concept together from the start (which I have found delays projects, as each person tries to push their own concepts and different ideas conflict), we separated to devise concepts separately, which could then be discussed in their more complete forms later and a certain one agreed upon, upon which the others can be broken down and incorporated.

Brainstorming work & Background Research:
To begin, I decided to give the brief a more thorough analysis, going through and underlining ‘keywords’ that stated the specifications of the project (aka; features and content that must be included within the final product, such as features, game plot, or the names of items and characters). This gave me a solid idea of, and allowed me to clearly list, the limits I had to stay within for the project (in addition to those decided upon earlier by the producer).

With these now available for quick reference, I began brainstorming concepts for the project based off of some of these keywords (the stage of games design that I particularly enjoy and focus my skills in). However, keeping in mind that in our grouping I was among those at the bottom of the chain of command, with a higher lead designer (Hannah) deciding which ideas were accepted or dropped, I decided to refrain from any full concepts at this time, and instead focus on outlining the different possibilities for each concept to present, so Hannah could then decide on which of them she liked and wanted developed further.

(Cleaned up version of a spider diagram produced during my brainstorming)

The first major area to consider was the concept of the fortress itself. Though many (including myself) automatically assume fortress to mean a large castle or installation, the term can in reality mean a wide variety of possible environments, which we wanted to explore so as to avoid making a cliché, ‘stereotypical’ game. A cave network can easily become a fortress when a group move into it. Or the fortress could be a set of ruins, their days of glory long since over. Over the course of these I came up with several possible environments I could develop into concept sketches later.

One area to which I paid special attention was Chrono himself, who is the main character of the project and would thus require great detail (especially as he is meant to have been from a popular TV show, which would’ve likely given him a deep character background that would need to be shown in our game).
Based on experiences of young teenagers (about 11-16) in real life and in the media, I feel that they are stereotypically very rebellious, slightly big-headed characters, generally rejecting adults attempts to order them or attempts by children to socialise with them; they are on a point between child and adult, fitting into neither group, and are just beginning to taste the freedom of adulthood for the first time, but lack the foresight and feeling of responsibility and obligation that an adult has. I have come to name this period ‘The Phase’ and I was very interested in seeing how our teenager Chrono (whom I assume is within this age group) would be affected by it, and how it would impact on his role in the storyline. If he was working for a group, did he serve them diligently, or was it a very frosty relationship? Does he truly believe in his attempts to stop Tempora or is he acting unwillingly? Many shows for non-adult audiences will consider this story arc at some point; presenting a character with a choice as to whether to conform to their obligations and obey higher authorities or to reject them and act according to their own desires (with conforming usually portrayed as the better of the two options). Though we are trying to avoid stereotyping, this kind of scenario is good for showing what is a vital component of the mental change from child to adult, and it’s a dilemma that the audience could really relate with, which would help them relate to Chrono more and thus get more out of the game.

With this theme in mind, I found an example of such a character can be found in the Capcom title Devil May Cry 4; the character Nero.

Though actually older than our age group (18), I feel his personality in the game (rebellious, petulant, anti-social etc) and his appearance serves as a good reference. I note that his costume contains a lot of denim, a material popular amongst teens and young adults, so I may make discuss this with Hannah and see what she thinks about him wearing jeans or some such.

Finally, I took an opportunity to consider the Tempora organisation as a group, outline who/what they are, and give possible reasons behind their actions. Though Tempora is presented by the brief as a stereotypical evil organisation, I would be interested in introducing an alternative viewpoint to the story, shaping it so that to Chrono’s eyes they are evil, but to themselves they are not so. Perhaps they think they are working towards a greater good, thinking the end justifies the means. Or actually think they are doing good, blinded to the truth of the matter. Perhaps even from the outside they are doing good and it is Chrono that is in fact in the wrong!

I’m also considering how Tempora came about, with my favourite theory inspired by the American/South African science-fiction series Charlie Jade, in which a future government, seeking a perfect world, created Tempora to shape history. Again, I will present these thoughts to Hannah for her views, and I will develop those she likes further.

Camera Concepts:

Finally, I had a few thoughts as to the camera system that would be used ingame, which the specifications demand is a third-person camera. Again, I am considering the DMC4 as a possible reference, as playing it, as I felt the camera system is quite well designed and rarely caused problems in game, though my colleague Harry felt the fixed camera style (the camera stays in preset locations, turning to follow the player, and only moving when necessary) would not suit gameplay, and suggested a more ‘follow-style’ over the shoulder camera (perhaps like the one in Syphon filter or Resident Evil 4 and 5.