Project PLASMA FPS
Blitz3D Forums/Blitz3D Programming/Project PLASMA FPS
| ||
| What ever happened to the plasma system. I think it was open source. But did it produce any game? |
| ||
| Somebody is apparently building a game using the engine i think :) |
| ||
| is the engine open source? |
| ||
| Ugh.. Project plasma as you guys knew it is dead :). I am continuing it's development in a sense. |
| ||
| So um... again. i Never got to look at the source for plasma. I was wondering if it was open source.If not then no worries. I was just wondering how it looked. i know that a few people put in some significant effort. Mostly iwas curious how the design worked out, or what the end result was. |
| ||
| Nope, no open source stuff, but I might be writting tutorials on alot of the stuff I wrote/learned by working on plasma soon (Including source). I figured alot out about good engine design in that time. |
| ||
| Blitz still needs at least one open source fps system imho. Remember there is still Joshs Singularity Engine, after his latest definitions it's pretty open-sourceish -which I highly respect. My own project was opensource, but it became kinda disguised-in-shame-of-spaghetti-code. So maybe it's time to start a new open source fps project - all together this time! |
| ||
| Sounds cool, I'll donate if someone else organises this time ;). Too much pressure for me under limited timetables. |
| ||
| Would be nice. I've never really worked on something this modular tho :) |
| ||
| open source imho a open source project will help all coders |
| ||
| yep, modularity is the way to go. |
| ||
| It's the only way to go. There should generally be a single main include holding base types for data manipulation/management. Then the additional modules are included as needed(Informing a main handler of their exsistance etc.). In the end it isnt as much of an engine as a mass of helper objects. What you people need to do if your serious about this, is decide what the main core needs to consist of. Heres my list. Event system(An event queue with access functions) Collision system(A system that registers collisions in the event system, etc.) General Message system(Inter system communication if applicable) A console(usually needed with FPS's) Generic Entity class/type.(Necessary for efficient scripting) With these and a few other possible items at the core, everyone should be able to build new code modules(That obviously must work indapendantly from all others). Uniform code style is a good idea(And community communications helps as well.). |
| ||
| Yeh, but if this is to happen then you will also have to control how the additional features work: For instance, how about a "shell" that is pretty much featureless (not overloaded with cosmetic features)- i.e. no headbobbing, particles, advanced lighting, animated weaponary, etc. whereby people can include what they want in the "shell". For example, some Blitz Peeps will want everyting like a commercial FPS - but a newbie may get lost and would like to only include stuff as and when they feel like it. In a nutshell, the "shell" ideally needs to be something you can easily add and take away from. I just think that there is sometimes too much of a temptation to add too many features, too quickly, which kills something off too quickly - before the basic stuff has been done. Some projects are too ambitious from the start. I think Blitz Peeps should still do advanced stuff, as long as it isn't embedded too much - in fact, there seems to be quite a few people that specialise in advanced stuff. The only reason why I say this as I have noted in the forums that some people say they are developing a FPS and they are including this feature and that feature, before they even have a framework engine that actually works. The above is just a thought - I think the whole idea of a new FPS open-source engine is a great idea. I just think it will be risky if too much goes in too soon. |
| ||
| Like I said, code a simple central module then code the tack on modules after that. If you're worried about noobs, then code your own easy to use "Player" module of sorts :). Most people who will use it however aren't gonna want to have to deal with all the extra work involved in the hand holding noob friendly version. |
| ||
| Hi guys, there are some left over code that Mr. Frank "Techlord" Taylor did in the Miscellaneous section of the code archives( about half way down ). I agree with jfk that an open source fps community project should be done. Where as, everyone can learn from it as PANNO said. I miss working with the Project Plasma FPS Community Project that Techlord started. I wouldn't mind pitching in either if I can. Right now, one of things I'm doing is trying to finish a CSG capable level editor so I can demostrate a new simple "Portal Method"( no BSP's! no recursion! no linepicks! ) that can be used for indoor and outdoor(Unreal-like) scenes. If a new community fps project started, I would be glad to try to work in my method as an option. I like the modularity idea as well! |
| ||
| so who's gonna write the core? |
| ||
| I always believed the Project PLASMA FPS would never truly die as long as someone contributed. So it is safe to say, as long as the code in archives exist or new code is added, 'Project PLASMA FPS' will live on. |
| ||
 |
| ||
| Exactly, don't just dive in guys, decide what has to be done :). |
| ||
| this reminds me of "the live of brian" - you can talk about it for years - which is exactly what happened - no offence. If we have a robust core we can add modules without to ask kofi anan first. so I'd say: write the core. If a competent guy writes the core then the rules will be set. |
| ||
| Not to be negative, but Plasma (and Josh's engine) are typical examples of what happens when people dive in with no plan. What people don't realize is that loading the level and displaying it with pretty coronas/lighting/effects and such is the easy part. It's the other 90% of the engine that's the bitch. |
| ||
| maybe we need some definitions. do we want multiplayer or not? because imho it is a little diffrence between mp and sp, especially in the level design. you can have undreds of doors and things in a single player adventure thing. But it's a pain to transmit every doorthingies state to every player. And doors are just the beginning. If we want multiplayer we better say "not too many doors and stuff" from beginning on. If we say single player, then we need an NPC definition. this will include a loading part and a function call in the game loop. maybe 2 calls because it's nice when you can do some things after updateworld. example given: bones manipulation on top of the animation, things like NPC looks to player etc. NPC is a seperate module that somebody could do. So what do you want, SP or MP? |
| ||
| it also depends on the story concept too. multiplayer is good but in what context. p1 v p2? or p1+2 coop? or massively multiplayer rpg? |
| ||
| I highly recommend keeping Game Play Objectives simple. Many First Person Shooter games contain common Game Play Objectives: 1) Find Keys -> Open Doors 2) Find Weapons/Ammo/Health -> Shoot Bad Guys 3) Defeat Boss|Find Exit -> Goto Next Level. These game play objectives are solid and achievable. More complex game play objectives can be built on top later. Levels designed with these game play objectives can be easier to develop. A general featureset should include: VIS/LOD System, Event Trigger System, FX System: Particle/Lensflare/Decals, HUD, Basic FSM AI (Attack/Evade/Seek), 16 Player Deathmatch Multiplyer Network, Configurable Control Scheme. Addtional features can be added later. I can assure you that an over ambitious Open Source Project will die an unfortunate death. |
| ||
| Whats the difference between a decal and a particle? What exactly is a decal, and how can one be made... |
| ||
| decal is a sprite aligned to a surface like a wall (ie bullet hole or blast darkening) where a particle is a sprite like fire or smoke that faces the user no matter what direction they are looking at it from. basicly both are sprites with different settings in blitz. think single surface. |
| ||
| Right, cool. I get ya now :) Thanks for the explanation :) |
| ||
| There's plenty of code available to develop a modular engine core. All that is required is to write functions to 'bolt' the modules together. Below is a selection of code modules extracted from the code archives which may be useful in developing the core: 1) Swift's Event Trigger System 2) Ripple Mesh: Water Effect 3) Unlimited Terrain w. Unique meshes: Terrain Management 4) Supercam! Another 3rd person cam 5) single surface particle system 6) Pixies: Sprites with sharp pixel perfect features can be used for HUD 7) Lens Flare 8) Homing Missiles 9) Relative Radar 10) Stacks: Useful for various operations 11) TCP client server chat program 12) Cubic Spline Interpolation: Multiplayer Game prediciton. 13) Sound Sorter: Sound Management 14) QuakeCam 15) CSP VIS System: A VIS Rendering System 16) COD2DOC: Code Documentation System 17) Vector Library A good vector lib. 18) 3D Pathfinding Lib 'Bolting' code together will be a challenge as there are many different coding styles. It is highly recommended that all code functions, types, arrays, constants be well docuemented. |
| ||
| I highly recommend Cod2Doc for documentation. ;) |
| ||
| thx frank |
| ||
| Baudspeed, Glad I could help. The great thing about the code in the archives is that its available to everyone, has some form of documentation and examples. |
| ||
| Frank - your list of archive entries might be useful, but you are already going to far. Forget VIS or Lense Flare at this point. What we need now is the following: player control, Bots, Multiplayer (BlitzPlay lite I'd say). For all these players we need a weapons system that will support 2 kinds of projectiles: immediate ones (no projectile in air, simply a linepick) which is used for supersonic stuff, bullets which are too fast to be seen, and the second type, visible things like Rockets, Fire-Particles etc. That means the engine will have to check if a player was shot by a bullet using linepick, as well as Entitydistance to all visible Projectiles currently flying around. Around this 2 kinds of Projectiles we can then build a collection of difrent weapons with diffrent properties. In the Multiplayer Part we need a flexible Packet devlivering system that will allow to add things later. So if we can make the core running without doors, that's more than enough for the moment. The only thing we have to take care for is some Parts must remain flexible, capable of modular enhancements. Here is an example for a gun definition: guns\plasma.b3d ; static mesh path guns\plasma_fire.b3d ; animation 1 guns\plasma_reload.b3d ; animation 2 2 ; type of gun (eg 2=shooting particles) guns\plasma_muzzleflash.tga ; muzzleflash texture 0 ; muzzle x offset -0.21 ; muzzle y offset 0.55 ; muzzle z offset guns\plasma_sprite.jpg ; particle texture guns\plasma_impagt.tga ; particle impact decal sprite 5.22 ; projectile speed 20 ; range 1.5 ; destruction range 1 ; serial fire enable 150 ; serial fire ms/round 50; magazine capacy guns\snd\plasma_fire.ogg ; fire sound guns\snd\plasma_noammo.ogg ; no ammo sound This is just an example and maybe i forgot a lot of things, but it shows a way how to define a ruleset for a generic weapons handler in the core. All you need is a type or an Array that will load these informations from a weapons.inf file, and then load all the required files as referenced here. In the cores handler it can then use the objects based on the definitions relatively easy. |
| ||
| ... |
| ||
| well, it's not code. It's my way of workflow. And it's tested, it works pretty well. I think a lot of things can be organized using such definition lists. Bots for example, while they can be linked to weapons. It is important that somebody makes a list of all properties for an object such as a Bot or Weapons. The core will then only have to call UpdateBullets() to check if anybody was shot. The function UpdateBullets() is of couse such a Module, in the hands of "Mr.Bullets", the guy who's gonna care for that part. Somebody else might do the Bot AI, and other people would have to do further things - Level Handling, Network etc. I think, Open Source or not - we would require a team of people who write the essential Modules. I am willing to do one part, and I would even use Types :P , but I shurely won't do the whole Thing by my own. Let's ask Surreal if he would like to implement the network part. Oh yeah, and maybe it's time to start a new thread. |
| ||
| When you start a new thread about this, please describe the various different modules that are essential to help people decide what that may want to contribute for. One thing that keeps popping up in my thought bubble is the basics for an input action mapping module. |
| ||
| I highly recommend you guys write a list of features and modules. I assure you it will prove to be invaluable in the long run. Check out my TBFPS Manual. I'm essentially devloping this game engine in reverse, writting my ideas down first, and then coding. It is giving me a greater overall perspective on my game engine and what must be done or not. Many would say that I'm making things way to complex. But, if you consider LOD, Portals, Physics, Motion Capture, DOT3 Mapping, Special Effects, Multiplayer, AI, and a slew of other features a game engine is complex. You will find yourself doing a lot of recoding without such a document to guide your development. Once neat code will become a confusing tanglement of speghetti code. |
| ||
| As far as I see a complete feature list is the easiest way to get stuck in theory. I see this happen all the time. You won't get anything in the end of the day when you only plan. Probably you will get some spaghetti Code while prototyping Modules, but with the need of modularity in mind it's always possible to complete a module in a proper way before it gets released. What I see here is a lot of opinions and theory, but nobody is actually coding something. My way of development works completely diffrent. |
| ||
| You have to buckle down and DO IT. |
| ||
| ... |
| ||
| Halo: Theres more then buckling and doing... The best way is to simply plot out how a system has to be built so it can be expanded later. After that JUST DO IT. Don't worry about plotting every aspect of the engine before coding, but at least make sure they are completely modular, and expandable, after that you can't go wrong. |
| ||
| Check out TournamentBlitz First Person Shooter Engine |
| ||
| Don't worry about plotting every aspect of the engine before coding, but at least make sure they are completely modular, and expandable, after that you can't go wrong. Even here, you may be going too far. Make sure that before you go to the trouble of making every system modular and expandable that they need to be. Take a serious look at the things you want to be modular and ask yourself if you're ever going to REALLY write a replacement module for it in the future. If not, screw the modular design and do it the easier way. |
| ||
| What's the core engine going to be based on? How will it work? Is the engine loading level by level, section by section - is it using portals or is it perpetually loading on the fly? How is level design being implemented? You need something to walk in before you can interact with it. Why not just "clone" something that has already been done? |
| ||
| I think the project needs both kinds of input. Reverse engineering people to think up features needed down the road. Forward engineering people to write the actual code, to get something going. First we need a test bed for all those ideas. Were does it all begin? In a Building, a village, or an outdoor field. That cubemap demo had water, torches, walls, stairs, floors. And a doorway. Perhaps we should start there and then expand outward. It needed something to pick up, and a doorway to exit. Lets place a key somewere, pick it up and exit through a door. Once outside the door we can shoot something. And the project can get started. |
| ||
| I was thinking more on cloning something commercial. |
| ||
| good idea, puki. how about to clone the functionality of the half live (1) engine? |
| ||
| If you are talking about half-life without the interaction logic, then yes. I was thinking more Quake 3 - not necessarily as a BSP structure - more in terms of logic - Quake 3 is a basic FPS shoot-em-up - interaction is minimal - Quake 3 is pretty dumb compared to some other FPS's or RPG's. If you can do something to mimic Quake 3 - simplistic doors - bots with limited interaction, basic pick-ups, etc. then you can build up all the other goodies. There would be no need to do advanced lighting initially. It doesn't have to look like Quake 3 or be an engine clone - it just needs to play like it - a simple FPS that can be improved on. The idea behind cloning a commercial game is the project would immediatley have focus and a goal as everyone will know what the end result is. Once the engine is complete, drop it out into tutorials or Code archives, then take the base engine and then start adding in all the advanced stuff that people want. Just a thought - I just think the project will move quicker if you follow a pre-trodden path. |
| ||
| Label-Based Management Scheme. All game entities can be identified in the Level Map using a simple label scheme. Basic game entity labels: Spawner{Bot, Ammo, Weapon, PowerUp}, Door, Key, Switch, and Lift.  Simply load the level map and parse the labels. The engine should know how to manage the behavior of the entities by label. An additional database may be needed to store extra properties. The is the easiest and most generic way to build the game level content and bind it to data. Additional labels for extra game entities and non-game entities (ie: waypoints, cameras, etc) can be added with ease. A variety of 3rd party editors can be used as long as there is a means to label the objects and export to B3D, 3DS, and X. |
| ||
| I would go against having a generic entity system. In my 3D engine I have found that there is just too much difference between the types of entities that are needed in a game. Since then I broke up my generic entity handler ( which was called GEntity btw ) in favour of separate entities, e.g. Room Lift Ladder Door Sound Enemy Object ( items you can pick up and use ) etc. etc. Having all of your entities held in one type structure leads to an overcomplication ( spaghetti code ) and unsuitably named type variables. In addition you may not want to loop through all entities of type 'Room' every frame, some entities will require specific handling. Also putting them into different types ( and different include "xxx.bb" files ) gives you more legible and manageable code. |
| ||
| I suggest you now start to ascertain who can (or potentially can) write a 3D engine or has done a lot of 3D engine work in Blitz3D. Forget about physics, particles, advanced lighting, advanced AI - just the core framework - you need the core engine. "jfk", "Frank" and "Shambler" seem to be interested here. Who else is competant? Some of you guys know who's who in the Blitz community - who is free? You'll have to decide a way forward. "jfk's" suggestion to to clone the functionality of the halflife(1) engine is fine, but you will have to forget about the AI interaction and a lot of the world interaction initially - think Q3 interaction first - get that working first. |
| ||
| I would go against having a generic entity system. A generic system will be necessary for a flexible engine. We have already identified several common entities found in a FPS level map: Spawner, Lifts, Doors, Powerups, Lights, and Sounds. These entities behave practically identical in every FPS game. In my 3D engine I have found that there is just too much difference between the types of entities that are needed in a game. Agreed. What I propose in the Label-Based Management Scheme is a method of level content creation, not code. The entity label is a simple mechanism to bind the entity to data within the engine. Having all of your entities held in one type structure leads to an overcomplication ( spaghetti code ) and unsuitably named type variables. Agreed. How the engine will deal with entities has yet to be determined and I'm certain that different code structures and functions will be needed to handle them appropiately. |
| ||
| I can see the need for 4 types of Entities. 1) Buildings, and structures. 2) Special stationary objects. eg. table lamp. (gives off light) 3) Animated objects. eg People, bots. 4) Temperary items you pick up or place yourself. And items that move or explode but don't have AI. These 4 types discribed 1) These items would be stored in map files to make rooms, dungeons, or even villages. They form the structure of the enviroment. We could use the various Quake editors out there for this type, and not have to write our own editor. 2) These items would be used for switches, lighting, doors that open, etc. 3) These items are moving around and will need AI. And we can use 3D Animated object editors for these. 4) These items disapear from the enviroment and enter the players inventory. These items would also include things left behind or fired like bombs or rockets. Each of these 4 groups has it's own specialized characteristics, making them hard or impractical to combine. I can't think of any reason for more then these 4 types. |
| ||
| @frank I was talking of generic system as in a program that used a single 'type' that contained the variables required to represent all the different kinds of entity, so resulting in an inefficient method. e.g. the same type could be used to represent a light/lift etc., resulting the the unsuitably named variables. You on the other hand meant generic as in a system that treats a lift as a lift no matter what the theme of the FPS is and I agree with you completely there. I keep each entity type to its own .bb include file and add the functions... Create_'Entity_type' to the load level function Delete_'Entity_type' to the same function to clear out the last levels entities before loading the next Update_'Entity_type' to the main game loop to make the entities act/react each frame This way each new entity is simple to add to the game engine and each Update() function is written with the fact that it will be called every frame in mind. |
| ||
| Shambler, I keep Each entity Type To its own .bb Include file And add the functions... I agree 100% its the only way To keep the code modular. Check out my object-based coding methodology for TBFPS.What I propose is that someone puts together a test level (B3D format) with at least one of each game entity: Spawner, Lift, Ladder, Door, Switch, Light, and Sound. Using the label scheme, label each entity like 'spawner01', 'door01', 'switch01', etc. With this a developer can take on writing the code structures for a specific entity based on the its purpose and intended behavior. We can add more entities later. Here's my list of entities and brief descriptions: Spawner - A 3D starting point in which bots and powerups are generated. Can be activated by switch or builtin timer. Door - A 3D structure which restricts access to level areas. Open/Close State is activated by switch. Can require key to activate switch. Platform - Aka Lift, A rotating/horizontal/vertical moving 3D structure which can transport bots and players standing atop. Can be switch activated or automatic timer. Climber - Aka Ladder, A virtual 3D Field which bots and players can climb vertically upon collision. Light - A virtual 3D object that is responsible lighting and light effects (lensflare, dynamic3D) within the scene. Sound3D - A 3D sound object. Switch - A virtual 3D field in which actions and events(multiple actions) can be activated upon collision or timer. Below is the level loader code. The level loader will load a b3d level, parse the entity labels, and create entity types and assign values.
;level loader code
Const ENTITY_MAX=255
Global entities%
Dim entity%(ENTITY_MAX)
loadlevel("test.b3d")
Function LoadLevel%(filename$)
;load entity properties from database
level%=LoadAnimMesh(filename$) ;load level geometry
b3dhierarchy(level%)
For loop = 1 To entities%
If Left(EntityName$(entity(loop%)),7)="spawner"
;new entity type (ie; spawner.spawner=New spawner)
;assign property values (; spawner\frequency%=1000)
;manipulate entity
End If
If Left(EntityName$(entity(loop%)),8)="platform"
;new entity type
;assign property values
;manipulate entity
End If
;other entities etc.
Next
Return level%
End Function
Function b3dhierarchy(parent%)
children%=CountChildren(parent%)
For loop = 1 To children%
entities%=entities%+1
child%=GetChild (parent%,loop)
entity(entities%)=child%
b3dhierarchy(child%)
Next
End Function |
| ||
| So you want to store all informations in pivot labels? if you want to chanche a single thing you'd have to run the level editor app and completely save a new version of the level mesh, just to alter some information for external stuff? And are there any illegal chars in labels? I'd suggest to do something like the csp engine does. Use a generic type for all items and interior, including stationary sounds and animated meshes. All objects of this type are stored in a simple textfile. Each object has a list of type data such as "special action trigger" strings, eg. "isElevator" etc. . Use a seperate type for Bots and a further one for weapons. So the level loader would more look like this:
loadlevel("roughbuilding.b3d","testlevel.bnf")
...
function loadlevel(rough$,levelinfo$)
load rough building rough$
rea=open levelinfo$
for each entry
readline object_file_path$
readline kind of object
if 1 then load static mesh
if 2 then load animated mesh
if 3 then load 3d sound
; here i can add lots of other objects if neccessary
readline color of socks
readline cheese logo
readline whatever
readline x,y,z,scale,rotation,smelling etc, etc, etc
positionentity where it has to be
read a lot of additional stuff, eg:
readline special job ("elevator" or "destructable" or "ammo" or "water" ...)
read 20 reserved dummy lines
next
closefile rea
end function
btw: Another detail: Think about the lightmapping of collectable items: eighter correct the lightmap after picking them up, or don't make shadows for those items at all. |
| ||
| So you want to store all informations in pivot labels? Not entirely, just the entity's position and/or geometry will be extracted from the level map "level01.b3d". Additional properties specific to the entity would be stored in a separate data file "level01.csv". The engine would bind the data to the entity by label id upon load. The idea is to provide a simple visual design interface mechanism in which level builders can orientate game entities in the level map using available geometry editors. Qoole, QRadiant, Wed, WorldCraft, CShop, and many other popular commercial game editors provide a visual interface to orientate entities. I totally agree with storing additional entity properties in a textfile of some sort. TBFPS uses MySQL database, but, for a generic FPS framework, a text file will work nicely. I would recommend the *.csv or Comma Delimited Text Format. You can easily import and export the data into your favorite spreadsheet app and manage the data in the form of table. You can also use any other text editor (ie: notepad) to edit the data. There are several csv utilities available in the code archives: Read Comma Delimited String, CSV Generator, Split CSV parameters out of a string. Here my version of Unknown's Split CSV Code. test.csv (generated with Excel) A String,Another String,etc Though it rain daggers with their points downward.,"Burton, Robert",1576-1640 "Beware the Jabberwock, my son!",Lewis Carroll,1832-98 Dim cvsfield$(500)
file=ReadFile("test.csv")
If Not file RuntimeError("No File Found!")
While Not Eof(file)
fields=cvsRowRead%(file)
Print "Fields="+Str(fields)
For loop= 1 To fields
Print cvsfield$(loop)
Next
WaitKey()
Wend
CloseFile(file)
Function cvsRowRead%(file,delimiter$=",")
row$=ReadLine(file)
column=1
cvsfield$(column)=nil$
quote=False
For loop=1 To Len(row$)
char$=Mid$(row$,loop,1)
If char$=Chr$(34)
quote=True-quote
ElseIf char$=delimiter$ And quote=False
; end of column
column=column + 1
cvsfield$(column)=nil$
Else
cvsfield$(column)=cvsfield$(column)+char$
End If
Next
Return column
End Function
|
| ||
| I dont't care much about if it's comma delimited or linebreak delimited, tho the second would be less complicating. someone please specify a generic object type, so we can start making a loader. |
| ||
| btw: >>TBFPS uses MySQL database<< how do i have to imagine that? every user has to install mysql first? (20 megs) or requires your fps to be connected to the web and download the entire level first? is there a mysql client for blitz at all? |
| ||
I propose this generic game entity type Type gameentity Field id% ;Stores id Field typeid% ;Stores entity type value field filename$ Field entity% ;Stores entity handle Field position.vector ;Stores current position vector Field angle.vector ;Stores current angle vector Field state% ;Stores state% used in game logic Field action3D.action3D ;Stores dynamic action selection End Type I prefer csv for data files. The implementation will be similar to loadlevel psuedocode you described.
loadlevel("roughbuilding")
...
function loadlevel(level$)
loadanimmesh(level$+".b3d")
rea=readfile(level$+".csv")
for each line
fields%=csvRowRead(rea)
select csvfield(2) ;typeid%
case 1
gameentity.gameentity=New gameentity
gameentity\id%=csvfield$(1)
gameentity\entity%=loadmesh(csvfield$(3));load static mesh
gameentity\position\x#=csvfield$(5)
gameentity\position\y#=csvfield$(6)
gameentity\position\z#=csvfield$(7)
.
.
.
assign additional properties
case 2
load stuff for this entity type
case 3
load stuff for this entity type
end select
next
closefile rea
end function |
| ||
| what is the diffrence between ID and handle? and it seems to me that generic type is indeed kinda short - I'd sugest we add a complete entity wrapper per default. this includes ALL potential entity properties such as FX, Alpha, Blendmode...................... you know, a whola lotta properties. just include possible sound props and so on. don't be selfish with a hand full of bytes here. and don't forget an action trigger string, this will be flexible. (eg: "elevator min:0.2 max:15.8 speed:0.25 trigger:whatever") position and rotation and scale are 3 values each. I expect to see 50 or more fields. As a first step let's copy/paste pretty much everything from the "entity control" command reference from the docs. Ok, from now on lets add everything neccessary. int Entity Handle string Entity title int entity type (mesh, animesh, sound) string entity file path string potential texture file path string Actions int entitycolor r,g,b float entityalpha float entityshininess int entitytexture int entityblend int entityfx float entityautofade near, far int entityorder string entityparent name float position x,y,z float scale x,y,z float rotation p,y,r int collision flag int texture flag (used with TextureFilter if set) int animation mode float animation speed float animation transition string animation starter object name float channel volume int channel pitch string emitter name (or "" for dummy pivot creation) Please add things I forgot |
| ||
| I'm not sure why you want a generic entity type, surely all entities should be specific since each one contains a very different set of data? For example my lift type currently looks like Type lifttype Field name$ Field meshindex ; the mesh Field xs,ys,zs ;starting position Field xe,ye,ze ;ending position Field ws,ps,rs ;starting rotation Field we,pe,re ;ending rotation Field f# ;0.0-1.0 where inbetween start and end is it? Field speed# ;speed of motion Field dir ;1=forward -1=back direction Field triggertype ;what triggers it to move? Field moving ;is it moving? End Type and my sound entity Type soundtype Field name$ Field class ;ambient oneshot everytime ? Field playing ;sound is playing now? Field pivot ;used for entity distance triggering Field radius# ;as above Field soundindex ;which sound does this use? Field timer ; how long has the sound been playing? Field time ; when was the sound started? End Type so you see they are very different and imo a generic set of data in a type would be unsuitable. |
| ||
| jfk, The difference between ID and Handle is that the ID is defined at design time, and the Handle is defined at runtime. For example, if I want to 'bind' switch04 to door01 (the numerical suffix bieng the ID) so, that when switch04 is triggered it opens door01 specifically. I merely store the ID into action associated with the switch. switch\action\function%=switchDoorOpen switch\action\i%[1]=switch\id% switch\action\i%[2]=door\id%This ID system requires the use of an array of types Dim switchindex.switch(255) Dim doorindex.door(255) ;in which the ID is the index switchindex(switch\id%)=switchThe Handle is defined upon the initialization of the type and it varies often. It is true there is a great deal you could do with just a handle, however, I do not recommmend the use of the undocumented Blitz Object and Handle functions. Using IDs you know exactly what is doing what, where, when, and why. I must also elaborate on the 'action' system and how much power it will give to the engine. The Action System is a flexible and easy-to-use Function Selection System (a function pointer). Its great for use in Triggered Event Objects, Dynamic Effects and Functions, Artificial Intelligence Systems and much more. Type action Field function ;function index Field i%[4] ;integer arguments Field f#[4] ;float arguments Field s$[4] ;string arguments End Type Function actionCall(this.action) Select this\function Case 1 function1(this\i%[1],this\f#[1],this\s$[1]) Case 2 function2(this\i%[1],this\i%[2],this\f#[1],this\f#[2],this\f#[3]) Case 3 function3(this\i%[1]) . . . End Select End FunctionInclude an action in the structure of the entity and you can give the entity power. This system is very similar to Swift's Event Trigger System I expect to see 50 or more fields. As a first step let's copy/paste pretty much everything from the "entity control" command reference from the docs. Holy smokes:) Its a good thing we are the csv files to manage such a large number properties. I would agree with Shambler on this one. A generic game entity is not an optimized solution. Each game entity contains a very different set of data, thus a specific type structure for each game entity is more efficient.I use lots of types in my coding. As a matter fact, I have developed object-based coding techniques based on Blitz Types that makes it very easy for me to build objects on top of each other. I would package most common properties into small packages, for example: Type vector Field x# Field y# Field z# End TypeThere is an entire vector lib in the code archives I recommend we use. I will write packages for common properties and create a set of entity type from those. I'll post them for approval. |
| ||
| nice to see you joining the production team, shambler! |
| ||
| Aha, this thread lives on since I last nosed at it. "jfk", "Frank" and "Shambler" still seem to be interested here - do you now have the 3 lead programmers that are probably required - 3 being ideal from a decision making point of view. There is no confirmation, as such, but are you guys going to follow the Quake3 logic path (not forgetting Unreal Tornament)? I just think it is a faster route than creating a project from scratch or by cloning something like Deus-Ex or Half-life, in terms of game logic. Plus, I think this initial project will finish quite quickly if you keep it simple - with no plot or story interaction - then you can bask in the glory of a finished project (albeit a Beta engine). I would have opted for the single-player route, as I think more people will use (or want to use) the code from a single-player perspective - but It doesn't matter, as long as there are bots - 3 is fine from a test-bed point of view. The enclosed world type seems the easier, as per a free-roaming engine (like Morrowind). Todd is working on his own portal system - that could be a future option. Is this project going ahead? "jfk", "Frank" and "Shambler" you seem the likely candidates so far, in terms of input - how about it? If this is kept simple the initial project shouldn't take that long. Ideally, it would be beneficial to document/diarise the thing (if it goes ahead). |
| ||
| I agree with what jfk says about ID's I do the same and steer clear of using handles. One thing that can make code easier to understand is the use of constants. I think these are very useful in Select/Case statements especially, here's an example of some I used in my last engine... ;Entity Classes Const cRoom=1 Const cSound=2 Const cEmitter=3 Const cMob=4 Const cThing=5 Const cDoor=6 Const cLock=7 Const cBlock=8 Const cButton=9 Const cPPad=10 Const cDeathZone=11 ;Entity States Const sOpen=1 Const sClosed=-1 Const sOpening=2 Const sClosing=-2 Const sVisible=3 Const sInvisible=-3 Const sLocked=4 Const sUnlocked=-4 Const sVising=5 Const sInvising=-5 Const sSolid=6 Const sHollow=7 Const sLoaded=8 Const sDeleted=-8 Const sPlaying=9 Const sNotPlaying=-9 Then the entity update function can have things like... Select GE\class Case cDoor ;Open/Close door if Unlocked If GPickedEntity=GE\resource If GE\state1=sUnlocked If GE\state2=sClosed GE\state2=sOpening EmitSound(GE\Sound_Open,GE\resource) EndIf If GE\state2=sOpen GE\state2=sClosing EmitSound(GE\Sound_Close,GE\resource) EndIf EndIf EndIf This code above was when I was using a generic entity type but I think it shows the gist of the idea. |
| ||
As much as I would like to avoid using a generic entity type it may be the easiest approach to take in a open source engine.Type vector Field x# Field y# Field z# End type Type color Field r# Field g# Field b# End type Type action Field id% Field function% Field i#[4] Field f#[4] Field s$[4] End Type Type texture Field id% Field typeid% ;1=normal, 2=animated Field texture% Field frame_width% Field frame_height% Field first_frame% Field frame_count% Field filtermatch_text$ Field filterflags% Field blend% Field u_scale# Field v_scale# Field actionid;animation and effect action End Type Type entity Field id% ;Stores id Field typeid% ;Stores entity type value Field entity% ;Stores entity handle Field textureid% Field position.vector ;Stores current position vector Field angle.vector ;Stores current angle vector Field scale.vector ;Store current scale Field collisionType% ;Stores collision type 0=no collision Field vector.vector ;generic vector Field i%[4] ;generic integer parameter Field f#[4] ;generic float parameter Field s$[4] ;generic string parameter Field state% ;Stores state% used in game logic Field actionid; Stores dynamic action id selection End Type This entity type should be flexible enough to support various Game entity types. Not all the properties mentioned are required during runtime, thus are not directly part of the type structure. We can include additional properties within the data file, handling them at load time. For example we can store the mesh filename$, upon load the Levelloader will load the mesh filename$ and assign it. The property 'filename$' should not be required once the entity has be mesh is created and assigned. Entity Typeid: 1=Structure 2=Spawner 3=Switch 3=Door 4=Platform (lifts) 5=Prop 8=Ladder 9=Light 10=Sound 11=Portal 12=Waypoint 11-99=Miscellaneous Many types of game entities can be defined with this structure. The generic parameters can be assigned values for specific purposes pertaining to a specific type. The actionid can be used to call a function associated with the specific game entity. I would like to get a consensus on wether or not this entity structure will suffice. |
| ||
| Instead of a generic entity type I suggest we adopt generic entity functions. Create_xxx to create the entity Update_xxx to update the entity per frame Destroy_xxx to destroy the entity and release resources This way the 'engine' doesn't have to worry about each new entities type structure, the functions that come with the entity handle everything so allowing each entities type to be individual. I think that Field i%[4] Field f#[4] Field s$[4] is confusing since for each type of entity it may mean something completely different and will make coding an entity prone to errors and a bit of a headeache. As for filename$, I use filename$ and store it in a global array depending on whether it is for a sound or a mesh. For example there is a global array of sounds and when the program calls the function 'Create_Sound(filename$,class)' the filename$ is compared against all of the filename$ sounds loaded so far. If the sound is already loaded the function returns the already loaded sound, if not then the filename$ is added to the list and the new sound loaded. The same goes for meshes, they are all stored in another global array. |
| ||
| ... |
| ||
| keep it simple... I want to see progress. There isn't much to worry about the item and interior system. I'd rather start with the bot ai, weapons handler and multiplayer stuff- this will be challenging enough. Puki said we should do something simple like UT . - lol if it was that simple then steve polge of epic games wouldn't be a star. |
| ||
| Good lord Frankie, you should have a generic entity type in there :). Will save you on scripting and physics. |
| ||
| OK guys I'm going to buckle down on one aspect of engine: Bots and AI. You guys will have to bear with my code, I'll modify as needed to get it to work with other components. Bot Code: I'm going to employ some code I have mentioned ealier, code archives, and new. All Bot code will be stored in a Project PLASMA FPS 2004: Bot.bb file in the code archives. Bot Geometry: Bots must be SingleMesh w/Bone animation in *.b3d format. Geometry can be loaded from within the level or independently. Animation will standard Blitz Animation. Bot Data: Data will be stored in *.csv comma delimited file. I will write the Level Loader portion for bots. Bot AI: 1) Bots must be able to see and hear players and or other bots within their field of view. 2) Bots must be able to attack, evade, find ammo, and find health dependent on their health and ammo status. 3) Bots must be able to navigate indoor/outdoor geometry avoiding collision with static and moving objects. I recommend everyone developing code to place the code in the misc code archives titled: Project PLASMA FPS 2004: *.bb If a code change needs to be made we can discuss it here. Hopefully, jfk is working on the Gun System. Shambler is working lifts and doors. Look forward to seeing what you guys have coded. |
| ||
| can you post a runnable example ? might be 2d, or use the maplet test level and cubes for enemy meshes. PS don't forget "bot follow player who's trying to escape" bare in mind: the weapons handler needs to be embed in the bot code as well as in the player controls. |
| ||
| From a level design point of view are the bots going to be assisted by nodes? I'm just assuming that with critical paths, it will take out a lot of "decision" making in terms of finding the closest health or a weapon, etc - even avoiding static collisions. @ "jfk" - "Puki said we should do something simple like UT . - lol if it was that simple then steve polge of epic games wouldn't be a star." Hey, UT is a glorified Q3 - we are talking dumb and dumber here - get coding - f'nar. |
| ||
| jfk, puki, Bots will use both waypoint nodes and A* Pathfinding for collision avoidance. I have to write a* pathfinding algo which might be the greatest challenge. So prior to seeing an demo, I want to get the pathfinding working. Waypoint nodes will be manually placed in the level via editor. Once again extracting the position of the nodes from the level geometry will take out some pain. |
| ||
| No, UTs bot ai should not be underestimated. |
| ||
| "jfk" is right - the UT bots are class - but I am talking more cloning these games in general game-play (the idea of running around a level with re-spawning bots and basic respawing pick-ups), as opposed to a major project with storylines and scripting, etc. "Frank" - you may want to advise if you would find it easier to initially have only ranged weapons. It may turn out that it doesn't make any difference to your logic. However: If melee based weapons are available then you will have to do more chasing down. Ranged weapons would help keep the bots under control and "on rails" - ie a bot could use its ability to fire a ranged weapon avoiding too much chasing the player (or another bot) to every nook and cranny of the environment and then having to rely on AI to negotiate. Just a thought, you may not have any problems with melee stuff - but say so if you would (before "jfk" comes up with the tri-chain, laser targetted, chainsaw). |
| ||
| Hey guys, I'm closely following your progress here as I'm interesting in later doing an add-on to this project for demostrating my new portal method. Currently, I'm creating a blitzplus/opengl level editor and want to make it easy as I can to build levels with for this project. The first version of it will be a freeware basic version in that it will hopefully get a basic FPS game up and running quickly or quicker. These nodes for path finding is something that I want to include in my editor. I would like to see your properties of a pathfinding node. In an editor, I would imagine one would manually place nodes in logical places and have connect them to each other for possible paths. Frank, From your bot.bb, I see id( identity value of node), waypoints( number of nodes connect to this node?), and bank ( the id of nodes connected to this bank?). Don't you need world position and radius of node? (ie: I say radius for knowing when a bot is at a node or not). Any info is apprieciated. |
| ||
| Hey "Todd", I knew you would pop up at some point, which is why I re-mentioned your portal system. Yep, "Frank's" got something to think about here with hard-coding the nodes - no doubt, he has a few ideas as to how he is going to reinterpretate them at run-time. Possibly, the editor could write the required details to a file - meaning the engine could pick up the data from the file at run-time. Or, perhaps the level geometry will be scanned and the data extracted at run-time without sourcing from a file. The radius of the nodes, may prove irrelevent but possibly will be utilised. The nodes will probably also sit at other key points such as health pick-ups, ammo, weapons, triggers, etc. I assume there will be a look-up for distances - to enable the AI to "know" the fastest route to the closest health pickup (in the way a human player could if they know the level and the location of all of the health pick-ups). |
| ||
| puki, As far as bots go. It should not be a problem to add write 'sensor' condition to determine what the best weapon to use or give chase. pepsi, I'm not sure how exactly the waypoint node will work at the moment. I'm building a simple level adding some waypoints and will use to test and fine tune. I will alter the code in bot.bb file to reflect. Hopefully there will be enough info for you to work with. |
| ||
| Good Tutorial on Pathfinding http://www.gamedev.net/reference/programming/features/astar/ |
| ||
| puki, reading your post mentioning me waaay up there :) ( i missed that )... yes, my portal system is definetly meant to be a future add-on option whereas I need time to perfect my method and ofcoarse have a level to implement properly ( ie: where my editor comes into play which in takes time to make also ). My portal method is designed for both indoor and outdoor scenes. The outdoor scenes I have no plans on making "LOD" for them( ie: I will never touch "LOD" algorithms for terrains again ). The outdoor scenes I envision are similuar to what the Unreal 2003 Tournament Demo has which would be perfect for my method. Any big flat or rolling hills style terrain will get squarely sectioned and have fog limiting far view. Ofcoarse, I'm trying to get my editor done at least in a usable way to test out my method asap. Frank, that's cool. I can wait for the info, no rush. |
| ||
| Door entity now implimented in http://www.blitzbasic.com/Community/posts.php?topic=29169 Door opens by right clicking mouse on the door when <600 units away. Door opens if it hits the player. Door closes when player is >1000 units away. The door is quite similar to a lift since it has a start and end position and rotation. This entity therefore can handle doors that rotate when they open, although will require some extra work on responding to a collision with the player in this mode. I suppose next we should have a lock/button entity =) |
| ||
| ... |
| ||
| UT's entire engine is daddyfied. The more like UT's engine, the better. Did a weapon mod for UT2003... it was amazingly painless. Took one weekend from complete newbie to modded weapon. |
| ||
| That ai wip looks good! My concern was about the size or radius of a node waypoint was to make sure that any given size in height ai bot would no doubt be able to interact with the waypoint node. In the "simple bot ai (WIP)" code, instead of the hardcoded +/-3 to see if the bot is in that zone, I would like to have that soft coded via waypoint properties. In an Editor, this would allow one to simply make an adjustable zone in a level's pathway and calculate the center of that box'd zone as the global position of the waypoint node. In this way, one can visually see the zone area that the waypoint node effects for detailed optimization of waypoint placement. Just a suggestion and mabie something you haven't gotten to yet. |
| ||
| pepsi, THNX. The WIP does not account for gravity and collision which will be implemented. I will make the collision properties you requested soft coded. Pathfinding routines may eliminate the manual point-to-point waypoint setup with only speciality waypoints being placed for jumps/teleport/etc. Ultimately, my goal is to keep the code readible and flexible. IMHO the level loader will be easy to add new game entities. I'm going to make it more modular providing a function template. back to coding. |
| ||
| You people gotta get out more ;). Hows stuff comming, I havn't paid much attention. Perhaps theres soemthing I can help with.. |
| ||
| Frank, I get a 404 trying to dl the botai wip zip. |
| ||
| jfk, Sorry, changed the filename, Project PLASMA FPS 2004: BOT WIP should be corrected. I will use this filename from here on out. |
   |