Editor, Octree, Quadtree, Terrain, Portal culling

I am working on the Octree and Quadtree implementation first using generics so I only have to make each once.

When this is complete, I will work on overloading the Model processor so that vertices are loaded for creation of a bounding sphere and AABB.

Afterwards I will Start work on the ingame editor so that levels can be made easily.
This will allow me to load the level placing each object with the correct scale, position, rotation, and effects.

When I can make levels, the bullets will start flying again accurately.

After bullets are flying, animations and sound will begin leading to a more complete game.
I hope to begin february with some AI development.

Culling and Optimization

I mentioned a method of culling scenes based on what room you are in and what rooms you can see from that room, in my interim report. Unfortunately, that is how I described it. The method is actually known as Portal Culling.

I know that it is used in Fallout 3 and should have searched that for details.

I found a video on youtube today which confirms what I wanted to implement. If I can do this then rendering and collision detection in my game will be awesome! (this discovery is one which boosts confidence for a decent game to be created.
http://www.youtube.com/watch?v=Tviftgg1jMI&feature=related


I said in the previous blog that today will be implementation of a quadtree heightmap which will be done followed by an octree for the scene objects and portal culling.

I still need to find a method of displaying dynamic objects without having to constantly rebuild the scene octree. One solution could be to implement a secondary tree for dynamic objects or to sort objects by room. That is for another day.

Riemer Tutorials

Today I did the first two 3D riemer tutorials. This involved Height mapping and a simple flying game with quaternan camera.

I did the tutorial to learn more about working with vertices and making a height map for the game.

I will take what I learned to make a heightmapped level tomorrow which a character can walk on at correct heights. The player will also not be able to leave the game area. I will introduce a quad tree which stores the heightmap data to check collisions with it efficiently.


Once that is done, I will make it so that bullets can collide with the heightmap.

This will lead onto object collisions, loading models with vertices and checking detailed collisions with them after bounding object broad phase checks.
Octree development will begin to optimize the scene for collisions and drawing with objects scene objects being added by their AABB


The game problems from previous blog posts have been fixed. Improvements still need to be made but the ability to interact with the environment is the most important aim right now.

After collisions are satisfyably complete, I will add more objectives, animations, sound and begin work on AI. AI development should have begun a few weeks ago but the fully working game as a base was more important.

Turns out that a problem that was stopping my models drawing was seting their direction to Vector3.Zero. This is what happens when you think quickly assigning direction the amount of rotation is a good idea.

To get back on schedule:

• Drawing classes: drawing models, 2d textures and text ( I need to see that game code works, not having visual representations slows my work and leaves me to assume functioning code)
• Moving Camera: I need to get my camera moving and rotating again. This time the camera DOESN'T rotate itself. Its dependent on the head of the character. Camera position = head position and camera look direction = head look direction. I have camera moving code already, its just a matter of making it work of a characters head. Shell code can be made to simulate the head until I am working on model manipulation.
• Menu System: I need to make my menu system solid. Make a full game like menu system. The true test is when I have drawing and moving cameras again.
• Bullet System: I need to get my bullet system back online. I will be taking shane's and the internets advise to use a memory pool for my bullets. I have code done, I just need to make it a memory pool (changing how bullets are added and removed from active list).
• Win condition: now that I have figured out what was causing me problems (Vector3.Zero :/ so many hours lost) I must work on win conditions. To start I will have time, kill counts and score. This will require a score system with teams. Win conditions will be separate objects and enum combinations.

When these things are done I will have a shell of a game that only needs proper collisions to form my base point ( the point which I will have a fallback to submit as my running FYP software). The fallback should be done at the end of december (Exams included).

AI will be started in january at the latest with focus on navigation first, then attacking, then strategy. My Ai will be designed to accept information mimicking that which the player has.

Information that the player has is what the player can see, hear, read on a map, know from experience of playing an area. "Cheats" for the AI will include telling it where it can get vantage points from and local AI communication similar to humans using headsets.

I think I will be going with the rule based AI paradigm but will research others to see if they suit my project better.

I will be dedicating Ai time to the first 3 weeks of january. after that I will be upgrading all aspects of the game to make a finished product I could be happy submitting.

Sleep time now. 23 november after I wake up will be a code heavy day. by the end, drawing should be done at least. and probably movement.

What I have so far

What I have so far for my fyp is a game that is in several pieces. However within those pieces are a bullet system, working splitscreen with First person cameras and a Menu system (main menu and pause menu) which can be extended as functionality is added.

after sleep (its 2:52am now) I will have a few hours of lectures but also a good 5 or so hours which can be mostly used for fyp. In that time I hope to work towards fridays goal of a winable game:

• Menu system working including a pause menu in gameplay mode that allows exiting to main menu and also allows a single player to leave the game and for the game to continue if there are still players remaining
• The game drawing scenes again with culling at view frustrum level.
• Bullet System integrated into new project (refactoring of original fyp work)
• new player movement system working
• split screen multiplayer integrated into project with separate pause menu per player.
• Context input checking(if paused only check pause controls, if in gameplay only check gameplay controls)
• GUI displaying player health, currently selected gun + ammo counts, crosshair and scoreboard if called.

A small bit of work to do but it will mean being closer to the basic game level I need so I can Have something to hand in ( a fallback level). With what I have by friday, I should only need collisions with modelled worlds working to have my fallback.

Refactoring almost done and Day after FYP Presentation

Yesterday was my FYP presentation. I think it went well but its what I got from it that counts.
I will be ditching plans for a networked game and will consider AI which can beat the player realistically as an AI success. This should give more time to perfecting the AI.

Also I have to research what AI paradigm I will be using. This will need to be done soon!

As for the Refactoring:
I have an extreme programming style of work. As a result my project has gotten where it is with planning used to figure out what system is needed next and the coding to flow from this.

As a result I have taken a step back from advancement to refactor my code to make it cleaner and easier to add the next functionality.
I've broken up some of my game as follows:
Players are added and managed from a CombatantManager class which will look after AI and Humans alike. As my setup has the only difference between AI and Humans is GatherInput();
BulletManager is taking care of efficient bullet collisions but this will probably get folded into a single Collision Detection Object.

Score Manager will have players subscribe to it and it will keep a match's score even for players who leave so that they can return.

SceneManager Draws the level when handed a camera. This is where I will do my own culling to optimise the game

When this refactoring is done, the game will allow players to shoot each other with a point added for each successful hit.

I'll add any new developments soon. For now its all going good.

Duck Mode

On Tuesday and Wednesday of this week we had the open days where secondary school students check out courses in UL. Over the two days, I advanced my games development with the use of moving ducks as targets. I managed to get people to play what I had and got some input. I also added random spawn points by an observation that people would spawn camp where the ducks originally came from. This greatly improved playability.
One person was playing the game for about 10 minutes even though all he was doing was shooting ducks without any rewards(points etc). A good Ludology game.

Inspired by what I completed, I am working on duck mode. This will be more advanced on what I had on the Open days and it will be much tidier code which can be used for other elements in the game. As for AI, the ducks will only have random changes but I will use them to add in movement and rotation AI decisions thus beginning my AI development.

Duck mode will consist of:

1. A Room with gravity and wall collisions. If I can find a model, it will help me understand how to import model rooms later.
   
2. Player and Duck separate spawn points (easily done by having 2 spawn point selectors which have already been coded)
3. Scores displayed on screen. I will find the source of my spritebatch problem and fix it. This will also give players a HUD and bragging rights.
4. Ammo, different weapons and weapon spawns. Players will now take shots carefully and have to reload.

What I will need:

• Combatant class - base for player and AI combatants

• Local Player class - builds on Combatant as the control interface

• AI Combatent class - like local player except replacing physical controls with virtual decisions ( wont be implemented for some but the code will be structured so all I will have to do is combatentList.Add(AIBot); everything else will work (updating, drawing etc)

• Duck mode class - runs the level updating Combatants and the ducks as well as bullets, physics and scores.
• Bullet manager class - manages bullets and notifies gameplaymode about collisions (returns what was hit and the bullet which did it)
• Score manager class - keeps track of the scores and displays them
• Weapon Class - stores weapon data, contains reload functions (does not add bullets directly, weapon stores data only)
  

Score tracker and Player Ids

Last night I got basic bullet collisions working.
I am going to continue to make my basic working game by working towards a working multiplayer deathmatch gameplay mode. ( Deathmatch is a simple each player fights each player. A free for all)
This will allow me to visually test new additions to the game.
I call the goal basic as I just need to see that what I add works quickly. I still need to optimize collisions with octtrees, reduce memory cost of adding and maintaining items and Add the AI elements of the final game product.
To finish deathmatch I will need to:

• Fix the Bounding Sphere covering amodel object to cover the entire object. Using six ducks to test the bounding sphere bounds. As seen below, I didn't completely cover the shotgun so it only registered a hit when inside the duck circle(leftmost of left duck, rightmost of right duck etc).

Whats wrong is that each mesh of a model has its own bounding sphere and I set the covering bounding sphere to only one of those bounding spheres. I need to combine them all.

• Add Scoring with user set limits. Display score when requested and at the end of the match before moving onto next match or multiplayer mainmenu.

• Add Timed Matches option with user set times. Remaining Time can be displyed ingame and on score report.

• Add a Aiming Reticule and to verify Accuracy and make it easier for users to play game. I have found an alternative method to mine for aiming. I will look into it to see if accuracy can be improved and if it will be easier to add shaky shooting accuracy depending on stance, player stamina and continuous firing. I will also have to look into aim assistance for users using gamepads as it is harder to get accurate shots compared to mouse users.

• Add Winning Conditions and End the match when they have been met. Remove all objects before leaving the match.

• Add Walls.Limit a Players Movement and Provide another way to get rid of bullets faster.

Theres more but I should get these done first.

Bullets

I CAN HAS BULLET COLLISIONS!!!
:D

Game Update

I have a fully functional Game development state <>
The Game has:

• Player controlled camera

• Adhoc local multiplayer (players join and leave at will and the screen re-adjusts correctly)

• Players can sprint and sneak. Speed modifiers will be adjusted later when the game play is more advanced. It was easy functionality to add :)

• Basic interactions (player can pickup items within a radius. Working on accurate selection)
  

The Game Demo post issues

"I am attempting Splitscreen with a major bug to solve and I have to solve a problem where the player is spawned directly ontop of the ground even when higher up is required."

I managed to solve these after a good sleep.

The splitscreen problem that I had with the split screen was that with 1 player, everything worked. However with
2 players: the two views were drawn over each other.
3 players: player 1 and 3 views clashed while player 2 was fine.
4 players: player 1 and 4 views clashed and player 2 and 3 views clashed

I found this problem in the code to remove adhoc players. What caused the issue was:

1. When a player leaves the splitscreen is refreshed so that unused screen is recovered. Unfortunately I was refreshing the screen every time.
2. In my iterator which filtered out left players to make a new active list, I was trying to be clever by reducing calls by "i = localPlayers.Count" and working to "i >-1". This combined with cause 1 made the viewports refresh every update in the opposite order. Hence players 1 and 4 and players 2 and 3 kept swapping viewports causing the flashing bug. This was a helpful cause though as I wouldn't of caught the constant viewport refreshing if i hadn't messed up the loop order.
   

The bug was fixed by a boolean check that a player has left before refreshing the viewports and when I removed the leaving player, I changed the loop so that they add in the correct order.


The players height problem was caused by me directly changing the players position in the player initialize function instead of changing the value through the Position property (C# set method). the problem was that the camera was stuck on the players default height. By setting the the Position property, the camera gets updated as well.


Right now I am working on the bullet manager. It will be a factory for bullets, update them, perform collsion checks and report to the gameplaymode class when a collision occurs.
Collsion checks are called to each object that the bullet can interact with and the closest object is returned to the gameplaymode class along with the bullet info for drawing. This will be basic at first so that I can get a game running quickly but will be optimized greatly later by introducing Octtrees and quadtrees.

Game Demo

As it stands, my game has a player controlled camera with collision interactions.
I am attempting Splitscreen with a major bug to solve and I have to solve a problem where the player is spawned directly ontop of the ground even when higher up is required. the shotgun objects which ive been using for testing are placed at the desired height so it is something to do with how i set up the ground tiles.

I need to sleep now but will attempt to solve splitscreen problem before meeting with chris exton at 12. Bullet collisions will have to wait a few hours! :/
I can achieve the goal of a basic deathmatch game (free for all and team) by end of wednesday.

My Project Goals - to be extended

Must Have:

• Working multiplayer and Single Player Modes.

• Working Sound Engine for sound effects and music.

• AI which can navigate the game world, find and attack enemies and work in teams to achieve goals.

• Character Collisions accurate to the limb and environmental accuracy to the object mesh

Would Like:

• AI which can flank Enemies, Sneak and can evaluate the best weapon for the job given available weapons.
• Scripting so that levels can be easily developed without constant recompiling.

Milestones - will be revised

Basic Shooting Game - 5th October A controlled camera, Split screen, managed bullets and collisions with basic game ending conditions(Time, points, target destruction, et). The collisions will be basic bounding spheres but this game should be usable for testing of later game elements. Also what I create for the game will be loosely coupled so that it can be inserted into my game engine when the Architecture design is finished. -> Camera and basic collisions done but issues with split screen drawing. Moving on to bullets. Splitscreen bug will be fixed by end of monday 5th. Basic deathmatch type game should be working by thursday.

List Of AI Elements - 12th October This will be the List from which my AI will be developed. On this list will be what the AI must be able to do and what would be nice if it could do. It will cover the different game modes as how a NPC acts in Capture the Flag will be different from Paint ball mode.

Body part specific bullet collisions and world collisions - 26th October This will be a big step on collisions compared to the Basic Shooting Game. In this instalment, the game should allow for limb specific damage and the player should be able to walk around in a modelled world (move up stairs, not be able to pass through walls and jump over small objects/walls). Also the ability to jump should be working. Collisions in XNA will have to be researched to make this work.

Have the Local multiplayer (-bots) done as well as the Menu system - 9th November This will mean a basic game with a working GUI and Main Menu. The Basic game will be for split screen only as networking will not be started yet and single player wont be started until AI is well advanced. Also a sound effect system should be implemented.

Have basic AI working which can walk around the world and shoot at the player – 23 November The AI should be able to path find from one point to another and shoot if they see the player. It will be basic and stop moving when shooting at the player. Cover and intelligent movements will follow at a later date.

End Of December Outside of Exam study and exam time, this month will see the completion of Al's ability to take cover and attack a player behind cover. AI Teamwork will have been started so that the AI can attempt to overwhelm its enemies. Before young Scientist demonstration Polish the games appearance for multiplayer split screen play. Animations should be working and basic levels should be set-up to demonstrate the future of our game. People at the young scientist event should be able to pick up a controller and play our game like any other with little problems. An Option to add bots should be on the multiplayer set-up menu and the bots should be able to act like a human player

End of January The game should be networked for system link and internet play. Work after the Young Scientist Demo is completed should focus on starting the Single player campaign. This will be Player getting to a point alive at first with extra missions added in after. The main purpose of the single player development to this milestone is to establish the single player framework and to start mission based goals.

End of February A beta Version of the Game should be completed for testing. The game will be cleaned up and upgrades will be made to AI behaviour. Optimizations should have begun. Effectively our game should be finished.

Before Demo Day The Game should be finished with competed Builds ready for final Demo Day submission. Changes will be made where improvement is possible but Builds will only be acceptable for demo day if no new bugs are added. We will have a compiled working version at all times with multiple back ups.

All other Milestones are as per FYP regulations for project submission dates

FYP Description

My Fyp is to Program a First Person Shooter. I have chosen this as my Fyp to demonstrate what I have learned so far and to further my knowledge in Game Programming as this will be my future career. My main focus for the game will be the NPC AI. With a game that has enemies like a FPS, a good AI is vital to a players experience and can make or break a title. The Game Engine will also be important for making this game and for my learning experience in game programming but it will be the AI which dictates how this is Fyp develops. My Research Questions for My FYP will be: Given the same information as a player: 1.Can I produce NPCs that are as believable as human players? For the purpose of this FYP, the AI will attempt to believable as a Human Player who is being tactical. Extremes like running into a crowd of enemies guns blazing will be ignored. A tactical player will: Use fire from cover where available. When in teams, attempt to manoeuvre around enemy.(some players will lay down cover fire while the rest attempt to flank enemy) A human player will attempt to reach goal as soon as possible while taking opportunities where possible.( example: Capture the flag, a player will try to get both flags in there base while defeating any enemies in their way to this goal) Try an sneak up on an enemy to get a clean shot or more points for a stealth attack. Stealth attacks also have to ability to demoralize the enemy which should make victory easier. Research Methods 1.Can I produce NPCs that are as believable as human players? First I will assess what behaviour my AI Players should have to make them believable as a human player. This will be done through examining games described as shooters for what their AI can do. The games will be examined through play, articles by professionals who worked on the games and through internet searches of blogs, videos and game reviews to see what worked and what didn't with the game AI. I will assemble a list of the key AI attributes. This list will be used to develop the AI. It will include how the AI should move, how it should act when given goals, how it should interact with the world, how it can communicate with team-mates and how it can find its enemies. The list will contain situation specific attributes as a player will react differently given the type of game, map or weapons available. The list will be sorted with necessary behaviours and behaviours which will improve how believable the AI is. When the basic game framework is complete and a multiplayer test has revealed that everything is working as it should (collisions, game ending conditions and player controls), I will begin work on programming the AI. This will start with a basic shell which will only move about the map using a path finding algorithm using goals set by a debug player but this will be evolved into an enemy which can find and attack the player. I will research, based on the AI Attribute List, professional articles, blogs and other internet and book resources for the Techniques used in game AI programming. From this I will use the techniques or my own based on them to form my AI. The AI will be tested through game play by myself first to make sure that it is working first. When I am confident that my AI is capable of completing a task, I will pit it against a human player which will have the same information as the AI. This will be shown with a split screen, the player on one and the AI on another. I will have another person present who will not know which screen is the AI and which is the player and from this will perform a basic Turing test. This will be done as the AI completes various tasks in its development (being able to move to a point, finding and shooting targets and safely hunting enemy players will be some of the tasks to complete). The Final test will be a series of matches between human teams and an AI teams. These matches will spawn the different multiplayer modes available. A few observers will perform the Turing test in a different room. They will be able to see the players (NPC and Human) but not what the players see so that screen shakes caused by human players using the analogue sticks won't ruin the test. The Human players will be asked to avoid abnormal behaviour like standing on top of light posts as AI characters will not do these things and would immediately fail the test should a human player do them. Should a majority of the observers pass the AI then “Can I produce NPCs that are as believable as human players?” will be answered with success. Regardless of whether I can make a believable AI Player, I will have examples of Game AI's which achieve the goals I had for my own.