smiff,
I truly appreciate the input. To be honest, I had no intention of "taking over the project". My original goal was to work on a modular AI system and track/post project changes. However, with no game plan, no documentation, no discussion, no agreement, I slowly ended up coding alone. ALL CONTRIBUTIONS to the project have been posted for download. There is much criticism, but, no assistance with the code and media available.
There are MANY assumptions with creating an FPS. Which have presented several woes with Project PLAMSA FPS. The First sign of trouble... NO GAME PLAY OBJECTIVES. There was no idea on features of the 'FPS Game' we were building. What do the players do? What is their purpose. Will there be Bots. Are there powerups, doors & keys, moving platforms? With no Game Play Plan - No Game. I derived a basic set of game play objectives from DOOM.
Noone addressed network and rendering optimizations. Will the engine be 'MOD'able/Script-abled? Just a sh*t-load of assumptions and requests. I did not anticipate this part of the project to be easy, but, when ideas were offered and labeled 'theory' and dismissed, I knew a DEAD END was just around the corner.
I realized that to build a modular engine, I would have to take an object-based approached creating 'objects' out of the components of Game Play. So, I categorized as many interactive Game Objects I could, defining their purpose, properties and application:
It was obvious to me that with so much information missing, NO modular engine could be built. Thus, I nominated myself as 'Engine Integrator' to bring all the code and media together. My job is to reshape code for modularity, continuity, and integration in this project. If the code doesnt fit, it doesnt go into the engine. Its that simple.
So, I would agree the time for a gui has come and gone many eons ago. But, no one has integrated one to the project.
I truly appreciate the input. To be honest, I had no intention of "taking over the project". My original goal was to work on a modular AI system and track/post project changes. However, with no game plan, no documentation, no discussion, no agreement, I slowly ended up coding alone. ALL CONTRIBUTIONS to the project have been posted for download. There is much criticism, but, no assistance with the code and media available.
There are MANY assumptions with creating an FPS. Which have presented several woes with Project PLAMSA FPS. The First sign of trouble... NO GAME PLAY OBJECTIVES. There was no idea on features of the 'FPS Game' we were building. What do the players do? What is their purpose. Will there be Bots. Are there powerups, doors & keys, moving platforms? With no Game Play Plan - No Game. I derived a basic set of game play objectives from DOOM.
FPS GAMEPLAY:
Player's navigate through Level Map [Indoor and Outdoor Maps] with a Weapon in First Person or Third Person with a goal to collect keys, unlock doors, and find the exit. Player will be armed with a weapon to shoot enemy bots and other players who try to prevent their success.
Player's will be able to:
1) Walk, Run, Jump, Duck, Strafe, Climb Ladders, Ride moving platforms.
2) Select one weapon from a variety.
3) Fire weapons from any position.
4) Shoot Enemy Bots and destructable props.
5) Pick up Powerups, Keys, Weapons and store them in a inventory.
6) Player's can unlock doors and trigger switches which activate events and ai.
7) Player will have several Single Player and Multiplayer 'Game Types' to select from.
Bot's will:
1) Walk, Run, Jump.
2) Use pathfinding to locate powerups and 'marked' areas.
3) Use finite state machine AI to select an action and pathfinding algorithms to transverse level.
4) Activate Triggers for events and actions.
5) Fire a weapon from any Position.
The Second Woozy... NO ENGINE DESIGN PLAN. Without a Game Play Obectives, there could be no engine design. Everyone screamin 'make a modular FPS Engine!', but no design plans offered. Others blurted, "just throw a demo together." A hardcoded demo that didnt seperate the engine from the game.Player's navigate through Level Map [Indoor and Outdoor Maps] with a Weapon in First Person or Third Person with a goal to collect keys, unlock doors, and find the exit. Player will be armed with a weapon to shoot enemy bots and other players who try to prevent their success.
Player's will be able to:
1) Walk, Run, Jump, Duck, Strafe, Climb Ladders, Ride moving platforms.
2) Select one weapon from a variety.
3) Fire weapons from any position.
4) Shoot Enemy Bots and destructable props.
5) Pick up Powerups, Keys, Weapons and store them in a inventory.
6) Player's can unlock doors and trigger switches which activate events and ai.
7) Player will have several Single Player and Multiplayer 'Game Types' to select from.
Bot's will:
1) Walk, Run, Jump.
2) Use pathfinding to locate powerups and 'marked' areas.
3) Use finite state machine AI to select an action and pathfinding algorithms to transverse level.
4) Activate Triggers for events and actions.
5) Fire a weapon from any Position.
Noone addressed network and rendering optimizations. Will the engine be 'MOD'able/Script-abled? Just a sh*t-load of assumptions and requests. I did not anticipate this part of the project to be easy, but, when ideas were offered and labeled 'theory' and dismissed, I knew a DEAD END was just around the corner.
I realized that to build a modular engine, I would have to take an object-based approached creating 'objects' out of the components of Game Play. So, I categorized as many interactive Game Objects I could, defining their purpose, properties and application:
* Player {Animated 3D Object, Player Controlled)
* Weapon (Animated/Static 3D Object, attached to Player)
* Projectile (3D Collection, projected from Weapon, inflicts Pow)
* Reactor (3D Collection, Particle Generator used for various particle effects: Explosions, Fire, Rain)
* Platform (3D Model, moving platform or elevator in which transports players or bots standing atop of it)
Pow (3D Object, PowerUp or PowerDown that modifies Player Stats, Projectile Stats, and Weapon Stats)
* Warp (Virtual Object, Defines a 3D cubic space which influence gravity on Players or Bots)
* Triggers (Virtual Object, Defines a 3D cubic space that executes a event/action command upon collision with player or bot)
* Key (Virtual Object, that must be in inventory of player the activate a trigger upon Collision.)
* GUI
Of course these are subject to change.
Third fluke, NO Coding Rules or Standards. As a programmer, I'm well aware of working with other's code can be very frustrating without some continuity and documentation. Some use arrays, others types. Some use a labeling system, others don't. Can you say CODE CONFLICT!!! I didn't expect everyone to take time to document their work, so obviously this would present itself as an enormous headache for others who desired to expand or build on top of the existing engine code. I devised a detailed rule set. In addition, I created a Code Wizard that outputs code using the rule set. * Weapon (Animated/Static 3D Object, attached to Player)
* Projectile (3D Collection, projected from Weapon, inflicts Pow)
* Reactor (3D Collection, Particle Generator used for various particle effects: Explosions, Fire, Rain)
* Platform (3D Model, moving platform or elevator in which transports players or bots standing atop of it)
Pow (3D Object, PowerUp or PowerDown that modifies Player Stats, Projectile Stats, and Weapon Stats)
* Warp (Virtual Object, Defines a 3D cubic space which influence gravity on Players or Bots)
* Triggers (Virtual Object, Defines a 3D cubic space that executes a event/action command upon collision with player or bot)
* Key (Virtual Object, that must be in inventory of player the activate a trigger upon Collision.)
* GUI
Of course these are subject to change.
It was obvious to me that with so much information missing, NO modular engine could be built. Thus, I nominated myself as 'Engine Integrator' to bring all the code and media together. My job is to reshape code for modularity, continuity, and integration in this project. If the code doesnt fit, it doesnt go into the engine. Its that simple.
So, I would agree the time for a gui has come and gone many eons ago. But, no one has integrated one to the project.