CLICK TO ENLARGE
CLICK TO ENLARGE
CLICK TO ENLARGE
CLICK TO ENLARGE
CLICK TO ENLARGE
CLICK TO ENLARGE
CLICK TO ENLARGE
CLICK TO ENLARGE
Made quite a lot of developments this month. First of all I started to work on some basic artificial intelligence using simple distance and direction calculations between the NPC and the player, I wrapped this into a basic state machine in order to allow other behaviours to be easily added. After this I added a state for fighting and a state for randomly wandering about when the player is not within range. In order to stop the NPC’s falling off the edge of the platform it was necessary for me to add some detection of the platform edge and link this into the AI’s wandering behaviour, forcing them to change direction until they are no longer in danger of falling off. When they are seeking or attacking the player this is not important as zombies are notoriously stupid and would most likely follow a person off the edge of a platform. A problem which still exists in this is that I haven’t added wall detection to the zombies so if they get stuck walking into a wall they may continue to walk into it until they randomly change direction, but this isn’t too hard of a fix.
For each of the npc’s I have attached collision meshes to the limbs used in contact when fighting (head, arms and leg) in order to accurately detect what kind of attack is being carried out and for how long they have been in contact (for harder / varied attacks) in order to apply damage and health. Due to a limitation in the number of different animations I have available I decided in order to make the combat a bit more varied and not so predictable I made it so while the player / npc is in the attacking state and its limb collision objects are colliding with the enemy it reduces health from them, meaning that if you hit a zombie with the ninjas hard attack and you catch them at a good angle the full force of the swing is applied. Also depending on what attack type they have received the AI when attacked receive a force in the opposite direction to what they are facing, and a different attack animation is played based on the attack. A small improvement on this would be to apply the force in the direction of the collision normal as opposed to their direction normal.
The turret I decided to create as I helped someone fix some buggy picking code which inspired me to implement a form of ray traced shooting. It was fairly easy to set up, although I did have some problems with the way newton works and the way I wanted this to work. In order to keep an rigid body still the best way to do this is setting its mass to 0 so that it has an infinite mass, but as I want to rotate the turret smoothly using forces (manually rotating creates serious collision issues) this wasn’t an option. So first of all I tried attaching the turrets dynamic body to a static body of 0 mass via 3 ball socket joints, and then manually rotating the static object, which worked more or less flawlessly, although I did begin to notice some glaring bugs which caused the dynamic body to sink into the ground, so I opted to use the same method I use for moving and stopping my character (applying an equal and opposite force to stop), so if the desired velocity of my turret was to always be 0,0,0 to calculate the force required to keep it still is the 0,0,0 – the current velocity multiplied by mass and time, this worked better than I imagined it to and is much less hacky than attaching to a static rigid body. Attached a cross-hair entity to the end of the turret, basically a specified distance in the turrets local space Z co-ordinate which is then multiplied by its rotational quaternion in order to give the direction, this is essentially how i cast the ray in order to shoot. upon the ray colliding first with a zombie i then apply an attack to it in the same way it is applied when in combat. in addition to this i added a simple particle effect in the same way as the cross-hair in order to simulate muzzle flash, i may add some kind of chaser bullet as well just so you can visualise where it is going.
After I got the layout of the first level pretty much how I decided It was going to be I figured it was time to start making it look a bit nicer with lighting and shadows. I decided to apply modulative stencil shadows, as they where easy to implement, fairly general purpose and still don’t look too jagged on the edges. After much deliberation and stress testing with large amounts of NPC’s I decided to only have one light in the first level (directional light representing the sun) but make it spread across the whole level (I may add some flaming oil barrels later but using omni lights with a very small range). Then using Ogres compositor material frame work I have applied using high level shaders a HDR effect (need to go through and optimise / modify this a lot to get the right look still) to give the level a bit more life and stop it looking dull.
So next up, finish the second and 3rd levels off, this is really a simple case of adjusting what is already there, and adding some more npc’s, turrets and lights. Sound effects which need to be linked into the appropriate physics material systems, the support for audio playback using Fmod is already written and functional so this is more of a design issue than anything else. Sort the sky out so that it is a sphere and not a dome, beginning to get annoyed by the empty spaces under the level. After this it should just be a case of playing around with the artwork (I have no artistic flare but I can still try) and optimise both the code and the shaders (also rewrite / refactor a few and implement my normal mapping shader). Then it will be simply a case of bug fixing, tweaking game play. And overall polishing the front end and usability.
4E6 Engine First Gameplay Test : Febuary Progress Log
CLICK TO ENLARGE
CLICK TO ENLARGE
Over the last month since my last update I’ve been looking into testing out some of the functionality i have spent all this time developing and putting it into practise with some simple game play elements, not too much in the way of functionality has been added except for the addition of an emitter which is capable of being scripted to emit objects at timed intervals, it is possible to create / destroy these via commands. added functionality for the use of a interface plug-in called CEGUI which allows for easy binding of functions to interface elements, and allows me to display game data to the user very easily.
The video shows 2 half finished levels with place holder artwork, the very first level involves the player getting over 2 moving platforms using dexterity, with a very simple puzzle in which the user must push a block up to a platform with a button on it that triggers the moving platform to the exit. I had to overcome a number of problems to achieve this. first of all being the jumping system for the game:
jumping was easy enough, just applying an impulse to the players physics body when the user presses jump. but one problem with this is detecting whether the player is in contact with the ground. i thought of a couple of ways to do this. one of which is casting a ray below the player a specified amount in order to determine if the ground is underneath the player, and another whereby I use the physics material callback between “player” and “floor” so when they collide a flag in the player object is set to “on ground” and every frame is set by the player to not on ground, allowing accurate ground detection every frame. this also presented another problem. when the player is on a object defined as “floor” i.e anything you can walk / jump on it sets the flag to true, all well and good, but if this same object is something the player can stand touching such as a wall it means the player is still able to jump, even if they are in the air, allowing the player to jump multiple times up and over walls. i used a little bit of maths to solve this issue in the material callback. so upon collision i obtain the contact position and normal of the collision, normalise it get the dot product of the resultant vector and the players normal (0,1,0) and then get the inverse cos of this, after this it is simply a matter of determining if the angle obtained is the right angle for a player to jump from.
another small issue that was fairly easy to resolve was if the player is standing next to a platform / block that they wanted to jump on and they where not moving to begin with it meant that there was no velocity applied to jump on top of it. i resolved this by adding a small amount of forward force to the character if they are in this situation.
the second level in the video entails the user getting to the top of the ramp in order to progress, but i have set up a number of emitters to emit spheres with a really high mass that can knock the player off the level hence forcing them to start again. to begin with it didn’t knock the player off of the platform due to the way that stopping force is applied to the character when on floor in order to correctly stop (as opposed to using friction to stop which is unrealistic). this meant that i had to add a call to the characters jump function on collision with one of these spheres, allowing for more of a challenge mode of play.
i was also presented with a design problem in this level, with lots of spheres if you do the level the first time it is an appropriate level of difficulty as the balls hadn’t yet got onto the bottom platforms by the time you where passed that, but if you got knocked off on the way up the ramp it was near enough impossible to complete (as you can see from the video) , i resolved this by extending the bottom section of the level by a significant amount and reducing the emit rate of the spheres, this made it a constant difficulty for the whole level.
4E6 Engine First Alpha Build, Feature Test : January Progress Log
Since my last update on the Destinatum Engine project I was recently given an assignment at uni to do pretty much what i was working on but using the Open Source Graphics Rendering Engine (Ogre : http://www.Ogre3d.org). in summary it is basically a scene graph for graphics rendering. fortunately the way it works is not too different to that of Destinatum Engine so porting the functionality across has been fairly painless, it was very easy to reintegrate all the work i did with the Newton game dynamics physics api ( http://newtondynamics.com ) through the use of Walaber’s wrapper for it ( http://walaber.com/ ), meaning i didn’t have to reinvent the wheel so to speak.
in addition to this i have added a number of new features:
Scenes are now fully editable in 3D studio Max, where as previously the objects needed to be exported seperately before positioning them in the scene via editable text files. this is carried out using an exporter called “OgreMax” which exports to Ogres native mesh format with a lot of scene specific stuff saved into XML format, particularly scene animations, transformations and lighting. making it very easy for me to manage different in game levels. physics data is still edited via text file, but this is flexible enough to group similar objects with similar characteristics.
I’ve been experimenting quite a lot with shading languages looking at different rendering techniques, particularly the use of bump maps, normal maps, and a similar but relatively unheard of technique called parallax mapping, which are all very nice ways to get high quality detail on low polygon meshes using the programmable pipeline of all modern shader capable graphics cards. also demoed in the above video is a demonstration of the use of shaders for applying post effects to the rendering in order to give different looks for different situations i.e under water, behind glass, watching something on a old movie tape. the transition of these is controlled by the scripting system i developed (which i will get to in a minute). a list of the effects demoed in this are listed below, and have been implemented using Ogres materials / compositor framework.
Old Tv, Bloom, Glass, Black & White, Embossed, Sharpen edges, Posterize, Laplace, Invert, Tiling, Old Movie, and HDR. these are all really place holders for final effects as im still undecided about a lot of specific elements and reasons for using certain post effects.
when eventually starting to bring a lot of elements together such as sound, post effects, video playback, scene animation, various game play tasks i realised that it would be much easier if a lot of the logic was separate from the Engine / Framework. and would allow for easy modification of game play. so i started off writing an event handler which receives input in the form of a string of a commands, this is then processed and passes all its messages to the appropriate game object managers. this has allowed me to develop a very flexible scripting system whereby it is possible to type commands into a console window and execute them, but also assign commands to Newtons material callbacks in order to allow triggers to execute various game play elements such as changing level, playing video / sound, spawning objects etc etc etc. i eventually found i could flexibly execute timed sequences in this way by creating a Script class, that reads in a list of set commands each with a time to execute in the sequence so a trigger can execute a script file and effectively allow for a multitude of game play elements to be triggered from this.
Using the scripting system i devised, I’ve made it possible to attach objects to various nodes of a character, as shown in the video it is possible to pick up an object and throw it (the artwork doesn’t really do it any justice), and also attach the camera in order to track the thrown object and move the camera back to the player when it lands
In the next update I should hopefully be bringing a lot of this together into some basic game play scenarios in order to test that everything works well together and iron out any glaring bugs.
CLICK TO ENLARGE
CLICK TO ENLARGE
CLICK TO ENLARGE
CLICK TO ENLARGE
CLICK TO ENLARGE
CLICK TO ENLARGE
CLICK TO ENLARGE
CLICK TO ENLARGE
