Posted October 17, 2021 by GMunro
Looking back at my concept devlog, I am surprised at how similar the game turned out to be to the initial concept art. Obviously, a few small design choices changed here or there, as well as the huge gap in general polish, but the overall appearance turned out as I had apparently planned.
Most of the changes between the concept and final game were due to time constraints barring them from any development time. Most of these ideas and features are still planned, but having now fully grasped the entire scope of what the concept devlog had planned, It will definitely take some time to achieve them all.
“Awakening in a cold and dimly lit room, our hero picks up the rusty sword by his feet and ventures forth into the unknown. As his journey progresses, and he moves deeper and deeper into the abyss, he starts to lose interest in his own freedom, and soon enough his only drive is vengeance and glory.”
The story and setting elements within the game have obviously fallen to the wayside, however I didn’t originally intend for the story to be front and centre, but rather something crafted by the player themselves; their current attempt at the game IS the story. The devolution of his character to a bloodthirsty barbarian over the course of the story somewhat came to fruition in the end arena, and only partially on accident I would argue.
“Upon impacting a victim, weapons and thrown objects use a variety of calculations to deal realistic damage according to how and where the impact occurs, as well as figuring out how your weapon will react to hitting its target. Will your spear get stuck in the goblin you’ve just skewered, causing his companions to swarm the now vulnerable you? Can you cleave cleanly through the horde of ghouls before you with your greatsword, or will it lodge itself in the first one’s head? Dark Testament forces you to prepare and think about every engagement, lest you meet an earlier end.”
My end goal in further development is most definitely still aligned with this sort of system. As the physics matures from further development, I plan to reach a weapon physics system as close as possible to this. The removal of the “weapons stick into enemies” effect was purely out due to time constraints.
“Sometimes, maybe fighting isn’t an option. Some areas may be separated by sturdy doors, which you can try to barricade with the furniture around you, it might save your life. You could also kick a barrel into your pursuer, stunning them long enough to deliver a vital strike.”
You can definitely see the remnants of this in the starting area, particularly the door with the barrel behind it, having been attempted early on and then put to the side indefinitely, however the final game lacks any of the gameplay impact of them due to the goblins almost never even touching the barrels. Physics environments are 100% still a goal in future development.
“In Dark Testament, death is almost certain, but it isn’t necessarily the end for you.
With each attempt, you carry on the lessons brutally taught to you, and you can unlock new and exciting weapons to find in your next run at the same time, each with unique and different properties and attacks for you to exsanguinate your foes with.”
The permadeath currently does exist, but given the shortness of each run, it’s not really permadeath in that death doesn’t really matter that much yet. The lack of progression mechanics is symptomatic of the lack of things to unlock, due to time constraints of course.
This section of the concept devlog included some of what I originally wanted some of the weapon sprites to look like, when I was still considering pixel art. The stark contrast between the pixel art and the vector character is quite foretelling, considering the path I eventually took by using vector art. All of the weapons listed will eventually be implemented, since they are all so easy to make and nothing is really lost by adding as many weapons as possible.
“Each level presents new foes for you to paint the room with. The first you come across won’t be much of a problem, but as you go deeper, you better start watching your back. Enemies planned include but are not limited to:
Ghouls – Dumb as rocks, but always a threat, especially in numbers
Goblins – Small and weak, working together to bring you down
Stalkers – The darkness plots your end
Demons – Large and extremely dangerous, good luck!”
In the final game, only the goblins made it in. Although I originally planned the ghouls to be in the prison level, given that I quite quickly (albeit not permanently) had to curb the possibility of multiple levels, I chose instead to bring the goblins into the prison level, to perhaps show off some advanced AI in them rather than the intentionally dumb AI of the proposed ghouls. Additionally, the possibility of more interesting artwork of the goblins was enthralling, over the generic grey zombies that the ghouls would have been. Later development will most likely rearrange the goblins to later levels reflect the concept devlog more closely.
“Each level is procedurally generated, using pre-made rooms connected together to form a continuous set. Each room may have a dozen enemies, or none. As you descend, prepare to paint the walls of:
The Prisons – Ghouls by the dozen, how long have they been here?
The Caverns – A nest of goblins, tread carefully
The Outskirts – You aren’t the only threat to the goblins
The Cathedral – An ancient cathedral, all the candles have long since burned out
The Abyss – The cathedral was built for a reason; containment”
Obviously, only the prisons exist at the moment, given the time sink that was the tile artwork barring further development of the multitude of different tile sets each level would need. Having the underlying systems for the generation developed however, adding future levels wouldn’t be too difficult in future development.
“The player will be controlled by the keyboard (WASD) and mouse, with each mouse button readying one of two attacks for each weapon when held, and attacking once released. When the player presses a movement key, the character is moved based on an applied force, meaning they can push and be pushed around by physics objects.”
The only difference between the proposed controls and what the game has now is the temporary dropping of the second attack for each weapon, something I will implement later in development for sure.
“Dark Testament uses dense 2D pixel graphics combined with an array of techniques such as:
Normal mapping – Pseudo-3D shading effect for extra detail
Tiling – Rooms are made up of individual tiles
Lighting – Realistic lighting and darkness, also included in gameplay elements
Particle effects – Sparks flying, dust billowing
Physics-based animation – Arms made of segments, less animating to do
Gore system – Bodily damage throws chunks and sprays blood according to the impact, blood stains the environment after landing”
Following the trend of “it’s not done yet, but it will be” present thus far, most of these effects are still planned. The complete change in philosophy from pixel graphics to vector artwork hasn’t cancelled any of these planned features. The tiling, lighting, physic-based animation(mainly on the player legs), and the blood spraying is all present in the final game. The normal mapping has some presence, but in a more subtle role of giving depth to the floors and walls, also the rocks in the start area doorway. The gore will definitely be expanded upon in future, but I am seriously satisfied with what I already have.
The vector artwork used in the original concept statement was done purely to save time, but vector art, when expanded upon, can create amazing game artwork, and is infinitely more flexible than pixel artwork. My choice to fully move to embrace the vector artwork was a decision I believe makes my game stand out amongst the sea of identically unique indie pixel art games we see today.
Many sounds will be custom recorded for effects such as:
Physics/weapon impacts
Player/Enemy noises
Ambient sound
Footsteps
Weapon interactions
Other sounds required that may be sourced elsewhere include:
Game music
Gameplay sounds – blips and beeps related to gameplay if needed
Anything else
In the end, all sounds I used were made by me. I have achieved every category here except the music and the footsteps. I forgot the footsteps. Oops.
The feedback received over the course of development as well as the testing session has certainly influenced my game in a significant way, however I fear that I perhaps have not taken enough of it on-board due to my prioritisation in getting the game’s pre-requisite systems and features implemented on time as a result of my horrifically over-scoped project. I definitely plan to invest significant time into fulfilling a majority of the feedback (within reason) after the end of semester, but for the time being, many of the suggestions have fallen by the wayside in the assessment build.
Much of the feedback received on Discord was overall very positive, with most suggestions centred around small bugs encountered, as well as the quirks emerging from people playing with the demonstration features such as the shunt action. Overall, most of the feedback from Discord were ideas already in the pipeline, but not quite implemented or fleshed out yet. The encouragement however was vital to pushing me to get this completed.
The first suggestion to be fully implemented was the Lindsay movement mode, also referred to as the mouse-rotational movement or rotation-based movement mode. The idea of having it was purely that of Lindsay’s and it wasn’t too difficult to implement and keep, so it is still in the game.
While it worked quite well in the early stages, it became quite difficult to use immediately upon adding the smooth camera system. I might make some specific improvements to it in future, however after receiving the feedback on it from the testing session, it definitely isn’t a priority.
One major change made in my game based upon discord feedback was in the art style. Originally, I wanted to use the standard indie pixel art style, however after finding that I could achieve great quality vector artwork using Adobe Illustrator, I decided that I would go with high quality vector artwork instead.
Michael later pointed out a visual bug with the torches, in which the player moving over them would encapsulate the light source, but not cover up the particle effect.
This has been somewhat fixed via moving the torch particles below the player. While this isn’t exactly realistic, the scripting I have in mind to fix it would take some significant time to work out.
One other piece of feedback was to add a loading screen while the rooms generate, to hide the lag. I have added it accordingly.
The last significant feedback from Discord was from Lindsay in that I should consider making the weapons no longer collide with the walls due to the annoying physics associated with it. While I don’t think making them no longer collide with the world would be the best solution, I do understand that the weapons sticking to the environment certainly is a problem. My solution, which I will implement in future, would perhaps focus on incremental improvement of the physics system to mitigate the annoyances, such as making the character sense walls close to them and move their weapon away slightly, as well as just better detection for stuck weapons. Another option is to make them only collide when attacking, however that causes other issues such as being able to move the weapon through walls before attacks, and then having them stuck behind them upon initiating the attack.
Another small suggestion was from Hayden, who suggested adding a katana, which I did shortly after.
The testing session gave me ample quantities of information; however I feel that the severely underdeveloped enemies and lack of gameplay elements in general in the testing session build significantly reduced the resolution of the information gathered. Furthermore, much of the more extensive feedback provided had to be put on the backburner in pursuit of getting the game into a more finished state.
The results of the testing forms were a mix of both confronting and comforting responses. Overall, impressions were good, and most people understood that the enemy AI was placeholder and incredibly underdeveloped as was noted everywhere possible, however some questions asked by the form were consistently misunderstood by the responders regardless.
Over the course of developing the weapons systems, it was suggested repeatedly to increase the speed of the weapons, which I did each time, I hope they are fast enough now.
People also seemed to like the art style a lot, which further enforced my decision to move to the vector art style. The advanced lighting also helped bring it all together. Maybe three questions was too many for one topic.
Most of the negative feedback, sans Lindsay-movement jokes, was about the enemies, which, as mentioned, were temporary and I knew they were garbage. The response mentioning the weapons controls seemed apt, as the weapons were quite sluggish at the time, and they have since been improved unfathomably so. It was also somewhat confusing, which has been improved a bit throughout the further development.
The physics system seemed mostly popular, and the player movement was like by all but one for some reason.
Looking back, asking the question about what people had looked forward to seeing was vain and pointless, but I am glad I didn’t make it mandatory.
The responses regarding the weapon mechanics were quite mixed, but given the awful state they were in at the time, I don’t blame them. I am surprised that the combat gameplay question scored better than the weapon mechanics question, considering the state of the goblins at the time.
The weapon suggestions definitely had a recurring response, that of ranged weapons. Obviously, barely scraping by with the weapons I have now, I had no time to implement any ranged weapons yet, nor did I have time to implement the melee weapons. The giant broadsword, flail, and the large list at the bottom will all be definitely implemented eventually. My theory regarding the ranged weapons is that the interest for them comes from the goblin enemies from the testing build, which were quite fast and would hug the player to death, making them difficult to kill. The wanting to engage from afar most likely comes from this issue. I do want to eventually implement both ranged player weapons and ranged enemies, but the systems for them are yet to be conceived.
People seemed to be content with the current speed that the game had, despite complaining about the sluggish weapons and in one case sluggish player movement. I have kept the gameplay mostly around the same sort of “speed”, but any change would most likely be for beneficial reasons.
Responses regarding the level generation showed satisfaction. They did urge towards the levels being too long (1 being too short, 10 being too long. The title is reversed, my bad), however the lack of reason to reach the end of them no doubt contributed to that. After adding the arena, I reduced the number of rooms from 12 to 11 regardless, as after adding the arena, this metric is most likely inaccurate now.
The reports of level generation bugs and performance metrics showed things were mostly okay. I will definitely always be working to improve performance, but it seems to run quite well now, so I am not overly concerned.
The only bug report unanswered for was in regard to the lighting, I couldn’t replicate the bug he brought up, and it seemed to be an issue on his end possibly. Really not sure on that one. The one regarding enemies was a result of my shoddy coding, and has been fixed as part of additional development.
The request for larger, elaborate suggestions yielded gold. Many of them are related to just later development, however the player feedback-related responses revealed to me that I should definitely focus on the combat system and player feedback from it. The game now having blood effects, sound, enemy pushback etc were all part of addressing this. The request for HP regain methods was fair, but due to running out of time to introduce more physics props, which could in theory drop medkits/health potions, I opted for the simple health regen system.
The question regarding the target audience yielded obvious results, the main benefit was in that it separated the lone female responder’s answers from the others, providing me specifically with a distinctly female perspective on my game. The results were positive and unoffensive.
The final two questions yielded yet more suggestions, more specifically late-stage development focused elements. All of these will be built towards in due time. I’m happy to see the $15 range being so large, but I’m sure if I mentioned more specific features in the question title, I could have significantly altered the outcome one way or the other regardless.
Given the ridiculous amount of posting I do in the unit Discord, I got far too much disjointed feedback to organise and directly respond to, however the encouragement from the discord posts were a fantastic influence on my game, and even more so my drive to work on it.
Parent player character object – Contains player torso, as well as the current weapon being held. Doesn’t do much else. While not actually a prefab currently, it is still the most important object in the game, so I’ve included it anyway.
Main player control/physics object - Contains player movement and inventory scripts, contains head (looks towards cursor), both pauldrons (purely aesthetic), both legs and feet (move when player walks), both hands (until a weapon object is equipped), right hand guide (guides the movement of the weapon), and left hand guide (unused, will be used for offhand weapons in future).
Upon equipping a weapon, a prefab variant of said weapon will instantiate as a child of the player parent, bound via physics to the right hand guide, and the right hand (contains WeaponHandler script) will become a child of the weapon. Each weapon prefab contains different colliders and sprites according to the weapon type/shape, the shimmer effect object, and the WeaponInstance script. Weapon stats are determined by the associated Weapon scriptable object.
Goblin parent object, merely contains the torso.
Contains goblin physics, movement controller script, and AI script.
Each and every room contains separate tilemaps for the walls, floor, static props, and the ShadowMap, which contains ShadowBlock objects in order to properly handle lighting. They also contain the RoomPerformanceSwitcher script, which toggles ShadowBlocks on and off to save performance when the player can’t see them, and the RoomConnector script, which handles generation.
Starting room, in which the player wakes up. Contains a door and some barrels, as well as a couple of the rock1 instances. Will spawn the first procedural room to its right upon starting.
Room prefabs used in the primary procedural generation stage. There are currently only 4 variations, however many, many more are planned, and mostly easy to make. Using the RoomConnector script, they will attempt to spawn a new room connected to one of their openings, which will then spawn its own, and so on until the room limit is reached. Upon reaching the limit, the final room will declare itself, and spawn the arena room. After the arena is validated, side rooms will spawn on some of the generated rooms. Next, it will make every room re-check for any collisions or overlaps, and if any are detected, it will start over and try again, otherwise, it will begin checking for doorway connections, sealing off any doorways that don’t connect to anything.
End-of-level arena in which the player fights an endless horde of goblins until they die. Also contains an instance of the ArenaDoorTrigger prefab.
Shadowblocks are simple objects just containing a ShadowCaster2D. They are placed manually over each wall section to have them properly cast shadows, and in a more efficient manner.
The DoubleChecker prefab is instantiated upon a room finishing initial creation, used upon the second collision check for the rooms for the sake of reliability.
Contains the collision box and the script for the arena door trigger script, which closes the arena door upon the player entering.
Contains PrisonTorchHead prefab. Different parent prefabs used because of slight difference in offset between rotations.
Head object for each torch, allowing control over effects without changing each torch tile. Generates light and particle effects to appear torchly.
Simple impassable rock, used only in the start area. Contains cool normalmap material.
Currently the only physics prop, can be moved around by the player and goblins.
Contain particle spawners which emit blood particles as well as play the blood splatter sounds. Blood particles will spray out depending on impact velocity and will land convincingly onto the floor, and remain there for a while.
Spawned by goblins as their attack, player will take damage upon collision.
Exists on each weapon, will play a short glinting animation upon the weapon being ready to swing.
While also not prefabs, they are vital to the function of the game.
The director object is the core manager of the RoomSpawnControl script, as well as the AudioDirector script and the Camera Director script.
Contained in the canvas, controls the heart beating UI effect as well as keeping track of the player’s health and player death conditions via the HealthDirector script.
The health director stores and manages the player’s health status, as well as controlling the heartbeat animation. Upon reaching less than 25 percent health, a timer will start, after which it will begin to regenerate up to 25 percent health.
Controls player movement input and physics. Uses forces to move the player smoothly and with physics ability. Uses code from https://answers.unity.com/questions/813087/2d-addtroque-towards-mouse-position.html to avoid the player rotation snapping around upon passing 360 degrees. Additionally, it controls the player’s legs and feet to move realistically as he walks.
Controls rotational movement of the player’s head. Also uses code from https://answers.unity.com/questions/813087/2d-addtroque-towards-mouse-position.html to avoid the head rotation snapping around upon passing 360 degrees. Tries its best not to look behind the player, doesn’t always succeed though. Rotates at a higher speed than the player body, to emulate realistic human movements.
Located on the legs, this script moves and switches out the sprites on the legs when moving in front of and behind the player. Almost gives the illusion of 3D.
Controls the smooth look-ahead camera movement. Situated on an empty object that is always following the cursor, it places another empty object on a point between itself and the player, with a maximum distance allowed away from the player. This allows a smooth look-ahead camera that limits the range the player can see.
Controls the initial zoom out and fade-in of the camera at the start, and nothing else because I just put the gameover events on the HealthDirector instead for some reason.
Base script for Weapon class. Contains details regarding a weapon’s sprites, effects, damage, and swing parameters.
Player weapon inventory management system. Calls to WeaponHandler to equip a Weapon. Randomizes weapons given to player at the beginning. Also manages weapon input control.
Placed on the player’s hand object, controls the attack states of the player. Also manages sounds for the weapon functions and the shimmer effect.
Handles the physics calculations for the weapon, guiding it towards the player’s HandGuide object. Also manages impacts from the player’s attacks.
Deals with the Shimmer object on weapons, causing them to rotate in place as well as do a short glint upon command.
Situated on the head and shaft of each weapon’s respective colliders, these are used to initially detect collisions with enemies, to differentiate the impacts happening between the head and shaft of the weapon.
Manages the movement and physics of the goblins. Takes an input desired position and look-at position from the AI script and moves/looks towards it in a physics-based manner. Also uses code from https://answers.unity.com/questions/813087/2d-addtroque-towards-mouse-position.html to avoid the rotation snapping around upon passing 360 degrees.
Controls the head rotation to point towards a look-at position provided by AI script. More or less the same as the player’s head movement script. Also uses code from https://answers.unity.com/questions/813087/2d-addtroque-towards-mouse-position.html to avoid the head rotation snapping around upon passing 360 degrees.
Main brain for the goblins. Checks if the goblin can see the player and if they are within range. If so, they will move towards them. Upon getting close enough, they will begin attacking the player. If in the arena, will always move towards the player. Attacks will spawn instances of SwingEffect to damage the player.
Situated on the SwingEffect objects, these ensure that the player is only hit once by any particular swing.
My nemesis. This component, present on every room, is how a room decides where and how it will spawn a new room connected to it. Explained extensively in the room gameobject description.
Director script for the room generation. Manages the after-generation checks and side-room spawning. Used by many scripts to determine when to start based on this script’s current status.
Script that determines what objects will spawn in a room after generation. Currently only spawns singular goblins, but will in future spawn physics objects and such as well.
Switches the shadowboxes of a room on and off depending on how far the player is from it, in order to save loads of performance.
Used in the arena. After the player has entered, it will begin spawning ever-increasing waves of goblins for the player to fight, increasing in difficulty based on how many kills the player has.
Used by a trigger to seal the door and begin the arena upon the player’s entering.
Similar to the RoomPerformanceSwitcher, this script dims lights upon leaving the player’s sight. Significantly less performance gains though.
Like the TorchHeadDimmer, this script pauses or plays the torch particle effects when outside the player’s sight.
Changes a torches brightness based upon input from LightNoiseMaster scripts.
Working upon the dictionary definition of “master”, it causes the LightNoise script in a light object below it to flicker based upon its randomised output.
Stores all of the game’s sound effects for scripts to draw from. Probably a terrible idea, but it’s easy to manage at least. Also contains the global volume modifiers, as well as handling the ambient audio control. It can handle fading the ambient audio in and out, as well as easing between the quiet and intense ambient sound channels as the player loses health.
A generic use-all script for physics objects, this script detects collisions and compares the physics materials of each collider, and plays the according sound with the volume based scale to the collision velocity.
Plays the splash sound effects after a delay for the blood effects.
Located on the title screen, does basically the same thing as ResetButton except prior to death.
Manages the infinitely scrolling bricks on the title screen background.
Manages the Generating Level… animation on the loading screen.
Originally used shamefully for an object reference, PointerOne is now used for moving the kill count to the middle of the screen upon death in the arena.
The reset button reloads the entire scene upon activation, so the player can die again.
Solely used for the physics collision sound scripts, all identical other than names.
Franklin Gothic, source: https://www.cufonfonts.com/font/franklin-gothic
Pre-baked artwork also uses Franklin Gothic, although provided directly by Adobe.
For pretty much all of the audio code, before playing a sound, the pitch is randomized to give an infinite number of variations for each sound. After, a random sound from the specific type is played.
Every sound present in the game was either recorded by me or generated in Audacity by me.
Sounds played when player equips weapons, different sound based upon weapon parameters.
Sounds played upon player finishing readying the weapon.
Sounds played upon player swinging weapon. There aren’t many because I whacked my microphone really hard and decided that three was enough.
Sounds played upon hitting enemies. Goblins also use them for hitting the player. The arena door closing sound uses a random SharpHit sound.
Sounds are played dependent on which physics material collided with which, and the names for each reflect this.
Water splashing onto my kitchen floor. Used for the blood effects.
Ambient sound generated from a 0.5 second clip of brown noise stretched out to 2 minutes and then reverberated, all using Audacity. Generates an eerie cave ambience from scratch. As the player loses health, the health director interpolates in volume between AmbientQuiet, which has most of its high notes filtered out, and AmbientIntense, which has had the treble cranked up as if to scream at the player. Keen to develop this further. Fades in at the start.
Uses the Axe 1 sprites, hits like a truck.
Uses Sword 1 sprites, incredibly fast to swing but lacking in damage.
Two handed, uses Spear 1 sprites. Great long-range damage, but sometimes tricky to aim.
Added upon request, two handed, uses Katana 1 sprites. Very fast ready time, but slower swing and recovery time. Swings from the left instead of the right.
Almost all sprites in the game were made in Adobe Illustrator, with the exception of the Noise and PlateNormal materials, which were made in Rhino3d.
Under this heading, anything regarding tiles imported as spritesheets will have both the specific tile names/numbers as well as the original spritesheet titled.
Main body piece of the player character. Designed to allow for pauldrons to be removed for future gameplay features.
Player’s head, designed for easy visibility of the head’s direction
Shoulder armour pieces. Future developments will allow them to break off upon absorbing a hit.
Player’s feet, plate boots basically.
Symmetrical textures so used on both calf objects. CalfSwitcher script swaps between the two sprites as the legs pass under the player’s body to give impression that the player is walking.
Used for the hands. Unfortunately didn’t get time to do the hand sprites, would have take significant time to do. Still looks mostly ok though. Credits to Unity of course.
Idle poses for weapons, used when player is in idle state.
readying poses for weapons, used when player is in between idle and ready state or recovery state and idle state.
Attack poses for weapons, used when player has weapon ready or is actively swinging the weapon.
Icons for each weapon as used in the HUD weapon boxes
Decided to make the goblins look like a mix of rats, lizards, and dogs, as well as the classic long-eared goblin of many fantasies. Given they are limited to scavenging in caves, their bones protrude noticeably and their spines are pronounced.
The main goblin torso sprite, in idle stance.
Goblin torso in ready-to-attack state.
Goblin torso after swing. Wrist bones for losers.
Goblin head sprite. Each hair on their head is an individual spur, planned future goblin types will put emphasis on these.
Stemming from the singular spritesheet PrisonSheet, there are 35 different tiles and ruletiles for the walls (the ruletiles simply act as regular tiles after having their deprecated shadowboxes removed). Missing all but a handful of configurations, it is quite extensive, however I am keen to replace it as the files for it were poorly planned (by me) and are horrible to deal with.
The primary flooring tile for the time being. I forgot that interleaving bricks was a thing while I was making them, hence the square grid layout. 9 tiles total, all contained within a randomiser rule tile which at this stage I am too terrified to rename. Each tile is basically a grid of 4 x 6 bricks with the inner 8 tiles slightly randomly moved. Keen to redo them to make them a bit nicer, as well as add in some large dirt patches or perhaps broken areas via another rule tile.
Ruletiles for the torches, which enables being able to paint them in directly from the tilepalette without any issues. All are identical barring rotation.
The FadeTile is only used once to fade the starting rocks area into darkness to hide the sharp cutoff of the wall segment.
Used for barrel props.
Used as diffuse map for Rock1 prop.
Experimental normalmap used for Rock1 prop. Gives the prop a 3D look.
Sprite for wooden door in the start area. Will eventually be placed randomly between rooms, but ran out of time for now.
Used for all blood particles.
Lens-shaped normalmap for blood particles, gives them a mild 3D shine to them, but hardly noticeable.
Ember is currently used for the torch particles. Emberwhite isn’t currently used, but will allow for any colour of flame in future where needed.
Used for bloom effect around torches for cheap. White by default for multi-colour use.
Sprite used for the weapon shimmer effect.
Sprite used for the goblin attack object. Rudimentary.
Random sheet of normalmapped noise. Used on walls and floor tiles to give them the mottled look.
Human heart graphic for player health area. Beats every second or so, will speed up and turn dark red as player loses health.
Background canister for health bar to fill.
Health bar filler. Noisy texture generated via randomly arranged lines with red shadows below them, turned out well, only killed illustrator one time.
Backing of the weapon inventory box, used when boxes weapon is not selected
The idea of the “Prison” designation is to have differently themed boxes for different levels, obviously not in the game yet.
Backing of the weapon inventory box, used when boxes weapon is selected.
Brick frame to go around box backing in order to hide weapon icon overhang.
Baked shadowed number for which key to press for weapon 1. Franklin Gothic font, Adobe provided.
Baked shadowed number for which key to press for weapon 2. Franklin Gothic font, Adobe provided.
Used for certain UI elements. Just a transparent 64x64 sprite.
Dark Testament title graphic, used in Title scene.
Brick scrolling background used in title scene.
Simple text of “Generating Level…” in which each stage is a different number of dots.
Mostly the same, some used for adding normalmaps to otherwise boring objects.
Used for torch particles.
Used for props, does nothing yet.
Material used for the gore particles, to add normalmapping to them.
Used on the player, doesn’t do anything though.
Material used for Rock1 prop to add normalmap.
Used for adding noise normalmap to floors.
Also used for adding noise normalmap to walls.
Title screen, just a start button and scrolling background
99% of the game happens here.
Dark Testament opens with a straightforward title screen. Simply click the “START” button to begin.
The player will then be met by a momentary “Generating Level…” loading screen.
In Dark Testament, you awaken in a dimly lit room to find yourself trapped in the halls of a harrowing dungeon.
To move around, use the WASD keys to move up, left, down, and right respectively. Use the mouse to look around. Press E to toggle between the directional movement mode (north, south, east, west) and the mouse-rotational/Lindsay movement mode (forward, backwards, right, left)
You can push physics objects such as the door to the right with your player’s body.
Using the two weapons you have awoken bearing, slash and stab your way through the dungeon to the end of the labyrinth. You will be randomly given two weapons to switch between at the start of each run. There are four total weapons currently: The axe, spear, sword, and katana. Each weapon has different stats, animations, and handling properties.
To equip a weapon, simply press the 1 or 2 key on your keyboard according to the two boxes at the top of the screen.
The literal heart next to them represents your current health status. If the player’s health is reduced to below 25%, after a short while, it will begin to regenerate up to that level.
Once a weapon is equipped, the corresponding box containing the weapon will be highlighted, and you will see your player holding the weapon in their hand.
To ready an attack, hold the left mouse button until you see the weapon shine and hear the accompanying sound.
You can then release the left mouse button to let loose your fury. Depending on what part of the weapon makes contact, a specific sound will be made, and different damage will be inflicted. Hitting an enemy with the handle of the axe for example will do very little damage, and make a dull “thud” sound rather than a clean slice.
After your swing has finished, your weapon will return to the idle stance after a short period.
Using this knowledge, make your way through the level, dispatching any foe that stands in your way.
Be warned however, at the end of the road awaits an arena, in which your glorious end will inevitably be upon you.
Once inside the arena, there is no turning back, and you will be fighting the goblin hordes for the rest of your recently truncated life.
As your health decreases, you may notice a slight headache. Depending on the player’s current health, the ambient background audio will transition from a quiet murmuring to a screeching symphony. Press M to mute or unmute this if you so desire.
Once you have died, simply click the “TRY AGAIN” button to begin a new run.
Dark Testament uses an extensive physics-based weapon system, in which the player must plan and think for each and every swing of their weapon. Weapons will physically collide with the world, meaning that the player must consciously manoeuvre their weapon around the environment, or else risk missing their attacks entirely. A sword may be good for open areas, but a tight hallway provides little arm room to swing it in. While a spear may not be the most devastating to grouped enemies, you require less room to stab within a narrow corridor.
The choices of how the player uses each of the four weapons will determine their fate. Sticking to the side of a corridor to allow yourself room to swing can save your life in many situations. Taking it slowly will also increase your chances drastically.
Additionally, the physics system utilizes a sound system which gives each object a realistic, custom-recorded set of sounds to use for physics collisions.
After the maze you will find yourself in will be randomly generated at the beginning of each run. There is a main “pathway” of 11 rooms leading up to the arena, with scattered side rooms attached to some of the main rooms. In some cases, the generation system may detect that some rooms are connected despite not being connected by the main pathway, leading to fascinating level layouts.
There aren’t many different room types at the moment, however many more are planned to be made.
Dark Testament currently contains only the Goblin enemy.
Their intelligence right now is limited, but certainly not basic. Upon spotting the distant player, they will look towards them, waiting for the player to get closer. Once within range, the goblin will chase the player, until they or the player are dead, or until they lose sight of the player. Dodging their attacks is easy, but they can be lethal in large groups.
Temporarily in the game for ease of testing and evaluation.
Press H to give the player some more health.
Press J to damage the player.
Press T to teleport instantly to the arena.
Press N to zoom the camera out, and M to zoom the camera in.
Press K to mute or unmute the ambient sound
Press B to reset camera zoom.
Enjoy