Project PLASMA FPS 2004: Thread 6
Blitz3D Forums/Blitz3D Programming/Project PLASMA FPS 2004: Thread 6
| ||
 Project PLASMA FPS 2004's Old Threads: 1 2 3 4 5 Welcome, Project PLASMA FPS 2004 (2K4.5) is a Blitz3D Open Source/Media First Person Shooter Engine And Game For the Blitz Community. THE SCREENSHOTS  THE NEWS  PPF2K4 Redirected - Building New Engine on Top of Jeremy Alessi's FPSNET 11/26/04 Frank Taylor.THE ENGINE Project PLASMA FPS 2004: How To Get Started! PPFNet Engine SourceWorkLog/TODO List 11/28/04THE CREDITS Code  FPSNet 08/22/2004 Jeremy Alessi 3D Art Scifi Character: RedBron 02/22/2004 Ruz FPS Hand 02/11/2004 Noel CowerFPS Hand (Screenshot) 01/29/2004 RuzPlasma Level 1 02/12/04 jfk 2D Art PP2K4 Logo v1 02/03/04 Frank TaylorSci Fi Textures 02/09/04 Noel CowerAudio fightforlife 2004-04-21 AshPlasma_Ace 2004-02-28 Todd RigginsTHE TOOLS Nullsoft Scriptable Install SystemTypeWriter][ Code Wizard 01/16/04 Frank TaylorPLASMA Editor 02/19/04 jfk |
| ||
| Checkout the WorkLog! |
| ||
| Checkout the WorkLog! |
| ||
| Nullsoft's installer v2 is very nice looking. =] |
| ||
| iumop, Thanks. Downloaded the latest version NSIS. Looks good! |
| ||
| ever need any free webspace to help ou let me know. Paul T. Silva |
| ||
| Zephar123 thanks for the offer. |
| ||
| Basic Network Server/Client working code written. Uses TCP for Reliable data transfer and UDP for Unreliable data transfer. Game Mission Load via TCP, Game Update via UDP. Currently working out Network Negotation and Messaging Scheme. Just for the record, due to the highly modular design of PPF2K4 I have moved over 50% of the old code modules with no rewrite. This a plus. However, rewrites will occur. The mission loading process is being completely rewritten to be loaded from a Database via TCP or locall from CSV. All high quantity 'replicant' 3D graphics (ie particles, GUIs) will be going to single surface design. |
| ||
| Took a short break from straining my brain on server/client architecture to go back to the design drawingboard. Within the short break, I wrote a extremely simple imagemap module to serve as a gui. The imagemap module includes a neat little parser that reads html client-side imagemap tags and creates clickable fields on a single image. I selected this method due to the massive number of free html imagemap editors. Additionally using a single large image is ideal for a single surface gui. I'm certain the imagemap technique will meet most FPS GUI needs. For dynamic text I will be implementing a single surface bitmap font system that will use either True Fonts or Custom Bitmaps. This is to come later down the road. I'm satisfied and will be pressing on with network design. |
| ||
| I continue to work out Network Negotation and Messaging Scheme. Things are starting to come together. Integrated GNET to work as master server. Four Network Operation Modes: Local Server-Client (Solo), Remote Server-Client (Join), Local/Remote Server-Client (Host), and Server Only (Core). I'm starting to have fun, sending messages between server and client. Currently, the server can register on PNET (PPF's version of GNET); launch the Client and build connections with the server; send some keystokes to the server from client; and send disconnection message to server to dropped the client. |
| ||
| It's ALIVE!!! |
| ||
| TournamentBlitz Services will be integrated into the PPF2K4.5's Network Core. For those not familiar with TournamentBlitz, its a Web-Based Tournament Managment System in which players can compete for CA$H comparable to: * SkillJam * PlayLink * Arkadium * BeAContender * FireBall * The House of Cards * IWin.com * Shockwave Tournament * CrediPlay * TournamentOnline * TournamentGames.com * WorldWinner.com TournamentBlitz will feature both 2D and 3D Games. Check out the 2D INSECTOIDS {TournamentBlitz Edition} Demo (1.3M). Project Plasma gets its own Server Tracking System: PNET. PNET is a modified version of Mark Sibly's GNET. Offering many more options and no refresh requirements. PNET will be hosted by TournamentBlitz.com. |
| ||
| So you're integrating your licensed tech into an open source project.. interresting... mind boggling but interesting... I think... Sort of.. |
| ||
| Dev, The TournamentBlitz SDK is openly available here. However, I had virtually no takers due to the lack of documentation. The integration will be more powerful and transparent. |
| ||
| Frank, who all is on the Plasma team now? |
| ||
| Frank, who all is on the Plasma team now? Past, Present, and Future Code and Media Contributors. I consider myself to be the Engine 'Integrator'. My job is to 'glue' all code and media into working a engine. I rewrite most contributed code to produce consistent code sytle so working with the engine source is easier. Many disagree, but, thats ok. It will prove to make more sense when dealing all the different aspects of the engine. I took a brief break from the Blitz-made Engine to get more idea on what direction the engine needed go, considering no solid engine design. I'm working with the Torque Engine The Commercial Game Engine used in Tribes I & Tribes II. I've learned a great deal from working with the Torque Engine and my new found knowledge is what I'm throwing into the revamp of the engine. I have streamlined the engine design to support basic FPS gameplay elements such as Triggers, Platforms, Bots, Weapons, and PowerUps. My Primary focus are on Network & Rendering Performance, and Tools. The Engine will have a Scripting System however, it will be isolated to programming the game elements (high level) such as Bots AI, Weapons, and Trigger Effects. When complete, a FPS Developers should be able to swap out the Place Holding Media and Scripts with their own and spit a entirely new FPS Game. |
| ||
| The Commercial Game Engine used in Tribes I & Tribes II. Wrong. It was not used in Tribes 1. |
| ||
| The Torque Game Engine started life as the technology behind Dynamix/Sierra/Vivendi´s products Tribes, Starsiege, and Tribes 2, and is an industry proven engine. -GarageGames.com |
| ||
| The Torque Game Engine started life as the technology behind Dynamix/Sierra/Vivendi´s products Tribes, Starsiege, and Tribes 2, and is an industry proven engine. For some reason I think that's marketing crap. The original Tribes engine was not likely to have been worth 'restoring' by the time Tribes 2's development had begun. |
| ||
| The original Tribes engine was not likely to have been worth 'restoring' by the time Tribes 2's development had begun. Perhaps, although one can always modify or build on top of a modular engine design. Regardless, it is a commercial engine and playing with it has certainly improved my understanding of a 'game engine.' |
| ||
| BlitzScript3D Compiler & Virtual Machine (BSCVM) will making a debut in Project PLASMA FPS! BSCVM will be the scripting solution for Project PLASMA FPS. BSCVM will provide PPF2K4.5 with a Scripting Language with a BASIC Syntax for programming high level GamePlay Objects such as Bots AI, Weapons, and Trigger Effects. The development of BSCVM is 50% complete. The implementation of Functions and Arrays are all that remain. I will post more news as it develops. |
| ||
| whwen will ther be a new demo. bit disappointed that this didn't progress. it all seems too 'abstract' to me |
| ||
| Don't expect anything Ruz, so you won't be disappointed. I think there should be yet another FPS Community Project byside Franks Project. Because this way it looks as if this is the best you can do with Blitz: An abstract theory. Anyway, there are many resources around, also in the code archives and some of them give a pretty good basement for a fps engine. Some ppl may put an fps game engine together in a few weeks. Frank I don't want to scare you, I am only honest. Stop the theory overkill, start coding the engine core. |
| ||
| Ruz, The Project is progressing. Unfortunately, I do not have a set date, but, I'm shooting for 3 to 4 weeks but no promises. Please elaborate on what you consider 'abstract'? I will do my best to clarify, although, I feel I have presented a Solid Engine Design around Game Play Outline. I'm currently working on the network core. The demo will demonstrate network performance. jfk, Have you honesty tried to bring non-consistent code from others and integrate them into single working product without support and documentation. ITS FRUSTRATING. 400+ Blitz Commands, not to mentioned other homemade functions. In Blitz there are several ways to store and access data. Some prefer arrays some types. There are thousand labeling schemes. I have devised a standard. Since many of us could not agree to standards, I appointed myself as the Engine Integrator to move the project forward. I use MY standards to bring the components together. I have taken code from you and others and reshaped it to work with other code components of the engine. Thats what I do. The result: modular integration and consistent code style. Many disagree, however, prior to taking the initiative there was very little organization, design, and documentation. As this Project is open to the public, its open for discussion as well. Discussion on theory, actual techniques, etc are relevant in this forum. I will no longer defend my role in this project. I have posted all source and media related to the project with plenty of demos to boot. If folks want to contribute code they can. They can either shapeup the code to be consistent with the other code components or I will. Someone has to glue this project together. |
| ||
| Your best defence would be to release a playable demo. There is a fully working networking FPS example in the archives, why don't you simply use that one? I guess your approach to make it better than the multimillion dollar engines is much to high. |
| ||
| The Network FPS Demo in the archives failed to launch on my pc. hehe. Regardless, its not a modular engine. I assure you, that you will come to appreciate my patience and focus. |
| ||
| Its just unfortunate that not many folks care how you do it as long as they get to play something. I am not saying its not important how you construct the engine, but in the scope of a project like this you must realise that people want to see progress in terms of a solid demo or they lose interest. |
| ||
| Ruz Yes. It is unfortunate. *sigh* |
| ||
| Your persistance is astounding O.o Please email me and let me know specifics of what needs doing! I agree that Plasma feels too abstract, you talk about network coding but I personally have no idea as to the engines current 'playability'. Sadly it appears to be a community project with just one person working on it. Maybe a 3D community project requires too much effort and resources for people to contribute to, knowing that they will get no return on their investment? email john@... |
| ||
| Shambler, There is no engine playbility without the network core. At the most basic level the INPUT/OUTPUT has been separated between the SERVER/CLIENT roles. This differs from the original design in which a Input Device was mapped directly to an action via code. Device -- code --> ActionWith the redesign a Client Input Device is mapped through a network connection to a Server Action. Client Device -- connection --> Server ActionThis is a significant redesign. Network Optizations require a modification to 70% of the original code. Server/Client Architecture in a nutshell: All Game Object logic, states, and values exists entirely on the server. Copies of the Game Object are Graphics/Sound are rendered on the client. The advantages: Security, Performance, and Persistance. Server INPUT are 'request' from the client to 'do something' to their player within the server's game world (move it, shoot weapon, etc). The server accepts the request, approves it, makes changes to the player in the Game World, Updates Game Objects, get their new results, and OUTPUTS the results to applicable clients. So instead of YOU performing a move on the the client and sending the server the new player(x,y,z), YOU send a request to the server to move your Player Forward, Backward, ETC in its game world. The server will approve the change, perform it, get the new results and the new player(x,y,z) is sent back to the client. The Client's I/O task are two fold: 1) collect INPUT from Server to update Copies of the Game World (aka Mimics) and OUTPUT them via the camera/listener. 2) Collect INPUT from user via Keyboard|Mouse|Joystick and OUTPUT 'request' to server. Single player games interface to the game world via connection to the localhost. The disadvantage of the architecture: a network interface is mandatory for game play. Game Start Snapshot and setup use TCP. Game loop uses UDP Packets to communicate updates and request. Network Operation Modes: Solo (Local Client/Server), Join (Client Only), Host (Local Client/Server accepts remote clients), Core (Server Only [zero render] accepts remote clients). I have a basic network system working in which I can send control mappings from client to server. So next goal is to duplicate FPS Game Objects on the server side to the client. The game objects: Camera, Map, Prop, Platform, Trigger, Warp, Soundfield, Player, Bot , Weapon, Projectile, Explosion, Reactor, GUI |
| ||
| Ok, sounds like a good network design which will allow even lower spec PC's to play the game because, for example, all of the code for collision response can be on the server. All the clients have to do is send input from the player and position players/objects in the world when/where the server tells them to, play sounds when the server tells them to etc. I'm going on hols today but when I return I'll get in touch and look into your templates 'if you have any' for game objects. ciao. |
| ||
| Shambler, I have a general set of properties outlined for Game Objects. The properties are shared between server and client. Game Objects and their are defined using custom types. I'll write out a Game Objects and a basic set of properties for each as a starting point. We can expand on the properties as needed. Enjoy. Chat when you get back. |
| ||
| Game Objects I will modify this list as needed to preserve thread space. |
| ||
| The time for a gui has come. I have designed a extremely simplistic gui system based on imagemaps where you basically have a large image with clickable fields. The system reads client side image map files in html format. It doesnt create any art, thus, you have to create your own. However, there are plenty of graphic and imagemap editors out there to quickly develop GUIs. The current system is a 3D pixel perfect single surface sprite system that supports buttons, checkboxes, inputboxes, dropboxes, scrollboxes, and bitmap fonts. I'm 80% complete with the system and will not be spending much time in this department. I'll add extra controls as needed later down the road. |
| ||
| The time for a gui has come. I would say the time for a gui has come and gone many eons ago. I admire your tenacity and dedication but its two years on since the first Project Plasma started and now we are into the 6th thread on the second coming of Project Plasma - still no playable framework demo ! A community project with one person hardly seems a community project. I fear that you have over complicated the design to such an extent that no-one could easily contribute. Server INPUT are 'request' from the client to 'do something' to their player within the server's game world (move it, shoot weapon, etc). The server accepts the request, approves it, makes changes to the player in the Game World, Updates Game Objects, get their new results, and OUTPUTS the results to applicable clients. So instead of YOU performing a move on the the client and sending the server the new player(x,y,z), YOU send a request to the server to move your Player Forward, Backward, ETC in its game world. The server will approve the change, perform it, get the new results and the new player(x,y,z) is sent back to the client. That's what Jeremy Allesi's FPSNET code does. It may not be completely modular but it was a simple task to add in Bots with simple AI. Only processor intensive operations like particles are done on the client.Player movement has to be carried out by the client otherwise there could be a lag between hitting the key and the commands being carried out. This is using Blitz built-in net commands but the principles are the same. You can see the code with added AI bots on the same thread. Something like this could easily be converted to a community project and there would be something tangible to work and have fun with. |
| ||
| 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. FPS GAMEPLAY: 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) 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. |
| ||
| When you search for "fps game engine" at yahoo, Project Plasma is top ranking 5th place :) and Franks TournamentBitz is even on Place 4, right after Unreal, and prior Torque or Quake 1&2. |
| ||
| Frank, There is nothing wrong with your design or visions if YOU mean to create/build a modular FPS engine. I just don't think this is suitable for a community project. The community projects that have been/are successful like Jump around and Alien Breed attract people to contribute because they have a starting point i.e a simple playable framework upon which to build. If someone were to write some code or functions for Plasma as it stands they could never 'see' their code functioning until you had integrated it. This would make debugging and testing very difficult. If your design is truly modular then it should not be a problem getting a basic working framework that can later be added to. Until such a thing exists people will find it hard to get involved which would be a shame considering the time & effort you've already spent on this. Maybe you should do a Plasma 'Lite' with a less 'rigid' design as a community project and continue with the full Plasma vision as your own project. I would be happy to collaborate on a project like this but I just can't see how it would be possible in its current form. |
| ||
| There is much criticism, but, no assistance with the code and media available. Well, I think you've cut yourself with your own sword on that one. I know that after reading these threads and looking at your designs, I wouldn't want to jump into this project because the learning curve is so steep at this point that it would take me weeks just to get up to speed with how everything works before I could even -begin- to contribute. |
| ||
| What smiff said..(Having just read his post after writing this ;p) You should just start again when bmax is out, but do it in the style of rob's open source projects. Clearly a way that works no? You know, just make it a little more accessible. Start with the goal of a simple fps..and let the people decide where to take it..as rob did, that way..it's fun to add to it as you're coming up with the ideas.. but following a pre-wrote design just feels like hard work.(For me, at least. |
| ||
| I agree with everyone my design is way too complex. If we can agree to the set of rules described here. Perhaps we can start a much simpler framework. Perhaps Mark Sibly's Castle Demo can serve as a starting framework. |
| ||
| I would be hesitant to start it over again in BlitzMax, actually. I know what I said above conflicts with what I'm about to say, but ... at least now you have scope and focus. With BlitzMax, people will be able to access modern hardware and that will mean vertex/pixel shaders and that will mean no focus on the core code and too much focus on glitzy effects. |
| ||
| The castle demo would be okay but I feel that Jeremy Allesi's FPSNET would be more suited. Apart from being fully functional and playable it also has working GNET multiplayer and chat - perfect for collaboration and playtesting. Admittedly this uses Blitz internal net commands - but they can always be substituted with BlitzPlay or likewise. The actual message creation and parsing will be the same It uses no external media which is an advantage at the start of a project. Code can be quickly modified and tested without worrying about the media. The design is as modular as can be with a procedural language and its easy to add stuff to. I had no problem adding in Bots ! To change the bot AI e.g. you would simply edit/replace the function UpdateBots(). It can be made more modular |
| ||
| Smiff, FPSNET sounds good. So what is needed and who is going to do what? |
| ||
| *Smacks Frank* That's all I have to say. |
| ||
| Noel, LOL. With so many others eager to participate, I had to release my stranglehold on the project. |
| ||
| If I weren't in the middle of developing Xiphias I'd help- but I am in the middle of developing Xiphias (among other things), so first priority is the people who pay me and then second priority is my engine. Which reminds me, I need to update my dev. journal more frequently. Good luck with this, Frank. |
| ||
| I'll modify and tidy up the BOTFPSNET code - make it more 'modular' and add in some more comments so its easier to follow and drop stuff in. My thoughts are as follows : Immediate and achievable goals could be - Improving Player movement and Bot AI. The current player movemt is fine for a fun type game but perhaps not suited to a more standard FPS type movement. The Players movement and collision model would need redefining. Although this is a multiplayer game the single player should be just as important. Good fun-to-play-against AI is important for those like me who havent got any friends to play with :) A good objective to aim for would be to create semi-autonomous bots, that can work alone or in teams, take cover and negotiate fairly complex levels. The bots of course can evolve as time goes on. For modelled levels I would leave out Doors,lifts and moving platforms for the present but make provision to add them later. The format for a level could be any that Blitz3d supports natively. Lightmapped .b3d would be my preference. It should be possible to do all level collison testing either with just blitz generated geometry or a modelled level as long as scales and collision entitytype are the same. I'll post the revised framework as soon as its done. |
| ||
| Smiff, Thats a solid plan. I have yet to play the BOTFPSNet via network. I would like to setup a couple of test sessions to determine if network code needs rewritting. The single player game can be processed via the network as well, just connect via localhost, only allowing bot 'connections' to be processed. If bots use connections they can be used in multiplayer games too. I'm not sure if your Bot code works this way. Integrating a Control Map for Player Movement would be a big improvement. A Control Map would allow players to remap the control keys and mouse. I will be removing the old ppf source and replacing it with new FPS Source. When we are ready to use external media, I would like to use the models that were previously developed considering the hard work placed into them. |
| ||
| "The format for a level could be any that Blitz3d supports natively but lightmapped" yep, probably b3d the best for that, then. |
| ||
| yep, Ruz models(as ruz is a great artist) were quite good. IMHO, it's not usual to find such good models for a free project ;) And also, very low res, good for blits. I think the skin was really low res, and the count very low, while looking good. |
| ||
| The Bots are only processed on the host.Single player would just be the host with no network connection. The GNET part can be disabled for single player. I'll make this available as an option on startup. |
| ||
| might get chance to do some more work on the character model soon. l already improved it a little |
| ||
| I think I might look into these changes. Might be more fun to work on now. |
| ||
| The single player game can be processed via the network as well, just connect via localhost, only allowing bot 'connections' to be processed. If bots use connections they can be used in multiplayer games too. I'm not sure if your Bot code works this way. As the code stands now the bots appear as just other players in single or multiplayer. All processing for the bots is done on the host and updates are sent to the clients. All network message ID's dealing with the bots are between 90 and 99 The bots currently only scan for and attack human players (I have written some simple bot v bot code but havent included it yet). When in range of their current weapon they begin to shoot. When they run out of ammo they go for a power-up. Bots react to being shot by attacking their aggresor. |
| ||
| As the code stands now the bots appear as just other players in single or multiplayer. All processing for the bots is done on the host and updates are sent to the clients. Thats what I meant, but, once again I complicated the topic. Your BotAI progress sounds really good. Look forward to getting on my hands on the revised framework. |
| ||
| Wow it's great to see that people are making good use of that FPSNet code! I'm very excited ;) |
| ||
| Jeremy, Your FPSNet is an excellent Resource. It will be fun to watch it evolve. Please feel free to contribute your input at any time. |
| ||
In preparation of extending engine and game resources, I would like to propose a file structure to manage future code and media additions.<Root>
<Engine> (source code)
Main.bb
OtherCodeModules.bb
<Game> (media, scripts, dat files)
Engine.exe
<Data>
<2D>
<Textures>
<3D>
<Maps>
map.b3d;*.3ds
map.dat
prop.b3d;*.3ds
prop.script;*.dat
map.jpg;*.png,*.jpg (textures)
<Players>
player.b3d;*.3ds
player.jpg;*.png,*.jpg (textures)
player.script; *.dat
<Weapons>
Weapon.b3d;*.3ds
Weapon.jpg;*.png,*.jpg (textures)
Weapon.script; *.dat
<PowerUps>
powerup.b3d;*.3ds
powerup.jpg;*.png,*.jpg (textures)
powerup.script; *.dat
<Audio>
<Music>
musicfiles.wav;*.ogg,*.mp3,*.mid
<SoundFX>
soundfiles.wav;*.ogg,*.mp3,*.mid
<Server>
Server.scripts
<Client>
Client.scripts
<UI>
ui.jpg;*.png,*.jpg (images)
ui.script;*.dat
<Tools>
Tool.exe; Tool.bb
<Docs> (.html format)
<Engine>
<Game>
<Tools>This is not set in stone so please offer opinions and suggestions. Once a file structure is agreed upon (if any) I will add it to the Code/Media Conventions, so contributors will know where to store their work. |
| ||
| Ooh ooh...where is this FPSNet code? And what exactly is GNet and how does it work? |
| ||
| BotFPSNet GNET Info |
| ||
| So why didn't you listen to me when I suggestied it first? BTW I suggest to use a local Server like Apache with a PHP Interpreter that will allow you to test GNET locally, even offline. EG: Easyphp (that includes apache, php and mysql). |
| ||
| So why didn't you listen to me when I suggestied it first? Slightly confused. Please Elaborate. |
| ||
| Checkout the NEW WorkLog! Need Your Input!!! |
| ||
| Hey can my name be added to the credits too? It'd make my day ;) |
| ||
| Frank, I was talking abou this: jfk (Posted 2004-11-12 12:23:45) Your best defence would be to release a playable demo. There is a fully working networking FPS example in the archives, why don't you simply use that one? I guess your approach to make it better than the multimillion dollar engines is much to high. Frank Taylor (Posted 2004-11-12 15:58:45) The Network FPS Demo in the archives failed to launch on my pc. hehe. Regardless, its not a modular engine. |
| ||
| Jeremy, Credits Fixed! |
| ||
| Anyone up for some network testing? I have yet to play another human with the current network code. |
| ||
| Thanks Frank! Hey, I'll test anytime ... shoot me an email BAN300 @ aol.com whenever you're up for it. |
| ||
| I don't know if this is out-of-the-question, but will the single-player functionality allow for adventure FPS gameplay (ex. Half-Life, Doom)? I'd be looking forward to that more than multiplayer. |
| ||
| Uber Lieutenant, BOTAI will be supported. However, Event Triggers, Doors & Keys, Platforms, and Special FX, etc are desired. Check out the TODO List at your earliest convenience. Multiplayer could also be supported in a Single Player Adventure as Cooperative Gameplay. I loved Halos cooperative gameplay mode and would honest like to see more games provide this gameplay feature. |
| ||
| One thing I will say is that I think too much focus is going into the bot AI instead of working on the engine's framework and functionality. Bots are nothing if the world isn't fully working. |
| ||
| in 14 days, will it be called Project Plasma 2005? |
| ||
| One thing I will say is that I think too much focus is going into the bot AI instead of working on the engine's framework and functionality. Uber Lieutenant, BotAI is currently the only task on the TODO List that has someone working on it. BotAI is also a very important component of single player gameplay, so its good thing Smiff is working on it. There are other task that need programmers. There is quite a bit of framework already provided with FPSNet. The code just needs to be broken up into code modules. |
| ||
| in 14 days, will it be called Project Plasma 2005? LOL. |
| ||
| Who's got level design? I guess this seems like it be a success, after being smashed in the showcase forum. No seriously need any help? I don't have much fancy tools, but me noggin' makes up for it. |
| ||
| PCD GUY Check Out the TODO List |
| ||
| What will the license be? |
| ||
| Source Code is public domain. Any media used for a Demo Game is property of the author. |
| ||
| "Open-Source" doesn't mean "Use my content and die" |
| ||
| 2005 New Year's Resolutions: 1. Complete Project PLASMA FPS 2005! 2. TournamentBlitzs' First Commercial Release. 3. Get back into the Gym. |
| ||
| The gym?! What the hell are you thinking, man?? Project Plasma FPS 2005 is a good idea, what with it almost being 2005 and you rewriting the engine. Can't wait for the source! |
| ||
| ... |
| ||
| PPF is no longer a sticky. So check the Worklog for updates. I will be contributing BlitzScript3D Scripting Engine to the project. |
| ||
| Modular Architecture: Refers to the design of any system composed of separate components that can be connected together. The beauty of modular architecture is that you can replace or add any one component (module) without affecting the rest of the system. The opposite of a modular architecture is an integrated architecture, in which no clear divisions exist between components. The term modular can apply to both hardware and software. Modular software design, for example, refers to a design strategy in which a system is composed of relatively small and autonomous routines that fit together. -webopedia.com |
| ||
| This looks good, I can't wait until a playable demo.... I have a Sci-fi FPS project - pretty simple, no network gameplay or anything, that I'd be willing to open to the Blitz community. I will if anyone wants to join me. I've got a playable demo and everything.... |
| ||
| Optomistic, Bring what you have to the table. Playable Demo here. |
| ||
| In taking a lil breather from BlitzScript3D. I've decided to revisted FPSNET. The code is a great start, but, its not very modular. Smiff was able to add Bot code with relative ease. However, I can see this becoming more difficult the larger the program becomes. I'm going thru the source and making some labeling changes to comply with conventions. I'm not doing anything major, just essentially a mass text replacement and I have a old tool I wrote to do that too. The use of blitz primitives is cool. But, dealing with 2D and 3D animation is a pain in the arse. It will have to be dealt with eventually, thus, using external media will come into to play and I intend to use contributed media. I've made efforts to remove my stranglehold and complexity from this project. If learned much from this project and others. This project is literally dying for folks to participate. If you would like join the TODO List has plenty of features that need attention. Using the conventions should allow one to develop independently and integrate with ease. I'm not sure what status Smiff's bot code is in. Hopefully, he will provide a update in the near future. |
| ||
| Gearing up for PPFNET. New Engine source. |
| ||
| I'm working on an FPS also, and I'm wondering about the media. I also need to model a hand, and I'm not that specific. Is there any legal issue of me using the hand in my game? It's a really good hand and I really would like to use it. |
| ||
| No Enemies, Just give credit where its due. |
| ||
| OK. Thank you. Very much. |
| ||
| Right, Okay, so what do we actually have so far? what features are built in? Also, a quick look doesnt find me a download ;) |
| ||
| Cygnus, The old download link was removed. The project started over (for the 3rd time) using the FPSNet source. Nothing became of the source. We have the option to start an entirely new list of features or add to the list I've started here. IMHO opinion this is a very good opportunity for us to discuss the features we like and get a understanding of what each individual expects from the engine. For example. I would expect the Engine to use optimized rendering methods such as : Single Surface Particles, an Occlusion System, and Level Of Detail Management. Blitz doesnt have native means to handle this, so it will have to be programmed. This has nothing to do with game play, only graphics rendering. A 'Game Play' feature the engine would handle could be Moving Platforms. Moving Platforms require special collision handling because Blitz default collision setup doesn't handle moving & colliding objects that well. This will have to be programmed as well. Overall, I say all this to make a distinction between the Engine and the game has to be made up front. |
| ||
| The platform collisions are quite easy i would imagine... i....ahh enough of code talk... on the particle front, ive not played with SS, but i would imagine it means one surface per texture? I did however play with Occlusion systems a few nights back, i have some ideas on how it can be done. Obviously, as an engine, it needs to be 100% modular, to make importing to new projects easy. I like your thread about 3d GUI and that is a must for modern day "woah!!"s.... Il be back later, incredibly busy tonight and my job is taking all my time... I'll do what i can here though. |
| ||
| Cygnus, What Instant Messenger Service you use? |
| ||
| I agree 200% with modularity. I would like to use as many freely available code Libraries and snippets already available and just modify them to fit the needs. There are some very good ones available and they come with examples and docs. |
| ||
| I am on MSN (my email address will get you there) these days, only on the evening because of work. (im on lunch now ;) ) If you can, it would be great to chat. Anyway, i gota go, I'm the only bloke in this office full of women!!!! ;) ;) :D ;D |
| ||
| ... |
| ||
| Anyone interested in a FREE, full-source, modular, high-performance, First-Person Shooter Game Engine made with Blitz3D? |
| ||
| Yes, of course :) /Alienforce |
| ||
| Me! |
| ||
| eh? |
| ||
| but ofcoarse ;) |
| ||
| Well sorry guys, I'm not convinced. With developing PW3D and working with several different code libraries and snippets, I'm certain that most of the features listed here can be developed separately and integrated single handedly. What do I need to do get more participation? There are many code snippets in the archives that can be used in this FPS Engine. For modularity they need to meet the naming convention. Documentation would be nice. But I will not do it all alone. I've tried, and you can see where the project is. If you take a gander at my Project Hierarchy below, you will see a step-by-step progression in which the PPF will serve. There has to be a distinction between the Game Engine and the actual Game. From a very high level the game engine should handle rendering, collision, sound production, and game logic using media and script files. It doesnt matter if the game is Sci-Fi, Military, etc, because the media and logic will define that. PW3D will serve as a level builder for PPF. After looking at what many other game engines are doing, its more advantageous to build the game engine features into the editor for active design. PW3D all ready features BlitzScript3D, BlitzPlay Lite, BLUI, and serveral other code components. Blitz handles most aspects of interactivity, graphics, and sound production by default. There are a few rendering techniques (Occlusion, Level Of Detail, and Single Surface) that have to be programmed to get the optimum rendering performance. Finite State Machine (FMS) Artificial Intelligence can meet the needs for bots. A* Pathfinding, Waypoints, and Triggers are part of the AI System. This needs to be coded. Triggers and Waypoints are fairly straight forward, but, I have yet to get my hands on 3D A*. The best uses for A* is navigating Terrain and object avoidance. Somebody find one or write one. I've touched every part of a FPS engine except a decent weapon system. Its no big deal to mount a static Gun mesh to the camera, generate a ammo particle when the LMB is pressed. But it gets more complicated with animation, multiple particle/decals effects and firing parameters. No-one has touched this and this is ultimately the only part of a FPS I would like to work on, but I'm doing everything else (Frank thinks to self: just imagine what I could do if only focused on this part). Physics are kewl. But, only simple physics are needed. Ragdolls and rigid bodies can be saved for PPF Next Gen. If you guys really want a FREE, full-source, modular, high-performance, First-Person Shooter Game Engine made with Blitz3D, then help me produce it. If your looking for somewhere to begin, look at the list of desired features. |
| ||
| let it die already:P |
| ||
| Is there somewhere i could download a complete .zip with all the latest project files.. I have tried to collect all the files but i feel/know that i miss some... I feel like this could be very good and it would be a shame if the project just died.. I really want to contribute to this project. /Alienforce |
| ||
| Alienforce, We are at a junction in which we can decide to continue with FPS_NET which will require a major rewrite for modularity and features, or pursue development of the engine with PersistentWorld3D (PW3D). I haven't received any other contribution for the FPS_NET revamp. I'm more inclined to go with PW3D. Although PW3D is being developed as an Level Building Application, it already integrates BlitzScript3D, BlitzPlay and many other features that can serve the 'Game Engine' functionality. Besides, a game Engine needs an Editor. Its an option not mandatory. I will continue dev with FPS_NET depending on what you and others agree too. I have learned a great deal in trying to make this project work. In order to get the engine to a notable degree of functionality we will need to devise milestones and work together in completing them. So first lets decide on wether we continue development with FPS_NET or PW3D. PW3D has a download for the latest updates. If we agree to move forward using it, ill post the download url. |
| ||
| PW3d. In my opinion, it is also more compatible with large groups, because with a world building app somebody can pop in for 10 minutes to add a cool feature they thought of, then leave. With a game engine, there's less room to do that. Besides, I think that though PP is very interesting, I find that PW3d is very cool and unique and worth finishing. Besides, it's about time we had a good free level modeller. |
| ||
| Besides, it's about time we had a good free level modeller. I agree 1000%. Whats really great about merging these projects is that work is accomplished simultaneously. I have to stress that we are not designing a specific game, but more so a engine to handle the generic game features found in most FPS games. Moreso A FPS Creator. In a generic FPS, the player navigates a level with 1-2 Weapons attached to the camera. The weapons, be it a Sword or Pulse Cannon is activated by the player to perform a action (swing, fire missile). The player can usually 'pick-up' items and activate events (a series of actions) by colliding with 'Triggers' (open doors, alert bots, etc). These game play elements is what PPF should handle. It doesnt matter the theme of the game. PPF should also handle specialty Rendering and AI routines. PW3D should handle the editing of every possible game object (rendered and virtual): items, triggers, particles, soundfields, weapons, scripts, and UI. So heres where I'm at with PW3D. I'm currently working on the network messaging portion of the application. Currently you can chat, but, thats it. Unlike a game, the application has different editing commands that can be executed between the connected clients. Figuring out the most generic means to handle the potentially large number of commands is the goal. Although a game will not require a large number of commands, network messaging is needed too for multiplayer. If we achieve a high performance network with lots of commands, we can easily achieve with very little commands. This is currently what Im working on. For years, FPS games have used several tricks to get high performance rendering results. If you heard of VIS, LOD, occlusion and all that crap, then you know what I'm talking about. The ultimate goal behind these techniques is to minimize the number of polygons rendered to the screen or shift polygon demands. Some other blitz-made FPS engines have used camera clipping/short range techniques to minimize polygon rendering. This is ok for interiors with short corridors. The problem is, your level designs are limited claustrophobic interior design. However, we achieve more flexibility by adding a method to create, save, and load information that tells the engine what to minimum number of polygons to display. There are several techniques floating around on the net. There are even 1 or 2 in the archives. Someone needs to find a Occlusion method and code it meeting the naming convention for easy integration. |
| ||
| 3D Pathfinding would be nice and would facilitate a much more sophisticated AI. I was writting one for the second edition of PPF. it was based on the 2D systems, used realtime collision, and was multi-tiered. Unfortunately it had a Bug i did not get around finding a solution for. We need one. Someone write one or find one. |
| ||
| Project PLASMA LIVES!!!! Lots of fires going at once. But at least they're burning. Intsead of gazing over one huge project, I've inadvertently created several smaller projects with a specific goal and focus: * BlitzScript3 - Scripting Engine * MAUI - Full-featured 3D GUI System * PersistentWorld3D - Multi-User Online Level Builder Another rebirth is taking place. In spite of naysayers, the project lives and things are looking real good from my perspective:) ------------------------------------------------------------------------- I'm adjusting my 2005 New Year's Resolutions. See above post! 1. In the Gym four days a week. 2. Working on several sub projects to complete Project PLASMA FPS 2005! 3. TournamentBlitz' 50% Complete!!! |
| ||
| Great Frank, Is the todo list uptodate ? /Alienforce |
| ||
| Alienforce, The TODO list is not updated. So updating the TODO List is on the TODO List hehe. Didn't get much input on using FPSNet by Jeremy Alessi. It would take a complete rewrite to make the FPSNet more modular. I'm in favor of BlitzPlay Lite for network support since its easy to use and already has been implemented in to PersistentWorld3D. I will definately be adding BlitzScript3D to the engine. In fact, I will adding the same GUI, Network, and Scripting Libs to PPF thats being used for PersistentWorld3D. This way I'm killing two Giants with one stone with Sub-Project Development. Whats needed is a AI Bot System. A Bot System that can handle Finite State Machine Logic, 3D Navigation: Pathfinding & Collision Avoidance over Terrain and inside Interiors, & Model Animation Control. The Bot System should be able to operate independently so that it can be integrated into any other 3D game projects. B.R.A.I.N.S: Behavioral Rules Artificial Intelligence Node System was the name of the AI system I was working on for PPF2K4 v2. It was going to be a Finite State Machine based AI with 3D A* Pathfinding, Waypoints, and Scriptable Logic. I had some really good 3D A* PathFinding code. Unfortunately, I ran into a bug that halted development. Perhaps someone could start a AI System Sub-Project called BRAINS. I'm working diligently on the MAUI GUI System. My goal is develop a suitable GUI System for Games and Applications. The Highlights will be 3D acceleration, Animation, True 3D GUI Scenes, and FREE use. So my direction and management style for Project PLASMA has changed. Intsead of trying organize one huge project, I've divided into to several smaller indpendent Sub-Projects. |
| ||
| TODO List Updated. Other Kick Ass Projects taking shape. Check out in the link below. |
| ||
| Checking the list. /Alienforce |
   |