curtisjumpfutureworks

[curtisjumpfutureworks]

Group Project Prototype #3

The third concept was for “Texas Masquerade”, a third person action/mystery game that featured multiple masks as power ups, giving all sorts of weird new effects and abilities to the character.

“Trading” was thus the theme chosen. The use of powers is limited to the specific mask that the player is wearing at any one time. Any combat with enemies is mostly stealth, as you can see them beforehand and dispatch their simple AI very effectively using the right sequence of powers.

-Mechanics Development-

As the gameplay is basically a very normal third person adventure for the most part, but with many modular mask mechanics added on top.

Detective Vision Mask

Was established by making 3D hand, boot and brain sprites to hide around the level, only visible when the player equips said mask. It was pretty straight forward to implement, simply casting to objects and toggling the visibility of the sprite component. The brain glyph was there specifically to tell the player which objects they could use telekinesis on, since the overall object should be movable.

Telekinesis Mask

The player can grasp certain objects and make them levitate before them. This was achieved in blueprint by having adding a physics handle function to the player, and having it defined by an invisible point before the player. They can thus grasp any physics objects and pull them along to that location, rotating them with the camera movement and everything.

On-Character Menu

One of the first mechanics developed was the on-character menu, wherein the camera rotates to face the player, and you can observe the masks stacked up in the sides of his trenchcoat. A HUD also appears to detail how much money they have picked up in the form of stylized floating coins from the world around them.

AI Basics

Uses vision cones and a ‘simple move to’ function, allowing for stealth.

-Planning-

Both Trello and Discord were used a lot more during this project. It was odd working on top of the existing level ideas instead of giving my team members the core mechanics engine first.

-The Verdict-

The strength of this game is it’s weirdness and humor, which might make it seem unlikely as a something with a strong core mechanic. But, as long as we are honest with what works and what doesn’t, and remain realistic in our overall goals, this game concept is ripe for continued future development.

[curtisjumpfutureworks]

Group Project Prototype #2

The second concept was for “Anti-Penguin”, a third person action platformer that featured a completely over the top scaling power system; The player builds friction by running, which can then be used to melt enemies and objects that reside in the icey levels. The basic idea was that the gameplay would be simple but continuously outdo itself, a bit like Katamari.

“Trancendence” was thus the theme chosen. Because of this weird system, enemies and objects could simply be scaled larger to make them more powerful, lending the game a bit of “Awe” as well.

-Mechanics Development-

The design mostly used the third person template as a kick-off for experimentation, through I always knew it would have needed replacing if the game was actually worked on further. The heat mechanic was basically programmed in one sitting and worked very well at first glance, creating a large glassy sphere and flame particle effect which scaled in accordance with the player’s heat level, removing the need for any distracting health bars or HUD stats. This was an intentional part of the ethos in my eyes, since such a fun and silly game shouldn’t rely on number crunching or distracting information. All the language and mechanics should be displayed visually.

Unfortunately, programming the objects that needed to be destroyed was not quite so simple. Custom collision was needed to prevent the player’s massive particle effects from simply melting everything from the other side of the level, and even then, it was very difficult to stop things from being destroyed (or going inside out after obtaining a negative value).

The problem was that contacting something repeatedly adds the value very quickly; Something which was difficult to diminish in a controlled manor.

Input from the other team members and the tutor suggested that if it was to continue that more solidly defined states would be required, but I’m not entirely convinced that would retain the fun that the infinite scaling that the project toyed with. Rich had ideas about changing the materials alone as a visual clue, but without the time to experiment, who knows if that would have been adequate.

-Planning-

Both Trello and Discord were used in varying measures during this project. It was a little more program-heavy than some of the others, which forced closer coordination in many ways. There were also several tech failures and sicknesses among the team that made things a bit hectic, but I think we did okay considering the relatively large scope of this idea.

[curtisjumpfutureworks]

Group Project Prototype #1

The first concept was for “Boom Boom Space Train”, a top-down third person shooter that featured levels constructed from multiple carriages linked in sequence, enemies that attack the player, and destructible terrain. There was also two weapons, including a pistol (for shooting enemies and walls) and a bombs (for destroying floor panels).

The overriding theme was “vulnerability”, as destroying the floor tiles will kill enemies, but also gives the player less and less room that they can walk on themselves.

-Mechanics Development-

Seeing as it was my job to develop the programming only, this blog will only feature that element.

Player movement and putting the camera in a fixed direction was easy. Adding a separate mode for throwing bombs was also rather straight forward, through I ended up having them thrown a set length instead of wherever the player clicks. This was because the throwing arc would have taken maths which it simply didn’t seem efficient to bother with in a one week prototype.

The enemies will face the player, and can be destroyed by bullets, but I didn’t quite get around to making them fire back (through it would have been rather straight forward). The floor blocks are simply annihilated on contact. Nothing too complicated, through it would have needed more development time to truly feature things like weapons which effect objects differently per context or explode, e.t.c.

-Planning-

Trello was used to plan out the specific functions that could be obtained within a set time limit, through honestly, Discord was more helpful in terms of rapidly communicating what did and what did not work. I’m still happy with the other team members (a prop artist and a level designer), as things were quite coherent in terms of what objects and mechanics we needed to work with at a bare minimum. Through the overall product was very quick and unfinished, another week of development could have easily seen more context-based weapons, a health system, and enemy behavior systems added.

[curtisjumpfutureworks]

DD2000 ASSIGNMENT 2: ROUTE INTO THE INDUSTRY

An Essay By Curtis Jump, BA Games Design at Futureworks

Tutor: Joe Darlington

Brief;

The intention of this research is to discern what skills are necessary in order to obtain a specific job role within the contemporary game industry. It is about developing a valid plan of action towards gaining employment, by examining not just what software technicalities that the job might require, but also what social dynamics and interpersonal skills may be invaluable in order to simply get noticed among the myriad of other upstart developers out there.

Upon the completion of my degree I intend to eventually become an independent game designer. Someone who communicates the project vision to a small team of other artists and programmers, whilst also being fluent in graphics packages and the necessary scripting skills. Such a person must also have a strong understanding of game theory, narrative skills, interface design, and be able to present their ideas adequately to others through several mediums including both digital and on paper.

Note the use of the phrase ‘independent’. It’s somewhat of a contentious subject if the ‘indie scene’ even exists anymore, considering larger companies and well-known producers are now taking to steam and kick starter in order to develop what are not technically akin to large-scale AAA titles, but are none the less developed in a much more complex and company-based manner than the single-man teams of old. Dennis Scimeca’s article “2014 is the year indie games died” raises a lot of these points, but it is another intention of this article to show that extremely small teams have still been shown to achieve considerable success even in recent times, as detailed in some of the game examples that I will specifically elaborate upon below.

It’s my intention to strike up a small team and set my sites on something unique and practical, so there are no lofty ideals of leading large companies here.

Job Prospects;

It is obviously difficult to obtain exact data on the operations of independent individuals, but according to recent reports the average salary hangs at about £31,000, taken from a survey that was 38% made up of those that identified themselves as belonging to “indie” companies.

This is compared to industry standard employees, who can begin with a lower salary of £19,000, but stand to earn up to £50,000 for highly skilled and experienced positions. The variation is likely simply due to their being a far larger variety of tasks available.

Portfolios;

Being able to display one’s past work and use it to maintain an online presence is extremely useful for an indie developer because it allows them to exemplify their skill set and earn trust with other helpful individuals. Being able to trust the other members of your team is even more important than normal because of how small the teams are, and obviously having common interests can seriously help drive the design forward.

Specifically as a game designer, it makes sense to include extremely specific examples of what you are capable of. It sounds obvious, but in the online medium, holding the attention of others is done far better by showing rather than telling. It’s all about immediate availability, and consistency of design that retains a very stable, marketable image.

A more blog like format is acceptable, since it obviously keeps the latest work on top, but care should be made not to get to “wordy” or opinionated, so that the actual material isn’t lost in the clutter. People who have to dig to find the real gems of your work simply won’t bother, so it’s best to stay on topic, even if it references another person’s work that is closely related.

Obvious pitfalls are having a site that is too difficult to navigate, or not elaborating on a project enough to make your exact involvement clear. Having just images or text is not nearly as good as having full-blown video material and downloadable content, either, through Sketchfab can be used to display 3D assets without the user needing to go as far as downloading them, offering another useful form of immediate exposure.

CVs;

Through slightly more applicable to a straight coder or writer, CVs attached to portfolios in the form of ‘about the developer’ pages can be useful in setting out your exact programming proficiencies, and your most recent involvement in projects that might flown under the radar because of larger names generally taking precedence in their marketing.

Noting connections can be useful, but one should be careful not to appear overly reliant on something tenuous. Much like the portfolio segments of the page, a lot of care must also be made to keep the type of material on display consistent, in order to play towards a very specific marketable image in the reader’s head.

Building Net Presence;

In order to operate effectively, it seems that there are a couple of facts which make immediate logical sense.

The first is to start releasing material the minute that something is mechanically sound, but make sure images look good, since it can be hard to remove old material from google. Overall, it’s better to have a wealth of available information for a project, rather than small concise details.

Dev blogs and websites should be updated frequently, and be personable enough to remain relatable. As mentioned above, they should also contain a wealth of captivating media.

A facebook and twitter profile are the bare minimum in this day and age. It helps to be involved in current events and be seen to be an active persona in the industry. That said, it serves to be realistic and associate with similar companies and individuals that you like, trying your best to avoid appearing to bullish or cramming your opinions down other people’s throats.

Most of all, becoming synonymous with a unique selling point is also very useful.

Becoming More Than Just A Backroom Fangame Developer;

In order to obtain success, it’s easy enough to say that one only has to be unique and memorable… But in reality success only seems to be observed by those who observe the public consciousness of how the game fandom works, and provide a product that can visually communicate it’s associations, only with the ‘added benefit’ of fresh new ideas.

It also takes a personality that is expansive and involved with others, utilizing sites like twiter and even facebook to become involved in other projects alongside the creator’s main goal.

Grants and government funding are actually reasonably within reach of indie game affairs, too. The video games prototype fund offers 4 million pounds of British government investment, planned to create jobs in the video game industry within the next four years. It needs a strong pitch utilizing a video to entail development intentions, team details and marketing schemes, but is otherwise development-light since it does not require a completed prototype.

That means games makers can claim discounts of up to 25% of a game's production costs. It helped companies in Scotland such as Stormcloud Games and Blazing Griffin. Additionally, the UK tax relief for video game development is at 15%.

Research grants are also common for video games, through they rarely fund the game outright, and may arrest some creative control. The Kerbal Space Program Asteroid Mission Pack, created with full support from NASA, and released on April 1, 2014, is based on the real-life initiative to send humans out to study asteroids.

Competitions that can be used to gain notoriety are another option.

Dare to be digital is an award specifically aimed at university students and recent graduates, directly sponsored by Channel 4. Recent Futureworks graduates won the “ones to watch” & Channel 4 award in 2014.

The Indie Game Festival is another such relevant award. The audience vote for favorite nominees, alongside a panel of judges for different awards. The prize is money to help with development. Now in its 17th year, the awards are a total of $50,000 in prizes to independent developers, in both ‘main competition’ and ‘student competition’ categories.

Examples to Emulate;

Undertale is an example that really strikes the point home, using deceptively retro-styled graphics, in fact discerned from SNES classic RPGs such as Earthbound, in order to garter a fanbase. The meta-plot and innovative character interaction elements are clever, but they could not exist in a vacuum. It’s intentionally designed to subvert pre-existing expectations from a pre-existing fan base.

Toby Fox was the main developer other than art and music assistance. Despite being developed in game maker, and coming from a background involving mostly Earthbound Hacks and RPG maker fares, it has now sold more than a million copies worldwide.

Devil Daggers is another example of a game which cleverly manipulates nostalgia. Using a style highly reminiscent of low-poly PS1/Dreamcast horror classics like Resident Evil or Quake, as well as the more recently popular Dark Souls series, it’s a rather strange “single player death match shooter” with practically no level design to speak of, only a constant horde of randomised monsters to defeat.

Developed by the three-man team “Sorath”, namely Eugene Nesci, Jon Marshall and Matt Bush, they are based in Melborne, Australia. It’s difficult to track past information on the past operations of these members individually, but by presenting an incredibly cohesive combined front, they have already received sales of more than 45,000 despite only passing steam greenlight on the 18th of February this year.

Hotline Miami is a more strange example, since it doesn’t have an immediately obvious built-in fanbase, and only uses an obscure graphical style and pseudo-eighties drug haze stylings to promote an image similar to the movie fear and loathing in las vegas. It was none the less met with an very high ratings and had more than 130,000 units sold during the same year of release.

The key here seems to be Jonatan Söderström (AKA ‘Cactus’), and his many previous freeware releases giving him a substantial internet presence even before he decided to monetize such things. His game Clean Asia! was nominated for both Excellence In Visual Arts and Excellence in Audio at the Independent Games Festival. He also gave a talk at GDC in 2009 called "The Four Hour Game Design", describing his extremely rapid development process.

Stanley Parable takes a completely different approach, and was instead seemingly proliferated by youtube personalities LPing it. Originally developed as a Half-Life 2 mod, it was spread by reputation using only it’s incredibly good script and level design. Not something that is easy to emulate, and possibly not even the original intentions of the designer Davey Wreden. But it is interesting to note how this specific kind of gameplay appeals to being spread by word of mouth, with specific quips and scenes being endlessly quotable despite the game itself being so utterly procedurally generated that it is very difficult to spoil for newcomer players.

Summary;

Despite not having vastly impressive skills in any one specific area, it seems like my diverse abilities in coding, art design, visual storytelling, and even the use of music, make me most suited for the task of ‘Independent Game Designer’ rather than a more specialized role within the triple-A industry. The biggest flaws that I need to work on are my net presence and presentability, but I believe with a background of enough impressive smaller games, I may be able to make some kind of an impact provided their marketing is concise, well focused and carefully aimed.

[curtisjumpfutureworks]

XB2178 (Games Specialism)

Assignment #2; Sprite Based 3D Shooter Project, Development 5th to 19th April

Mechanics;

Now in it’s eight iteration, the game engine is operable but has some serious issues. For one, a parent system was created for the enemies that allows multiples of different types to use the same basic collision, navigation and “always facing the player” code, but also allows them all to act independently.

The collision issue with the player’s bullets is now fixed, and it now works fine. A hud for the bow weapon was also added, alrough it is not yet animated.

Problems which I have not been able to solve include the enemy arrows not causing damage to the player, even through I managed this using other objects in the past. Destroying an enemy with the player’s arrows also kills all of the enemies on the level at once, annoyingly, even through they should only be individually effected.

At the very least, I’m going to attempt to fix these issues, as well as making enemy projectiles collide with the walls more reliably. Lastly, a health power up would be an easy addition, as the sprites are already in the game, but it would be hard to test in the current situation where the player cannot be damaged.

-Curtis Jump

[curtisjumpfutureworks]

XB2178 (Games Specialism)

Assignment #2; Sprite Based 3D Shooter Project, Development 8th of March to 5th April (Easter Break)

Mechanics;

The development of the AI is still in progress. The main problem at the moment is that the player’s projectiles collide with the enemies’ oversized “detection” collision sphere components, causing them to despawn whenever the enemy is able to see them. Given the limited time remaining to work on this project, may simply implement only the most basic functions of each enemy type for now, and work on the more advanced AI components (Such as moving to acquire a line of sight before firing at the player, e.t.c.) given leftover time after the fundamentals (like them simply being able to fire or be destroyed) are implemented.

Graphics;

Finished 17 individual level tiles in the standard 64x64 pixel size. They retain the same limited palette as the enemies. They’re done in basic MS paint and converted to PNG using Photoshop as usual (necessary for both the transparency functions and keeping the file size down).

Level Design;

Construction of the actual level began, half to test the tiles and get the final scale values down, and half to see how well it works with the existing AI components. Seems to work fine so far. The only problem encountered is getting stuck in a corner if the enemy pushes you there (Via the “launch clear” function after getting damaged, added in the last post...)

Other than that, it’s certainly workable as-is.

-Curtis Jump

[curtisjumpfutureworks]

XB2178 (Games Specialism)

Assignment #2; Sprite Based 3D Shooter Project, Development 1st March to 8th March

Mechanics + Graphics;

Animated sprites now load in-game, alrough the specific animations for attacking are still missing. They will now rebound the enemy upon contacting him and cause damage to his health, however, which is the melee attack modes for the individual enemy types sorted.

Currently the entire structure is a bit of a mess and cannot support two enemies at once, however, so it’s a bit hard to test two individual enemy types at the same time (The ranged attacks WERE finished and demonstrated in a previous video, however.)

Using the same code that triggers the damage immediately, enemies can also be set to fire ranged attacks only within a certain range.

All that really needs to be done is to streamline the code more and separate it out so that every enemy is self-contained.

-Curtis Jump

[curtisjumpfutureworks]

XB2178 (Games Specialism)

Assignment #2; Sprite Based 3D Shooter Project, Development 23rd February to 1st March

Mechanics;

Now contains a health bar widget at the bottom left. The blueprint seems to be a bit temperamental (it unloads a bit too fast), but it works overall. The same mechanics can be easily used to integrate an ammo counter later on also.

Graphics;

HUD sprites for the second weapon, a bow, including firing frame.

-Curtis Jump

[curtisjumpfutureworks]

XB2178 (Games Specialism)

Assignment #2; Sprite Based 3D Shooter Project, Development 9th February to 23rd February

Game mechanics development;

Redloft Alpha 3 has a number of tweaks and improvements. First off, collision physics on the projectiles have been turned off, but given overlap effects so that they are destroyed when hitting things like walls. This greatly improves the strange way that they acted in earlier versions.

Secondly, the enemy now fires it’s own projectiles at the player, even using the auto-facing feature to aim. They do not yet harm the player however.

Thirdly, there is now a basic health system for the player. They can take ten points of damage before “dying”, through this simply destroys the player object at the minute, with no visual effects. A spike with a pain causing volume has been specifically added to test this. Also note that it displays the remaining health in the upper left side of the screen when the player takes damage, through it is still a simple numeral string at present.

Sprite Progress;

(Higher res version here.)

New progress on the sprite sheets. Enemy one (”Archer”) now has a death animation, including a hat which falls off. Enemy two (”Komuso”) has a simple animation for attacking with their sword, and a death animation in which they are intended to drop said sword. The newly added enemy three (”Oni”) only has idle and walking animations so far.

Lastly, larger-resolution arms holding katanas are in progress, shown here in two different versions. They are intended for the HUD, when the player is using their default melee weapon. The perspective is very difficult to make look visually appealing, however.

The main things left to do for sprite work are thus finishing the attack animations, creating the other weapon HUDs, and adding small blood “particles” for a more immediate visual confirmation of when an enemy is hit.

-Curtis W. Jump

[curtisjumpfutureworks]

XB2178 (Games Specialism)

Assignment #2; Sprite Based 3D Shooter Project, Development 2nd February to 9th February

Game Mechanics Groundwork!;

Redloft Alpha 2 contains a lot of new unreal blueprint elements that will be used for the game’s basic enemy AI. The first component of the followguy object adjusts the rotation so that it is always looking directly at the player. This is both handy for making the sprites always display correctly, and actually having them aim at the player when firing projectiles,

The second blueprint component uses navmeshes to not only cause the object to constantly move towards the player, but also to avoid any objects that are blocking the path. It is currently activated by pressing the “f” key, which is why it delays in the video, but it will be activated using trigger volumes in the actual game.

Also note how the projectile that the player themselves fires behaves rather strangely. This is because it was programmed from scratch and doesn’t use the default unreal code.

All of these assets need refinement, but it’s a start.

Sprite Progress;

Running animations for enemy 2 were completed, and some large-scale character sprites were created for the start screen. Also note how the color palate has changed to reflect the second “beige and red painting” style from the last post, which I have now decided to make standard as the art style for the entire game.

-Curtis W. Jump

[curtisjumpfutureworks]

XB2178 (Games Specialism)

Assignment #2; Sprite Based 3D Shooter Project, Development 26th of Jan to 2nd February

Art Style Reconfiguration;

Large portions of this week were spent not just creating sprite assets, but also reconsidering large portions of the game’s aesthetic from the ground up. Feedback from the earlier sprite work has lead me to realize that the hazy and indistinct nature of the earlier graphical ideas weren't really up to scratch. and would be a hassle to play with without a serious rethink of how information could be physically communicated to the player.

Robotic characters would loose their sinister appeal if reduced down to more chunky, abstracted parts (instead appearing too cute for the intended mechanics), but are too indistinct with the detail level they are currently at. The level design itself was simply thought of as a random junkish maze with no real personality or set features that could really be exploited visually.

With all this in mind, the art style will now be changed to a Japanese ninja inspired dark fantasy setting, through the intended mood, mechanics and graphical style will otherwise remain exactly the same. The advantages are more immediately recognizable enemies and objects, plus the architecture of the level itself can be made to resemble traditional castle interiors, which are themselves quite boxy and lend themselves to simplistic sprite work.

New sprite sheet;

Each cell is 64 x 64 pixels in size, and the image contains 6 base colors plus a green transparency layer.

Top left; Protagonist character idle sprite. Will most likely just be used for the status screen.

The rest of the first and second row; The new “standard” enemy type, who is an archer. Idle, walking, firing, and projectile sprites all provided.

Third row; A Komuso-style second enemy ninja. Currently idle sprites only. They will be able to attack both in melee and with bombs.

Fourth row; Health potion item, relic stone item, sword item (inventory only), bow item, arrows item. Note the sparkles that will be used for animated particle effects. The relic stones now perform the stat-improving mechanic that “spare parts” once did.

Alternate Palettes;

Through the six-color palette was chosen for visual clarity and similarity to the original style, three major routes are still reconsidered for the overall palette and thus art style.

Simple six color, very high clarity;

Sepia + red six color, looks like a bit like a traditional painting;

Full red “demon-vision” five colors, looks the most like the original idea; 

Several swatches have been created to facilitate testing during continuing developments on the engine. It has yet to be seen which style will permanently stick.

-Curtis W. Jump

[curtisjumpfutureworks]

XB2178 (Games Specialism)

Assignment #2; Sprite Based 3D Shooter Project, Development 12 of Jan to 26th of Jan

The image provided is a level design map for the entire world that the game is intended to contain, including a key. This also uses new simplistic objects such as doors, pylon obstacles and “break doors” that require specific weapons to destroy. Each cell is intended to be three times the size of the player character.

Further research required into how exactly each corridor portion will be constructed, particularly how often weird non-cube shaped examples like the the original engine images will be used. It will be highly modular regardless.

This is the suggested completion route (Which tumblr will not allow to be posted for some reason).

A considerable amount more sprite work and animations need to be finished, which is massively behind schedule. In order to resolve this more rapidly, I intend to hand draw the sprites from this point forward, and convert them into low bit sprites by using using Photoshop CS2. Using several transparent layers with the threshold function should be able to rapidly convert them to a usable format.

Alternatively, a much smaller resolution could simply be used.

-Curtis.W.Jump

[curtisjumpfutureworks]

XB2178 (Games Specialism)

Assignment #2; Sprite Based 3D Shooter Project, Development 22nd Dec to 12th of Jan

Task #1: Art and Mechanics

Currently titled ‘Project Redloft’ for the sake of development, during this assignment I will attempt to create a 3D shooter using simplistic movement and weapon power ups, but also with a grim and heavy atmosphere. It's intended to be half run and gun, and half survival horror, much like the original Doom was when you actually examine it mechanically. Enemies can be very tough and overpower the player in sheer numbers if they do not tread carefully. There is also the constant concern of ammo.

In order to push this into rather it's own vein, Redloft has the player piloting a robot that must constantly seek upgrades to survive. The dark and foreboding visuals are intended to bring to mind the visual style of the Terminator's POV, the up and coming new game Firewatch, and even a little of the ill-fated Virtual Boy, rough game play obviously still takes priority and these values will require a great deal of continuing experimentation to not just look otherworldly but also still retain playability.

Included below are some stock art images taken as research.

Task #2: Sprites

In order to attain the level of detail required, large 128 by 128 tiles were decided upon, rough they are only 4 bit in colour depth. This image is a test mock-up including a character that may or may not be used as the protagonist;

More concretely, the standardized enemy robot type will use this sprite as it’s idle frame, and as a basis for it's animations;

Task #3: Basic Player Physics and Level Design

Originally the game was intended on being programmed in Unity, but multiple experiments have lead me to the conclusion that Unreal is actually far more practical for this particular project. It's not important that the game is particularly compatible with systems other than the PC since it favors a mouse and keyboard setup, and certainly not anything like touch screen tablet or phone controls. It also became obvious that future larger scale projects would require knowledge of Unreal's blueprint functions, and the native shaders can create far more distinct and original visual effects.

The project will not simply use the default Unreal first person engine, however. The current iteration already has it's vertical camera rotation restricted (to make it control more like an older shooter), and model arms are only being left in as a place holder to test the shading effects in different lighting.

Included are (exterior) pictures of a simplistic level mock-up in the current engine, with unfinished experimental lighting effects.

-Curtis W. Jump

References;

The “Doom clone” (fig.1) is the Yeti 3D engine by Derek J. Evans.  

Firewatch image (fig.2) is the property of the developers Campo Santo.

[curtisjumpfutureworks]

XB2178 (Games Specialism) Assignment #1; 2D Horizontal Sprite-Based Shooter Project, Development Week 6;

HShooter Alpha 16;

Fixed problems with player animation and the invisibility of extra player projectile types (they were copying the crooked rotation of the bulletspawner). Added a "fire blockade" object; This sets enemies from normal tile speed to attack speed & allows them to fire, making them easier to place during level setup, and also prevents the player's bullets from travelling beyond the screen. This actually took significant modification of the both the enemy scripts in order to work correctly.

A "universal destroyer" object was also added to the trailing edge of the screen in order to automatically delete all objects which come in contact. They originally simply timed out, but this is not practical for level placement. Bullets now also collide with the terrain tiles. Started on level creation.

Enemy 2's movement pattern sometimes fails to work. Investigating.

HShooter Alpha 17;

Finished the arrangement of the first level.

HShooter Alpha 18;

Finished second level, added an object for triggering level transitions.

-Curtis Jump

[curtisjumpfutureworks]

XB2001 Assignment 1 - UT4 Level Design - Whitebox Progress

The entire map is effectively a singular large additive cube with many small subtractive cubes cutting into it. This is to retain the cavernous feeling, as much of it digs downward quite deeply.

The bottom “trench” section. The walls have not been slanted yet, as noted in the original design idea.

The large “hub” section that makes up the central part of the upper layers.

The easternmost “trench”. Note that the ramps have been turned sideways (away from the viewpoint of the camera), because they were originally too step to actually climb. They tend to lead directly into walls now, which will need fixing once I have time to adjust the space a little.

The “reactor” section below the main hub. Note the dense pillars, and the two “escape vents” that exit from drop-down chutes above.

An additional problem encountered is that some of the corridors leading from the second level up to the third have very tight and awkward turns, again because the ramps would have been too steep to traverse how they were originally planned. These corridors will most likely be completely rearranged later.

-Curtis Jump

[curtisjumpfutureworks]

XB2001 Assignment 1 - UT4 Level Design - Initial Designs

The overall idea for the UT multiplayer map evolved into something that was to thematically resemble a volcano; A large mound of inwardly twisting corridors surrounded by downward sloping plateaus surrounding it as an outside space.

The extremely densely pillared lower sections indeed make it seem a bit like a nuclear reactor, alrough the actual intention was to create a space in which players would have great difficulty discerning where an enemy was coming from, and force them to exploit the tight terrain by using explosive or area-effect type weapons.

Both higher up, outside “plateau” sections have tall sloped walls, but still give enough room for sniping enemies at a distance, particularly when aiming downwards into the lowest parts of the trench, and thus exploiting the compete opposite end of the game play spectrum.

Two small narrow vents which drop down from these top levels, right down to the bottom, are intended to serve as secret escape routes to those who have become savvy in using the map.

-Curtis Jump

[curtisjumpfutureworks]

XB2001 Assignment 1 - UT4 Level Design - Secondary Research

Gathering secondary research images for my UT map was all about taking the original ideas of large, overpowering stone structures and expanding the concept up to it’s logical extent.

One of the difficulties in seeking to imitate an actual cave system directly is not just a problem of crafting organic shapes in UT, but also the practicality of these spaces in terms of game play flow, and allowing the player to understand their location within the world at a glance. They simply aren’t spaces that humans can navigate inside with ease, in most situations.

Actual houses and complexes chiseled directly out of the stone, however, provided an interesting aesthetic somewhere in between.There are many such ancient structures scattered in places like Tunisa, Turkey and South America (particularly the Olmec civilization). Salt mines are another similar situation, where the relatively soft stone can be removed in large sections, but imposing beams must be left intact to maintain structural rigidity.

Images of these kind of structures were useful from a gameplay standpoint in that they gave me a better idea of how to manage “courtyard” type areas even in a dark and rigid cave-like setting, spaces which are actually pretty crucial provide focal points for the map, and give memorable locations to place items (and intrinsically make them good locations for ambushes).

-Curtis Jump