Project PLASMA FPS 2004
Blitz3D Forums/Blitz3D Programming/Project PLASMA FPS 2004
| ||
| Project PLASMA FPS 2004: Thread 3 |
| ||
| Sorry man, but surely this should go somewhere else? As this is more of a help forum. |
| ||
| I think it is because the other thread is here - and that sucker is getting big |
| ||
| help forum? :) IMO It says "Blitz3D"... anyways, old PLASMA had it's own forum but things went pear-shaped and died. I seriously hope that this new re-born PLASMA will have better fate. Good luck to you! |
| ||
| The project is here to help, and needs help. The project's success is completely dependent on the contributions of the community. I just hope the community will contribute (tangible) code and media and not just opinions. Please post your WIP code and media for the project regardless. The sight of progress will prevent stagnation and death. |
| ||
| Sorry to butt in, but what you guys really need is some organization. Declaring it an open source project and anyone can contribute sounds lovely, but it won't result in a finished project. People will lose interest, they will write half-finished code, they will fade away and if their code/assets need refining you won't be able to find them, etc. You need to create a core team of interested people, get a seperate web page/forum somewhere, put your heads down and go for it. This open, free flowing format seems lovely but it just doesn't work. |
| ||
| sourceforge.com has tools for free for setting up open source projects. |
| ||
| I've seen lots of dead projects on sourceforge. It's not a question of the format, it's a question of the motivation. And since we meet here, why shouldn't we talk here? Naysayers won't help much. |
| ||
| Frank - the bot wip is already pretty impressive. Some thoughts: Maybe think about to use a waypoint recorder. walk around in the level with gravity enabled. save a waypoint every other step . this way the bots will follow a natural way. use x-z-bezier-curves to smooth direction changes. if a bot has several tracks, search for crossings of his diffrent tracks. these will be the nodes. from these nodes the bot can choose per ai which way he wants to go. Using the recorder you can define which ways and zones can be walked by bots and which cannot. you can record every possible way if you want. |
| ||
| jfk, THNX, I like the waypoint recorder. I had something similar planned for other purposes. The waypoint type structure is not yet complete, but, upon completion I'll write a recorder or someone else can. My goal now is to my 3D pathfinding algo working. This has been a major thorn for me. If I solve it now, I can focus on other aspects with ease-of-mind. It will solve many problems. |
| ||
| I was thinking about pathfinding too, especially in a non-grid enviroment. Let's assume we have recorded lots of tracks and the crossing points of the diffrent tracks are the nodes. Now we could precalculate a list for every node which contains a 4-way chart for every target node, so the bot would know which from the 4 possible ways to the next node to go if he's after the player. He would then try to go to the node that is most near the player an has free sight to the player. I was calculating: if the level has 10 ways on x and 10 ways on z then they would cross about 100 times, so we have 100 nodes. 100nodes*100nodes*4chart*32Bit = 160 kB which is almost nothing, compared to 192 kB for a singe 256^2 bitmap. so even when we have 1000 nodes (10 levels building or something) it will still be a small amount of memory required for the pathfinding precalculated chart data. Compared to A*, Z find or whatever algo this would be much faster and still look and feel good. |
| ||
| BTW I will write a waypoint recorder, but first we have to define our world size. I suggest: 1 Blitz Unit=1 Meter. This means if a level Mesh is loaded then it must be scaled until the width of an ordinary door is about 1.5 meters or something. (Using scalemesh, avoid scaleentity for the main level geometry) Any other suggestions? For the WPRecorder I'd say all we need is x,y,z in float and time as int (milisecs()-t_gamestart) So we can use pauses when a bot is just walking around, in a non-panic state, and ignore pauses (or the complete timeline) if he is pathfinding, running and attacking. We still can discuss if diffrent bots can use diffrent waypoints - maybe we want to add flying bots or bots who cannot open doors etc. |
| ||
| I think that Mark once said that 1 Blitz unit is actually 1 meter :) Tracer |
| ||
| People will lose interest, they will write half-finished code, they will fade away and if their code/assets need refining you won't be able to find them, etc. That all sounds very familiar... |
| ||
| Sorry Frank :) |
| ||
| jfk Here's the current waypoint type structure ;Located in the bot.bb Type waypoint Field id% Field typeid% Field parentid% Field f% Field g% Field h% Field walkable% Field position.vector End Type ;requires the vector type structure, located in the vector.bb Type vector Field x# Field y# Field z# End TypeThe waypoint type structure is designed for A* Pathfinding and precalculated PathTables. We can use the A* Pathfinder Algo to precalculate paths and store them in a PathTable. The path is stored in the path type structure ;Located in the bot.bb Type path ;stores waypoint ids% in a bank Field id% Field typeid% Field waypoints% Field bank% End TypeHeres the psuedocode of the Path Table Preprocessor: ;Create PathTable Dim PathTable(maxwaypoints%,maxwaypoints%) ;store path object ids ;get paths For startwaypointid% = 1 To lastwaypointid% For targetwaypointid% = firstwaypointid% To 1 step -1 PathTable(startwaypointid%,targetwaypointid%)=pathCreate(startwaypointid%,targetwaypointid%) ;1) creates a path object ;2) uses A* to calculate paths between startwaypointid%,targetwaypointid% ;3) returns pathid Next NextThe A* can be used to generate paths realtime. Other 'path cost' pathfinder algos can be used for determining shortest-path with pre-positioned waypoints during realtime as well. If you can work with this waypoint structure (and I hope you can), I'm sure we can use it for the WPRecorder. |
| ||
| Hmm - I was thinking about something slihtly diffrent. Yes, we can use A* to precalculate the paths. but my strucure was more something like: A number of recorded tracks, used in the production, will then be "compiled" to nodes, each with (max) 4 ways to surrounding nodes. for each node we try to find the best way to all further nodes. But we don't store the entire path. INstead we only store a chart table with infos about which surrounding node is the best choice, which is second etc. The bot will then go to that best next node (or probably to the second best, depending on further factors), and from there he will decide again how to continue. This way it is kept very simple and transparent. let's see, maybe i can write a little example. |
| ||
| let's see, maybe i can write a little example. Yes. It would definately give me a better grasp on your concept. Is this a new concept? If not, perhaps there may be document available to explain in detail. |
| ||
| Mmm - the pathfinding is getting interesting as choices are opening up here. "jfk's" idea works from the point of view that the conditions are changing - the bot may be searching for ammo or a better weapon (initially), then suddenly needs health - in a way it is deciding at each critical node what it wants to do - he isn't storing a path as such, just the capability to 'decide' where to go next - it seems that it will help to make the AI more 'human'. The concern could be that it may make the AI slower to calculate, or less single-minded, than "Frank's" idea of precalculating the actual paths. However, the AI following pre-calculated paths would be constantly changing anyway - perhaps if a bot needed ammo or a better weapon, then suddenly needed health, it is going to have to follow a new precalculated path - this seems quicker but, less 'human' - you could end up having huge amounts of precalculated paths from each critical node due to constantly changing conditions. However, this all based on whether I understand your two methods as you meant them to be understood. |
| ||
| New logo looks like poo poo :) What happened to the old one? |
| ||
| wait a minute - now I am not shure anymore if we really need this kind of pathfinding. the reason is simple: how can a bot know that you are in sector x47? how can he know that the ammo or healt powerup popped up in sector a124? He can't - unless he has access to a video monitor system or something. And therefore I think it is kinda unrealistic. I would rather suggest to use a panic system. when they see you, they attack. If you run away and they cannot see you anymore, they go to the point where they saw you the last time, trying to hunt for you, follow you. Well, this is only my opinion, and maybe a true pathfinding algo is required nonetheless for some things. I just think it's no fun when they always know where you are. If they don't know and try to find you, that would be much more realistiv imho. This way the player could also surprise the bots, when he jumps down from somewhere where they didn't expect him. What do you think? |
| ||
| "jfk" > "how can he know that the ammo or healt powerup popped up in sector a124?" It doesn't matter, a human player doesn't know this either - they just know where it respawns - that's where the fun is for humans and bots - you get there and someone has nabbed it - do you wait or move onto the next one? The AI is simply searching for stuff - hoping it will be there. |
| ||
| "puki" :P ok, for respawning stuff it might be useful, although I am not a fan of q3 like energy and health control. THis is not the only way an engine may work. It was only you who said he wants a q3 clone. Me myself I'd prevere a HL or Monolith like engine. Currently I got them walking waypoints I have previously recorded. When I hit space I become visible to them and they start hunting for me. They have 3 states: don't see me, see me and try to come closer and see me and are in optimal attacking position. The placebo-enemy Cubes are then colored in diffrent colors to signal their state. ATM everything is just one long track that is crossing itself several times. now I need to allow them to jump onto a crossing part and continue that path. Need a brainstorm break. cya. |
| ||
| If you add or modify existing code and media, please collaborate with the original author. Is that the only requirement? I mean, if I contribute a model or a few textures to the project, is it free for anyone to use for any purpose they see fit? Or is it only for us in this project? BTW I'm not against the idea of it being free for everyone to use for any purpose they see fit. I just would like to know because it will affect what source material I can and can't use. ( photographs, references,etc. ) |
| ||
| Half-Life is cool (I was looking at something easier for speed) - at least we now know what you are aiming for - but are you doing it deathmatch style or actually like Half-life - ie the bots won't be searching for ammo or health, just the human players will be looking for health/ammo? I assume you want the bots to play like they would in Half-Life - they have ammo and just fake-reload from infinite ammo and don't actually heal themselves as such. Some of the bots could be on preset patrol routes, or static guards. Patrolling AI gives the human player the ability to "sneak" about. Actually, the Half-Life AI route is going to be easier than the Q3 one. |
| ||
| As I understand it it is a Blitz Open Source Project, to push the Blitz Community and make it easier for noobs to put something together. and therefore I tink it is free for everyone who is going to use it in a blitz project. Ripping Media for other compilers should not be legal IMHO. |
| ||
| I like the idea of people being able to use the media for another Blitz project, that sounds fair to me. Just wanted to make sure because I don't want someone to rip a texture or model I make and then they get in trouble because of me. I will ensure that anything I submit is free for use in any Blitz Project. |
| ||
| Sybixsus, Its all free to everyone with no restrictions. Please do not submit any work that cannot be freely distributed. jfk, The current AI Model is based on my AI model and will use a variety of 'linepick' scan patterns (ie: cone) to detect players and other bots. The patterns and range will be adjustable. The BOTAI Sensor-Reaction-Motor subsystems will provide a modular Finite State Machine AI system which can be easily built upon. The goal is to provide a flexible AI system in which a variety of behaviors can be simulated without the need of completely separate AI systems. Here's the concept in a nutshell: 1) Perform a check of the environment and self. 2)Prioritize returned values (inputs) from checks and select state based on the highest priority. 3) Select a reaction based on state. 4) Perform movement, animation, and other mechanical actions associated with the reaction. BotAI will have to know where things are located to generate paths. Path Generation can be generated manually (WPRecorder), generated realtime for obstacle avoidance(A*), use precalculated pathtables(start,goal), or use a hybrid precalculated and realtime pathfinding methods. Bots will be able to seek ammo or recharge ammo from a infinite source if needed. Its simply of matter of creating a Sensor-Reaction combination. Ultimately, I'm shooting for the basics here: 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 and avoid collision with static and moving objects. |
| ||
| Its all free to everyone with no restrictions. Please do not submit any work that cannot be freely distributed. Thanks for the confirmation. I assumed that to be the case, but I have some really high quality photos which I can use for texture source. The condition is that they can only be used for a project with which I am directly involved. If I contribute to Plasma, it would not be a problem, but if anyone takes them for something else, they would be in trouble without knowing it. As I said, I won't use any of those photos, I will stick with photos I have taken myself and other freely reusable stuff. |
| ||
| jfk, Hows that Weapon System coming along? |
| ||
| No offence, but I think I have to make something clear: Did I miss something? It feels like the Blitz open source fps project automaticly became Plasma 2004 and Frank is automaticly the Project leader, and I am hired and under contract? I really want to see something more than tons of theory sheets here. It's easy to talk about Linepicks, but it requires Practice to realize how speed-consuming they are, and this is only 1 example. I have made a first approach for a seek and destroy ai, but you Frank didn't even ask for more Info, I guess simply because I mentioned that it would probably not fit your theoretical Waypoint Structure. This suggest a massive inflexibility, together with leader ambitions. I never signed a contract for a weapons system and I don't work on command. If I ever start working on a weapons system for this project, then it requires a working core, player controls and bot ai. It wouldn't make sense to start with it earlier. |
| ||
| jfk, I apologize. I was under the impression you had started efforts on a Gun Weapon System as mentioned in the previous Project PLASMA FPS thread. It is what motivated me to start working on Bot AI for the project. I will not inquire again. I anticipated an example of your seek and destroy ai which would give me a better grasp on your concept. This was mentioned earlier in the thread. Please, provide it if its available. There are no contracts and obligations. No-one is getting paid here. I have no title or position in this project other than programmer. However, I will attempt organize things in the top post for the community. |
| ||
| I am sorry if i sounded harsh. but still: I need the core, controls and bot ai before I can start with the weapons. We also need (mp or bot) character models which can carry all kinds of weapons. A kind of generic Char, like military essentials, but probably a diffrent style. |
| ||
| jfk, Apology accepted. As far as AI goes I hopefully will have something working in day or 2. I'm currently sorting out the A* literally. I'm very interested in your seek and destroy ai and WPRecorder. I assume we are in need of a boned b3d model? If I had received my Milkshape registration (waaaay overdue, ordered 21 Dec 2003), I could export a quake or ut model to b3d. I'm sure someone in the forums should be able to assist. |
| ||
| I had massive speed problems with the current version. EntityVisible and LinePick are serious Speedkillers. I had 20 bots in the level and it was slowing things down unconsistently, to a painful 10 fps under some circumstances. It was pretty fast when I didn't try to "jump to crossing paths", it seems searching for crossing paths in realtime was the problem. I chanched my mind, now I think the A* Pathfinding is the way to go. The bot don't have to know where the player is, but when the bot can see the player, we can use a* to make him go to the attacking position. And of course we can use a* to make them walk from A to B, just like a waypoint recorder, but it only requires to define 2 points. I think the main problem is to port the various A* examples from 2D to 3D, and not only to a 3D Grid, but to a 3D Level with stairways, ramps, unregular floors etc. |
| ||
| jfk, Perhaps we can solve the speed problem together. I enjoy finding optimizations. Additionally, we may experience these troubles in the A*. We can troubleshoot this problem now and solve it for future work. I'm currently writting a Priority Queue module to manage path node sorting, which is required by the A* algorithm. The PQ could also be used to sort other data. Theres just a few gliches: missing data, but, success is near. Check out the WIP, load the wipqueue.bb and exec. The A* is a complex algo. I agree the 2D -> 3D port is tricky. I have not seen many examples that explain a 3D implementation. However, Patrick Lester's A* Pathfinding for Beginners is an easy to read tutorial and has been my reference document. My 'realtime A*' approach is using a 'worker' pivot with sphere collsion applied to test for floor and wall collision. The A* executes the [8] adjacent node check, only checking X/Z planes, while gravity is accounted for on Y plane. Heres the bot.bb, the A* code is located pathCreate function. I have yet to get this tested or working. |
| ||
| Here is a little demo, it is far from to be useful, just a quick and dirty hack. The bots are walking along waypoints or try to follow the player if he's visible. you need to copy these files into the maplet installation folder (where the test.b3d resides ) because it uses the test level that comes with maplet. Sorry, I have only few space on my server... http://www.melog.ch/dl/demo_wp_play.zip If you are visible and walking backward it's looking nice how they follow the player. |
| ||
| Well.. optimizing A*.. It can be totally precompiled, dunno how much more optimised you may want it? |
| ||
| jfk, The bots are relentless! This demo is awesome. We can definately use this. ShatteredReality Please explain A* precompile. Are you referring to a path lookup table? |
| ||
| There's an artist who uses the nick Bob3d who frequents the BlitzCoder forums but can't post on here as he's not a coder and doesn't want to buy Blitz. He noticed that this project had started up again and asked me to mention to you that he has a fully rigged, animated and textured model which he made available recently for all. The license is already practically open source, and he's quite happy for you to use it in this project. It's a gladiator style model, but the quality of the model and animations is excellent, and I'm sure someone could change it to suit their needs quite easily. Remove the shoulder protection, scifi-up the texture, whatever. THe only problem is that it can't currently be used in b3d format. There is a bug in CharacterFX ( his animation package of choice ) and although I don't quite understand the technical stuff, the animation gets screwed up in b3d format. It's something to do with mirroring bones. I believe he includes the cfx file and the md2 file, so conversion and editing should not be a problem. He has also said that it would be practically useless in b3d format, even if Dirk fixes the CFX bug, as it doesn't animate correctly without vertex weights. I don't know if there's any chance of us ever getting vertex weights, but here's another model that shows you what we're missing out on by not having them. The thread with the model, and Beaker's mirror is here if you're interested. It's good stuff : http://www.blitzcoder.com/cgi-bin/ubb-cgi/postdisplay.cgi?forum=Forum10&topic=000622 |
| ||
| Sybixsus, This is a great model, definately something we should be able to work with. I'm nearly complete with the a* pathfinder, just a few more optimizations and code clean-up. Once complete I'll look into *.b3d format conversion or get some assistance. |
| ||
| Realtime 3D A* Path Finding. Check out the WIP (BOT WIP ZIP v.2 in top post). |
| ||
| Precompiled A* in a nutshell. You simply complile the paths into lists, then index them. It shouldn't be too tough, and really is one of the better ways to handle it. |
| ||
| Frank I had troubles with the new file, all I get is a 2d grid and I also can't see it working as I expected. did I miss something? However, not shure if this is going to be useful for plasma2004, but i have converted a A* 2D Grid example to a 3D Grid example. I'll upload it soonish... I think this is a good backup progress choice. the source is pretty clean and type-based (thanks to morduun & turtle), it was surprisingly easy to add a third dimension (tho some details still might be optimized). Well, I'll put this to the code archives as well since a 3d pathfinder isn't something we can find in every corner. |
| ||
| ok, here it is, but it is still a bit buggy, somebody needs to help me to fix this: the path is kinda ziczac sometimes. It finds the way and avoids obstacles etc, but still it doesn't take the shortest way, this might be due to the way I converted to 3d in the function "evalNeighbors(,)". http://www.melog.ch/dl/astar3d.zip I will now go and seek for help :) |
| ||
| jfk, Please describe your results. Load and exec the wippathfind.bb. You should see a green cube, red cube, and a blue barrier(small grid). Press 1 to generate the path. There are still a few bugs lurking, so, you can only generate the path once. I'm at work so I will have to check out your 3D A* demo later this evening. |
| ||
| I saw a 2d grid of cubes. |
| ||
jfk The A* functions in 2D, but, could easily support 3D. The tetrahedrons represent a pathnodes generated during the search. The yellow tetras represent the shortest path created. There are a few bugs but for the most parts it works. True 3D pathfinding would be expotentially slower then 2D. I only account for collisions with walls on the X,Z planes. The Y plane is controlled by gravity/floor. The collision radius and distance increment can be adjusted for a two-tier path search. This implementation of the A* would support Bots that traverse the level on the ground. Aerial Bots would probably use a hand-generated path or hybrid. |
| ||
| this is looking completely diffrent than the one I tried. seems like I really missed something. Well, how would you do this when starting point is on level zero and end point on level 5? I guess true 3D pathfinding is required, it's just a question of how to rasterize the Y axis of the grid, probably only 1 grid level per level floor. Did you test the example I posted? |
| ||
| Opps! I mistakenly mislocated the correct ppf24k.zip. It has been corrected, re-download the wip. Well, how would you do this when starting point is on level zero and end point on level 5? Hmmm thats a good question. The behavior of the A* Collision Checker is the same as that of a ground-based Bot, in which a bot can move X/Z with gravity applied to Y. I figure in any scenario, if bots are to climb up ladders or take elevators special waypoints will be needed.Our code is very similar in many ways. I will add a full 3D behavior and check out the performance. |
| ||
| the performence is pretty good in 3d. probably we have to take care not to do a search each frame. And there is still the precalculation option. The only problem I see is Ramps etc. But your Idea of the gravity based grid points could help to solve this. simply use a linepick from the official grid point location downward against the ground and then use pickedxyz for the physical waypoint location as well as for the check for the walkability: If the linepick hits anything that is above the next lower grid then it must be walkable ground, else the point is inside a wall or something and therefore an obstacle. Something like that. |
| ||
| jfk, Your concept sounds very good, lets give it a try. |
| ||
| A little question : The pathfinding system use A* : ok Is this for purchase of the player or for the "patrol mode" of the bots ? Do you insert static waypoints to help the bots to take a decision ? Is there a map editor where u can insert waypoints entities ? Sorry to bother if it's already asked questions... |
| ||
| I had a problem - if there are some big obstacles which force to path to be s-shaped multiple times, then it seems the source uses huge amounts of ram for some reason. My computer then starts to use virtual ram(!) on the harddisk, which of course would take days, so I have to stop the programm, and it even crashes with an illegal memory error. It really seems like there is a serious memory leak somewhere in the code. I suspect this is due to type creation which is then not properly removed. I'll try to fix this. Also: such complex paths require too much cpu time (also without the harddisk swapping), so we are forced to use precalculation. But now we need to check the amount of ram required. If we would stora a complete path for every grid point to every grid point in the grid, this would be a big lot of data. I think we can use the method I described earlier: every point has a list which stores the next points the bots have to go to to reach the current target point most effectively. If these data is once precalculated it will be as quick and simple to "find" the right path as peeking an int out of an array! But to be honest - from what I see from some first calculations about the required ram - this will require a big ot of ram. storing this in ints for a 16^3 Grid would eat 64 MB - which doesn't make sense. I try to find some tricks to save storage. ONe is to use Bits: 6 Bits for a 3D direction vector instead of 32 Bits, but this is still 12 Megs for the mentioned Grid size... thinking... |
| ||
| Olive the path finding is used for many things: bots use it to patrol from a to b (where a,b,c etc, can easily be set in a level editor), bots use it go to power, health, ammo or whatever respawning points. Bots would also use it to go to strategic positions where they can attack the player. They can also use it to follow the player. Like when the player is hiding behind a corner, the bot will go to the point he saw the player the last time - using the pathfinding function. A good and solid generic Pathfinding Function will make a lot of things much easier. There will be static waypoints for diffrent reasons. Like waypoints for patroling bots (which can be seen as a passive mode). There is no editor yet, we first want to make the core and the near-core elements work properly. It seems like we are going to have this pathfinding thing nailed soon. Then we would be glad if somebody writes an editor, although maybe later we should try to use the same GUI design for all tools, or maybe even to include all tools in one program - if possible. |
| ||
| Heres Patrick's Pathfinding article on Gamedev.net. Its the same as above with more info on optimization and more links to other articles on the topic. I have implemented many of the optimization suggestions, with greatest optimization is using a binary heap. A reduced number of nodes checks is beneficial as a full 3D adjacent node check requires 24 nodes, a 2D only requires 8. Patrick also suggest using Two-tier A* search, which large areas are used for long paths, switching to finer searches when you get close to the target. All of these optimizations can be used for real-time. But, none of these will out perform precalculation. |
| ||
| IMHO we have to take care that the pathfinding handling remains simple. It shouldn't be too complex. Two-tier A* search would also mean we need a refined additional grid, which will probably eat a lot of Ram too... I think we are not far from a very efficient precalculated pathfinding functionality. If we only use non-diagonal neighbor checks this would reduce the amount of required ram dramaticly. These would bmean there are 6 possilbe directions, plus 1 for no movement. So we would need only 3 Bits to count from 0 to 7 possible direction vectors. Using no diagonal steps would also mean we could ignore diagonal G cost diffrence in the evaluation. I know, it's not very elegant, but comparing both (I can turn diagonal on and off here) the non-diagonal search is pretty nice too. |
| ||
| Heres am intresting article on 3D pathfinding,might be of some use to you. http://www.hardgeus.com/pathfinding/ |
| ||
| Just in case: http://www.gamedev.net/reference/articles/article1939.asp Apologizes if you already mentioned this, I hadn't the time to read the whole thread. |
| ||
| Thank you for the links. Hey Frank, can you help me with the types problem I got? see the other pathfinding thread. would be nice. |
| ||
| Hi i have been working on 3d pathfinding and collision avoidance for some time and i am starting to get some good results. The pathfinding was the easy bit compared to the bots colliding into each other. When i get a second i will post a small demo. |
| ||
| jfk, I will do my best to assist. I'm reading over your astar code. |
| ||
| So if someone wants to contribute, where would i find the base code to plug any modules into? |
| ||
The base code is not finished by now, but I hope it will be something simple like this:Graphics3D 640,480,16,2 SetBuffer BackBuffer() Collisions 1,2,2,3 player=CreatePivot() camera=CreateCamera(player) TranslateEntity camera,0,.25,0 PositionEntity player,0,0.7,-1 EntityRadius player,0.3,0.6 EntityType player,1 mesh=LoadMesh( "level.b3d" ) EntityFX mesh,1 EntityType mesh,2 sp#=.05 while not keyhit(1) ; standard navigation mxs#=MouseXSpeed()/4 mys#=MouseYSpeed()/4 xa#=(xa#-mxs#)Mod 360 ya#=(ya#+mys#)Mod 360 MoveMouse GraphicsWidth()/2,GraphicsHeight()/2 RotateEntity camera,ya#,0,0 RotateEntity player,0,xa#,0 If KeyDown(200) Then MoveEntity player,0,0,sp If KeyDown(208) Then MoveEntity player,0,0,-sp TranslateEntity player,0,-.033,0 UpdateWorld() RenderWorld() Flip Wend Of course it will not look exactly like that, and the controls will be outsourced somehow. It doesn't really matter that much how the core is going to look, there are several things everyone should take care for: If you need to use globals, arrays, types etc. which could be in conflict with things other people create (everything which is not local) then you should use your personal name prefix, eg: global baudsp_x function baudsp_calcx() etc. Include Files should be named (hi Frank :)) "include_whatever.bb" to prevent confusion! |
| ||
| Will someone clean up the variables later? this would require some sort of documnetation for the variable. Just a suggestion, may instead of users names we use a module name. ie if a person is creating a path finder then we use PathFinder_function1() as the naming standards. This will avoid confusion later on when someone contributes to more than one module. jfk, will you be sort of the project coordinator? if so what kind of standards, organization do you forsee in regards to the project? I have a *very* strong background in project design although game architecture is relatively new to me. If you have any questions on best practices just email me or post, i would be happy to contribute as well in that capacity. |
| ||
| I would like to suggest we collaborate before making a contribution. This communication will allow us to coordinate our efforts together. As the engine will be modular, I would anticipate all code components to be separately stored in their own .bb (bot.bb, weapon.bb, player.bb,etc) and one main.bb file in which main control loops executes. The main.bb file may follow a template like below:
.engine_includes
Include "bot.bb"
Include "weapon.bb"
Include "player.bb"
Include "other.bb"
Include "other.dat"
.engine_start
splash()
levelload("game")
;initialize other stuff
botStart()
weaponStart()
playerStart()
otherStart()
.engine_update
while not keyhit(1)
engine_sync()
;all component updates
botUpdate()
weaponUpdate()
playerUpdate()
otherUpdate()
UpdateWorld()
RenderWorld()
flip()
wend
.engine_stop
;memory cleanup
botStop()
weaponStop()
playerStop()
otherstop()
This is generic main file setup which should be flexible and easy for everyone to contribute without major changes to the main structure. The tough part will be coordinating and writting functions that bolt different code components together. But, through collaboration I'm sure we can work through it. |
| ||
| Baudspeed, The project does not currently have a 'Project Coordinator', although, I will attempt organize code/media in the top post for the community. Perhaps you can bring your *very* strong background in project design to this project. |
| ||
| Frank, i completely agree with your modular file idea. i think going any other way wouldnt be effective. It would be nice to 'plug in' other engines like physics, bots, etc. each can be managed with a tick or step based time. each frame results in 1 tick. As for project design, i think we need to nail down some core deliverables. Realistic things which the core engine requires. ie, frame limiting, or how input will begathered, possibly even the level/environment loading. Items such as pathfinding is important but would be a module for the later phases (that looks very cool btw). In the sprit of contribution i have a few suggestions we may want to focus on below: * frame limiting/rate - if we set up standards here then each module that uses a frame/tick/turn based rate can then know how much work to do in a single frame. I think that some systems sort of lack that. Ie, if a level was to be loaded, how much do we load. all of it at once. That would mean that the game comes to a stop while we are loading, accessing a large process, or even doing multiple database/network/system api calls. If we agree to use a frame/tick managemnet system as the core, and we set this as a standard, then all the modules can use that. This can also be used as sort of a pseudo multi threading system where each module can perform part of its complete action. The benifit of using this as a standard is that even if we don't build modules that use the, we will experience no downside. Thoughts? or am i just rambling? |
| ||
| Just a scenerio, I know for myself that I need to have delta time movements for any realtime FPS games I make or get involved in. I will not touch the renderworld tweening thing. Will delta time fps method be able to fit in this core? |
| ||
| personally I'd vote for delta_t too, esp. since I have used it successfully in the csp engine, but I am afraid this is against popular believe... :) I am also afraid of me practice is a bit unsophisticated in this perfect theory. |
| ||
| Just a suggestion, may instead of users names we use a module name. ie if a person is creating a path finder then we use PathFinder_function1() as the naming standards. I'd say: no. All of a sudden you have 5 diffrent Pathfinder1_function1()... Instead use a 3 Char abbrev of your nickname if you want, and prefix everything: BDS_pathfinder1() So we'll see who did it, inside which Includefile the functions are etc. |
| ||
| Yay. Its started again. Really happy to se that its not dead. (The project ofcource) :-D |
| ||
| @jfk: if we are all contributing to the same project we can probbably coordinate the module naming. I just would hate to have to work with: baudspeed_functionx() We need to have what module that the function etc. belongs to. Perhapse something like: MODULE_DEVELOPERINITIALS_FUNCTION() this would produce * PHYSICS_JFK_Update() * GUI_JFK_Update() * PLAYERS_JFK_Update() * BOT_JFK_Update() rather than * JFK_Update() or at least we could use * JFK_Physics_Update(). I very much doubt that if we are collaborating on the modules as well that we will build more than 1 physics module for the comunity. it would be kind of redundant to work on more than one. Can you see what i am getting at with the fact that the modules really wont be implemented togeather? I wouldnt want to see a game that used two (or possibly more *shudder* )entirely different physics or gui engines because only a few items of each were usefull. I do agree however that we may want to keep them unique. How about a compromise with: MODULE_INITIALS_FUNCTION() This would produce: CLOCKTICK_SYS_Update() PHYSICS_JFK_Update() GUI_BAUD_Update() BOT_TOD_Update() |
| ||
| Then I'd prefere MODULE_FUNCTION_INITIALS(). Anyway, it's not about a physics module, it's more about Global X or something. |
| ||
| Hey that's two D's! :P I like this naming convention... either way is kewl. |
| ||
| @JFK. great no prob looks like thats three of us that agree to the convention. I'm assuming there is no group voting process, but it sounds like a start. @Frank Taylor if its okay with everyone could you create a link to a standards document? attached entry is below. ****************************************************** NAMING CONVENTIONS - CODE MODULES ****************************************************** When submitting code modules for incorporation into PLASMA 2004 please ensure that the following standard is used when naming your module and public functions. This way all contributors will be able to identify specific modules. Syntax: MODULE_FUNCTION_INITIALS() Example: CLOCKTICK_Update_SYS() //example of a clock tick module part of core system PHYSICS_Update_BOB() // example of a physics engine written by BOB GUI_Update_JOE() // example of a gui written by Joe BOT_Update_TOD() // example of a bot module written by Tod *********************************************************** |
| ||
| Baudspeed, No prob. I assume this naming convention will also apply to all consts, globals, variables, arrays, and types. I think it will be in our best interest to define an entire set of 'Code' Conventions. One of the greatest challenges will be reading others code, with the conventions we can can at least provide some guidelines that make translation smoother. What do you guys think? |
| ||
| I can work on a set of code conventions. We can go pretty extreme on them but i think sticking to something usefull will go over well. In other news, i have a GUI system for menus. It includes skinnable gadgets, windows, list boxes, buttons etc. each which drive events. So they would probbably integrate well into someones scripting language. Once we get the core of the system completed I will wrap it up and add it to the project. It took a while to make, but i think this is a good cause. And well... im not using it right now, so maybe everyone can benifit from it. However it is a 2d over 3d overlay which means it would only be good for setting settings, menu items etc. not as a HUD, since it tends to chop off a few frames per second. |
| ||
| If anyone is interested check out TypeWriter Code Wizard. This code wizard will produce a set of common functions to intialize, update, and destroy objects created with a type structure. Could be used to generate code with a standardized format. I have developed a object-based coding technique and I'm quite used to coding with it. The code wizard generates code based on the technique. I have been pondering over the naming convention and the fact that more than one developer would be developing different code modules for the same purpose. I do not mean to be difficult, but, I forsee developing in such a fashion becoming grossly unmanageable, not to mention code readability. I would be more in favor of collaboration in which coders and artist working on the same code module or media work together to produce one version of a module. |
| ||
| I agree on trying to keep it standard. However we dont want to lose contributors due to the bueracracy of trying to keep things unified. (But we dont want to lose the project to garbage code). In the end its going to be blitz code, so if worst comes to worst, we (the community) can update the conventions if working on it. I'll try to get some more standards posted tomorrow, and I will look into finding the GUI code i tucked away. Im sure it will be very usefull for our purposes. Ill check out the typewriter code wizard as well. is the list at the top (your code and JFKs) modules which are scheduled to be plugged in? or are they what u guys are working on? |
| ||
| I think Frank scheduled them to be plugged in. I don't work on it. As mentioned before, I wait for a working Bot AI, then I'll see what I can do for the weapons handler. |
| ||
| Nice gun in the logo. Do you have the model available to look at anywhere? |
| ||
| Baudspeed, I believe both code modules will be plugnplay ready once label convention is applied and bugs are worked out. All that should remain is the storing/loading of data for the modules which I also propose a method for in the Level Loader. If we agree on the Main.bb Structure I propose here. All code modules should be stored in a single Module.bb and provide a 'Start','Update' and 'Stop' Functions of some sort to go into the main.bb. Other labels could be used as long as they serve the purpose of initializing/loading, updating, and deleting modules. These three functions should be the only functions allowed in the main.bb from any module.bb. My current level Loader is pretty flexible, however, I'm going to redesign the level loader to be more modular, so that each module can have its own 'level loader' function using a template. This will allow module writers to develop the levelLoader how they see fit. All the main level loader will simply have to do is call these module loader functions to load data associated with the module. |
| ||
| halo, Sorry no gun model. A image rip from UT to keep the banner from being completely boring. I reckon I'll redo it when a playable game is made. |
| ||
| You're welcome to all my media I post, if the exchange goes both ways. |
| ||
| Im working on the coding guidelines tonight. However, Im a bit worried about adding much more to the standards package that plasma will use. I dont want to start 'choking' the process. Could people post there opinions on how much standards they would actually adopt, or what they do not want to see occur. |
| ||
| reading the guidline shouldn't take more than 1 minute, written in basic english for dummies like me. |
| ||
| has anyone thought of if we are going to use any physics engine for the fps? would we need one? |
| ||
| Baudspeed, Put all of your ideas together in full. We can add or remove later. One of my goals is to provide a centralized information center. I have a some code guidelines up for vote. 1) Code Writers are responsible for providing a Reference Sheet(s) for their code. With this guideline, the PPF2k4 team will provide a Reference Sheet Template in which Coders can use to document their functions, arrays, variables/types, and constants. I understand that writting documentation is not fun, but, must be done to so that code's purpose and use can be referenced (just, imagine Blitz with out a command reference). I will personally take on the responsibility of putting together a Table of Contents for all Reference Sheets. Coders can submit their Reference Sheets and changes to me and I will build/update the Table of Contents. 1a) Changes. If changes are required, Coders must submit a new Reference Sheet w/ changes to replace the old. I will NOT take on the task of performing these changes directly to Reference Sheets. 2) Code pertaining to the project should be posted in the Blitz Code Archives. Its a Open Source Project for the Community and this is the ideal location for code IMHO. Coders have the option to place the code in the archives themselves or provide me the code to do so. 3) Code modules should be stored in a single Module.bb and provide a 'Start','Update' and 'Stop' Function of some sort for use in the Main.bb. These are the only functions that will be allowed in the Main.bb. Contants, Globals, and Arrays should be defined the associated Module.bb. If the modules must be loaded in a specific order or the module requires another, this requirement should be stated in the Reference Sheet. 4) Code Modules should be 100% blitz and not rely on DLL's. |
| ||
| has anyone thought of if we are going to use any physics engine for the fps? would we need one? IMHO I would avoid implementing any complex subsystems unless it is complete. Attempts to implement such a subsystem in the first PPF brought development to a complete stop. If we are to pursue physics, it should be very basic. |
| ||
| justa questions but how are we going to change the state of something. ie. if we are 'updating a gui. we start the gui when theapp starts. and only call update when we want to see it? what if we want to change the menu of the gui before we display it? or pass data from one module to another? ie if we click a button in the gui, what would be the preferred method of calling something like 'fire gun' or change weapon, etc. My gui system relies on the ability to return values into something like a case statements or scripting engine. but it needs to be able to effect things. Should we include a function called 'getstate()' or something? to get the state of items/systems in modules? Any thoughts? |
| ||
| Baudspeed, These gui questions are difficult, because we have yet to see the code or know how it behaves. This is where collaboration comes into play. We can better define how the gui will work with other components, if we see how its handled with a demo. If the Gui code module is compact and self contained, it should not be difficult to develop 'glue' functions to interface other modules to it. This is why documentation will be so critical. |
| ||
| Frank I strongly agree with point 4, but I think the project needs it's own server and forum. We better don't fill the code archive with something WIP-ish IMHO. |
| ||
| can someone one clarify what WIP and IMHO is? |
| ||
| I think he means - Work in progress and In my honest opinion |
| ||
| ah. i get it |
| ||
| Frank, I strongly agree with point 4, but I think the project needs it's own server and forum. We better don't fill the code archive with something WIP-ish IMHO. I agree. A server would be great, however, we have one major delimma: Server Space. Someone would have to donate such server space. This can be very difficult, not to mention maintenance. There is no problem posting code modules in the code archives. Modular code can be used in other projects, in fact, the entire Code Archives is that of modular code. All code pertaining to project should be readily available for the Blitz Community. IMHO what better home for a Blitz Basic Open Source Project then BlitzBasic.com:) Until Server Space is available, I will continue to post my code in the Code Archives. Ultimately, it shows effort and progress. If necessary I will design a few icons that display the status of the code or media: New, Updated, WIP (work in progess), Final, TBD (To be determined). I will place these icons in the top post along the code/media links. My goal here is to help organize, not control. So if someone else would desire to take on a few of these logistic issues, I would be greatful. |
| ||
| Frank, What about asking MasterBeaker for a forum? If there isn't space available there to store files, then I could let you use some of my space. (I can give you a login to upload/maintain the files) |
| ||
| i strongly beleive we should continue to post our source into the archives as well. i think that we still need to get people into helping build plasma. if someone uses the bot or gui module in another application and finds a flaw or something that can be done better, PLASMA benifits . We need to stick close to the blitz community. Removing plasma from that will choke off the flow of creative blitz developers. In the past it has happened like this on more than one occasion. My only concern is that once plasma starts breaking up into component development, this one forum may not be enough. but for right now we are not an army of coders. I think there are like maybe 4-5 of us. @frank logistics wise, what would you like others to take over? id be happy to help. |
| ||
| Maybe we better set a link in the code archives to the download area of a simple project-dedicated page. As dangerdave suggested we could use his upload script and his space. |
| ||
| Maybe we better set a link in the code archives to the download area of a simple project-dedicated page. As dangerdave suggested we could use his upload script and his space. I will also post a link in the top post, when the simple project-dedicated page is created. |
| ||
| Well guys after a week of coding pathfinding, the Pathfinding System I've devised will support: 1) Precalculated PathTables, 2) Real-time Multi-tier Pathfinding, 3)CollisionMaps with variable terrain cost for Realtime pathfinding, 4) Precalculated and Realtime Hybrid Pathfinding systems. Precalculated PathTables offer the fastest processing time and best memory consumption ratio. I really desire to use a realtime pathfinding system, PathTables are more appealing due to their speed advantage. If PathTables are used, A tool of some sort will need to be developed to perform the calculations within level maps save the data. I have idea(s) for such a tool and they will rely on realtime pathfinding algorithms to calculate the paths. There are some advantages to using a Realtime Pathfinding Algos and there can be uses for it in conjunction with Pathtables (ie: Obstacle avoidance). Pathfinding heuristics can be used to determine items closer to the bot and select dependent on that value. Also the shortest path isn't always the best path a human would take, so a using a quirky A* in this scenerio could be useful. I will leave the Realtime Pathfinding Capability in there just in case. My next step is generate a Precalculated PathTable in a test level, move a bot from pathnode-to-pathnode and then integrate more sensors. |
| ||
| Sorry for taking long. Work sucks. I'm just about finished the page and will be ready to store files shortly. |
| ||
| cool :) BTW Frank - about the naming conventiones: please add a remark that says: Any Types, Globals or whatever which are not local should be postfixed by the Authors TLA like the modules as well. Example: Global machine_speed_JFK your MEdia Conventions read like they where written in stone. 1) All 3D geometry should be in the B3D format. Why? 2) All Game Entities Properties should be defined in CSV (Comma Delimited) Format File. ok, if you really want it. 3) Auxillary Binary Data files should have *.dat extension. Example(s): PathTable.dat, Portal.dat .dat is a known audio format extension. I think this isn't a good choice. I'd prevere something like ".plasdat" Guess we are not restricted to msdos compatibility. |
| ||
| 1)PRO: this may be because the format is not something that most people cannot change or mod. Down the road blitz may support additional features for storing in the format also. Also, if any of the other types change (ie is no longer compatable) we still have a language standard that never goes out of date. Con: though i think we should stick to some sort of standard, what about 3ds or other models that use bone structs etc. are we limiting oursleves here>? 2)PRo: easy to edit, easy to read (relativly) Con: easy for moders to read or someone to change features of a game (ie more ammo, lower gravity). If we use a binary format we might be able to store information in a smaller file, and thus restrict user modifications. 3)*.dat or *.plasdat it really doesnt matter to me. But i do think we should ensure that there is some sort of header marker to determine what the file is used for. ie path data, trigger data, etc. |
| ||
| Can someone come up a small icon for Project PLASMA? I can try but it wil look like fecal matter. |
| ||
| * * * * * * * * * * * * * * * * * * * * Yay!! * * * * * * * * * * * * * * * * * * * * Please visit Project PLASMA 2004 |
| ||
| To: Frank, JFK, BaudSpeed Please email me and I will give you the login info to ftp to the site when need to make changes or add something. =============================== To: Everyone Please let me know if you notice any problems with the site. You'll notice that is a similar layout as Franks first post in this thread, so it should be simple to use. Thanks, Dave |
| ||
| jfk, Nothing is in stone my friend, however, we can set these standards early in the process so everyone is on the same page. Heres my reasons for electing the following data formats: The Blitz3D file format (B3D) is a 3D file format specifically designed for use with Blitz3D. Many game specific features are supported including vertex coloring, multitexturing, boned animations and so on. The use of B3D has increased significantly in the community. Additionally there are many converter tools available (ie B3D Pipeline tools). Comma-Delimited Text Format (CSV) A data format in which each piece of data is separated by a comma. This is a popular format for transferring data from one application to another, because most database systems are able to import and export comma-delimited data. *.DAT file extension was optional. Just want a easy means of identifying such files. Baudspeed, If compression and encryption become an issue I will write functions to convert the CSV text into a binary. Leaving the data in moddable state will be beneficial to those trying to learn. dangerdave99, Lookin Good! Please email ftp login info to frankie_taylor@... Subject: PPF2K4 |
| ||
| frank, it makes sense. It wouldnt be too hard to convert encrypted CSV data files anyhow, since the loader would be the same. You would only have to decrypt to the directory, read, then delete. just would take a moment longer to load. |
| ||
| DangerDave - this is great, thanks a lot!!! BTW.I forgot to add a readme text into astar3d.zip- the programm mus tbe run from inside the Maplet Folder - maybe add this Note to the Link on the Page, thx. (something like "uses Maplet test.b3d level") |
| ||
| Just curious, is it to hard or difficult or messy to have misc. data like pathnodes, starting positions, item positions and other customized data inside the .b3d file itself? As in something like Fredborg's gile[s] b3d parser? I haven't even tried any thing like that yet as I haven't had time dedicated to try it. I would just think it would be nice to stuff all the misc data belonging to a level in the level's own b3d file. |
| ||
| JFK, Are you sure about the astar3d.zip needing to be in the maplet folder? (It doesn't use the test.b3d file) I can run it fine elsewhere. The waypoint demo needs to be in the maplet folder as it uses the test.b3d level. Note that it already has a readme stating that the program must be run in the maplet folder. =================================== |
| ||
| Just curious, is it to hard or difficult or messy to have misc. data like pathnodes, starting positions, item positions and other customized data inside the .b3d file itself? * I would just think it would be nice to stuff all the misc data belonging to a level in the level's own b3d file. Todd, I agree 200%. My Level Loader is designed to parse CSV data files and B3D Geometry files using a simple Label Scheme. More details can be found here. |
| ||
| Frank, The WipZip indicated in the code archives ain't working. The file cannot be found. =============== Also, did you get my email? |
| ||
| dangerdave99, Sorry its removed for bug hunting. I will post another soon. |
| ||
| I think I see now. I can just delete the csv part in that level.bb code and work with the b3d part. That should help me devise a plan for my editor. Thanks Frank. |
| ||
| I know its not high on everyones list, but i thought i would mention why the code standards havent been updated. Real life has intervened, and I have to eat. So it looks like im not going to be able to contribute much for a week or so. Sorry guys. Gotta take care of some client contracts. BBL |
| ||
| dangerdave - urgh! stupid me :) |
| ||
| wotsup? |
| ||
| I'm finalizing the pathfinding system for the Bot.bb Module. Once I'm complete I will be putting the system to action in a test level. I would like to get my hands on a complete B3D character. I'm not certain what everyone else is working on. I believe the Main.bb, Level.bb, and Convention provide a basic core framework. Following these guidelines other modules can be developed now. |
| ||
| Is there a list of the animation sequences a bot must support? |
| ||
| I'm not certain how complex we want animation sequences, the more the better:) I assume Bots should be able to mimic player movement: Walk Walk & Fire Run Run & Fire Stand & Fire Stand & Taunt Jump Strafe Left/Right & Fire Duck & Fire Kneel & Fire PowerUp Would like to see ideas from others. |
| ||
| It seems like the fire variants are pretty resource consuming. Mabye we can find a way to make the fire animation a second animation layer? This would mean we need a bone (or child) name convention for some of the bones. BTW I made the CSP engine support both, B3D bones manipulation and 3DS Children manipulation (as a 2nd ani-layer, after updateworld()), it's possible to support both. And you're happy when you have a 3DS with complete Animations and don't have to port it to B3D first (eg: Darkmatter Chars) However, I think we should use only a minimum, and leave the door open for additional modes. If we only use a minimum, it will take much less manpower to put some Characters together. You forgot an important one: Dieing. Maybe in about 3 variants. And maybe a hit-by-bullet animation. |
| ||
| BTW I would also like to suggest we should use at least both, Comma delimited and Linebreak delimited data in datafiles. I vote for flexibility. Linebreak delimited datafiles, using strings for all values, will allow visual debugging and even on-the-fly editing of things much easier. |
| ||
| jfk, Linebreak Delimited Data files and 3DS are in! I hope these formats will meet the needs. One of the problems I experienced with the first PPF was that everyone wanted to change the standards, sadly nothing was ever completed. I have to admit that Model and animation is not my specialty:( I agree that 5 variants are too much. Simple is better. Bot Control is totally dependent on the model animations. It will not be a problem for me to adapt the bot.bb to manage once I now the animations are to be used. Another possibility may be to divide the animation control in two: upper | lower body animation. Halo had a really good example of this in which you could rotate the upper body independently of the lower body. This technique may not be suitable for bots, but, could be great for an optional 3rd Person player control. |
| ||
| the multiple body part thing will complicate the character design a lot. I think quake 3 uses that kind of modularity. I am reall ynot shure what's better. Somehow it also looks unrealistic when the upper body part moves the same, no matter if the legs are running or walking. Again I am afraid we go too far. Let's keep this simple and open for additions, let's finish a slim game engine first. For now we could take some Darkmatter Characters for the AI tests. Some of the animations on the CD are real crap, but I edited them and also added a running animation. Download the Pretzel Demo of my CSP Engine (Demo 2) and grab one of those Chars from the Char Folder. @All - this was directed to Plasma Members, not to the public. The Models are from the Darkmatter CD, which you cannot use if you don't own the cd and the additional Animations are copyright by me, all rights reserved, no offense. @Frank - that Animation set is what I use in my Engine, it is an absolute minimum - you'll see. |
| ||
| what sort of charatcers are you requiring ie what genre - military/sci fi etc |
| ||
| Again I am afraid we go too far. Let's keep this simple and open for additions, let's finish a slim game engine first. Agreed. Thanks. |
| ||
| Ruz, For now a basic character is fine, although, I love sci-fi. BTW, checked out your site, great modeling work! |
| ||
| Ruz - if you can help us with a character this woud be fantastic! |
| ||
| cheers Frank Yeah i was going to do bobo's new challenge on polycount,but I may give this a shot instead Just give me some time to sort a few things out and I will see what I can do.I already have a quite few 'heads' that have no home and I have a default model I built for making other mdoels off for the body, so it would not take too long hopefully Polycount- I feel that since there are no weighted vertices for Blitz, we should stick to around a 1000 poly budget. I have a finished fps player view hand/arm that I made too if you want it. Texture resolution? Perhaps a single skin for the head, single skin for the body 256x256 each? |
| ||
| Ruz, This sounds very good. How can I assist in finding a home for your model 'heads' & 'hand/arm'. We definately want all the models you can afford to donate to the project:) |
| ||
| What I'm working on... My current Pathfinding Algo uses realtime collision and I've ran into a Collision Bug. I'm using ellipsoid-vs-polygon, apparently EntityCollided() is detecting collision between my worker pivot and level geometry when it should not. This results in an error. I haven't quite figured it out, but, seeking a workaround. I could a use 'Collision Map'. The problem is this is only good for static obstacles, not very good for moving obstacles. A hybrid may be necessary in order to work around the collision bug. I have decided to use Precalculated PathTables for long 'permanent' paths and Realtime Pathfinding for short dynamic collision avoidance. Pathtables simply store a list of waypoint IDs in a bank and assign the bank handle to a PathTableArray(StartWaypointID,GoalWaypointID). The challenge will be to automate generation of waypoints and paths. This will require a utility of some sort. I would like to avoid manually placing waypoints at all cost:) The first idea is to use the Pathfinder to navigate through the level creating paths from specific objects placed in the level. But, I must solve the collsion bug. The second idea is to use the Waypoint Recorder. Using the Waypoint Recorder will require one to navigate through the level from various locations which could be tideous dependent on the size of the level. Game Entities that move on a tracks can benefit from the use of the waypoint recorder. The third idea is to drop a 'blanket' of Waypoints from the top of the level. Using gravity and collision these Waypoints should fall and land on the level geometry at appropiate height. Waypoints out of bounds are removed. Once the waypoints are in place, use the Pathfinding Algorithm generate paths from waypoint to waypoint. Either way scale and item placement will be crucial. Assuming that we all agreed on the '1 Blitz Unit = 1 Meter' rule this shouldnt be a problem. |
| ||
| Frank, Did you get the email I sent you with the login info? There is room on the site to store some media. Just upload and mod the index.hmtl to post a link to it. ================ Manual placement of waypoints may be a pain, but I think that some are necessary. In Unreal, pickups are also waypoints and there is a priority value on the waypoints to indicate the probability that it would be used. This would help bots move around. With the blanket idea, I guess you would have create another way point, after a collision was detected, to keep going down to see if there is another collision. (Ex. An office building where the hallways are stacked up above one another.) |
| ||
| dangerdave, Yes I did received your email and will post the upcoming media in the space. ================ Heres another explanation of the blanket method. Just imagine creating a sandcastle. You take a handfull of tiny seashells and toss them over the top of the sandcastle. The seashells fall and collide, landing at different points of the sandcastle. All the seashells that do not land on the sandcastle are removed. The remaining seashells are points in which we can create paths from one to the other. Unlike throwing seashells in the air, which land in a random fashion. Our blanket of waypoints would be organized in a grid, evenly spaced. |
| ||
| been making you a player model today. coming out quite good I wil post some progress soon. Let me tidy up the arm and I will send it to you. If I get time I will bone it and do some basic animations for you. ie fire, draw, down , idle etc. they are pretty straightforward |
| ||
| Ruz - sounds good! Frank - but with this method you still don't have ways and bare in mind there might be several unregular levels. You could solve this by dropping seashells several times: You drop one, it falls until Y=1.35, then drop a second from 1.34 - this one falls until Y=0.81, then drop a third from 0.80, which is going to fall until Y= 0.24... just until the seashell falls out of the tformpointed min/max vertex Y-coords of the level mesh. Dangerdave - I still have a better version of the 3D A* pathfinding demo, I'll upload it soonish, someone please update the index, later. |
| ||
| here is a little progress. generic sci fi- ish dude and the hand I did while ago. I suppose the hand of the player model should be the same as the hand in the view port, so i will do that when I finish texturing the player model. Its kind of inlfuenced by the stuff I have been doing recently and from UT and UT2003 characters and little bit of 2000 ad thrown in. But it is modelled from scratch and is my baby , so there is no restriction on useage.   |
| ||
| Looks good Ruz! What are you using to make the character? |
| ||
| cheers danger dave. using 3dsmax to make it. |
| ||
| Looks great! |
| ||
| Ruz, Wow! Awesome artwork! I can not wait to put this into action. |
| ||
| cheers Frank. might take me another week to get the thing textured and looking just right, but I will take my time on it. need more portfolio pieces you see as I am applying for jobs right now |
| ||
| Ruz, No worries. Take your time friend. I'm gonna have to make a few utilities to generate waypoints, collisions map etc. I would like to get me hands on the Baudspeed's GUI and Jfk's Waypoint Recorder. |
| ||
| I hope this stuff remains open to the community. :) I'd love some test models. |
| ||
| Of course, it's open source. Frank - my waypoint recorder maybe isn't the best choice since it allows to record a way, but in the end these ways won't allow pathfinding. I would rather say we should try to realize your "seashell" idea. alfter dropping some levels of seashells, and storing them in a one-dimensional, sequentional array, we will assign them to a 3D grid, simply by checking in which xyz-cluster they are. This will be our open bocks for the a A-star path finding. we can then use my 3D pathfinder, or port any other pathfinder to true 3D, precalculate some long distance ways, and probably use it for realtime calulated short range pathfinding. We are really so close - the seashell-idea really seems to be the solution. |
| ||
Anyway, this is the waypoint recorder i used for the demo, real simple stuff, and as I said before, not very useful for real pathfinding. Not at all.
Graphics3D 640,480,16,2
SetBuffer BackBuffer()
Collisions 1,2,2,3
player=CreatePivot()
camera=CreateCamera(player)
TranslateEntity camera,0,.25,0
CameraRange camera,.1,200
PositionEntity player,0,0.7,-1
EntityRadius player,0.3,0.6
EntityType player,1
mesh=LoadMesh( "test.b3d" )
EntityFX mesh,1
EntityType mesh,2
sp#=.05
maxrec=100000
Dim wp#(maxrec,2)
Dim isnode(maxrec)
wp#(0,0)=EntityX(player)
wp#(0,1)=EntityY(player)
wp#(0,2)=EntityZ(player)
wpcount=1
While Not KeyHit(1)
; standard navigation
mxs#=MouseXSpeed()/4
mys#=MouseYSpeed()/4
xa#=(xa#-mxs#)Mod 360
ya#=(ya#+mys#)Mod 360
MoveMouse GraphicsWidth()/2,GraphicsHeight()/2
RotateEntity camera,ya#,0,0
RotateEntity player,0,xa#,0
If KeyDown(200) Then MoveEntity player,0,0,sp
If KeyDown(208) Then MoveEntity player,0,0,-sp
TranslateEntity player,0,-.033,0
UpdateWorld()
RenderWorld()
Text 0,0,TrisRendered()
Text 0,16,wpcount
Flip
; **** recording waypoints ****
If KeyDown(57) Then ; create node
isnode(wpcount)=1
c=CreateCube()
EntityColor c,255,0,0
PositionEntity c,wp#(wpcount,0),wp#(wpcount,1),wp#(wpcount,2)
RotateEntity c,45,45,45
ScaleEntity c,.05,.05,.05
EntityFX c,1
While KeyDown(59)
Delay 1
Wend
EndIf
; record standard points
xd#=Abs(wp#(wpcount,0)-EntityX(player))
yd#=Abs(wp#(wpcount,1)-EntityY(player))
zd#=Abs(wp#(wpcount,2)-EntityZ(player))
curdist#=Sqr(xd#*xd# + yd#*yd# + zd#*zd#)
If curdist#>=1.0 Then
wpcount=wpcount+1
If wpcount>maxrec Then
End
EndIf
wp#(wpcount,0)=EntityX(player)
wp#(wpcount,1)=EntityY(player)
wp#(wpcount,2)=EntityZ(player)
c=CreateCube()
PositionEntity c,wp#(wpcount,0),wp#(wpcount,1),wp#(wpcount,2)
ScaleEntity c,.05,.05,.05
EntityFX c,1
EndIf
Wend
wr=WriteFile("waypoints.bin")
For i=0 To wpcount
WriteFloat wr,wp#(i,0)
WriteFloat wr,wp#(i,1)
WriteFloat wr,wp#(i,2)
WriteInt wr,isnode(i)
Next
CloseFile wr
End
|
| ||
| No no, I said the resources remain open to the community, meaning those lovely models Ruz will be donating ;). I really don't have use for any of this code atm. |
| ||
| jfk, Thanks for the code. The Waypoint Recorder will be part of the Waypoint Generation utility. It will not be used for pathfinding, but, for creating patterned paths, tracks, rails,etc. Such tracks could be used for moving platforms, and other animated props, etc. About seashells, lol. In my current demo you can move a guide and create a matrix of 'markers' to drop over area. The problem is collision. For some unknown, blitz collision isn't working. I'm getting concerned may be trouble within blitz. |
| ||
| this code is way too complicated to test the "drop-zone" method. I suggest to make this work use a prototype that includes NOTHING but the required things. Omit FPS calc and any other unneccessary stuff.
set 3dgfx
Load Mesh
creat 1 drop cube
Set Collision MOde and types
simple camera etc
determine xmin, xmax ymin ... using tFormedX() , Tformpoint with VertxX/y/z etc.
for x=xmin to xmax
for z=zmin to zmax
y=ymax
while y>ymin
y=y-gravity#
position cube at x,y,z
updateworld
if collision then
store logical position (thats x,y,z) in array
inc counter
endif
position cube at x,y,z (to null prev coll. action)
wend
next
next
dim grid(xmax-xmin, ymax-ymin, zmax-zmin)
for i=0 to count-1
; find 3d cluster of this stored collision
grid(int(array(0,i)),int(array(1,i)),int(array(2,i)) )= 1
next
use 3D Pathfinding with Grid(x,y,z) where 1= walkable
|
| ||
| jfk, I found the bug. I know it looks like a lot, but I'm using the same code modules as my other wips, with the new edition being the marker code. |
| ||
| are you having multiskins on this project? who is building the levels/maps Is it BSP or mesh geometry |
| ||
| Ruz, I'm not sure exactly what is meant by the term 'multiskins'. However, if it means using multi-mesh characters, I'm sure we would like to support it. We dont have an official level builder at the moment. However, per media convention, the levels will be B3D or 3DS mesh geometry. |
| ||
| I mean characters have interchangeable skins so you can load more than one skin on to a single character/mesh Unreal tournament style. I was just thinking aloud though, its not really essential at this stage anyway Regarding the levels, thats cool enough.Just would be nice if you could find a really good level builder. |
| ||
Waypoint Editing Utility Almost Done! |
| ||
| Looks really ace so far guys! Keep it all up!! I just popped in here to see if I could volunteer my services as a musician for this project. I understand it's early days yet, and it's all good if you don't need a musician right now. Just consider me, is all I ask. I'd be happy to create a couple of tracks for this game. |
| ||
| 'way ' to go on thw waypoints. I have been skinning the player model. its coming out quite nice so far. Its been tough cause I am no concept artist, but its comin' out interesting so far will post some stuff tomorrow |
| ||
| Ruz: Toss the player model over my way some time, I'll try my hand at skinning it. I've been needin' the practice anyways. :) |
| ||
| Frank, I know it wouldn't be done until it works properly, but for optimization sake, the editor will get rid of all of those redundant waypoints right? |
| ||
| As far as I see these waypoints are not waypoints, but walkable, _potential_ waypoints, they can be used for all kinds of pathfinding. It is just a matter of a hand full of linepicks to detemine if there are walls between 2 points. Frank, does it already support multiple levels? And BTW: you can check the slope of the colliding Ground ( CollisionNX() etc. ) and decide not to set a waypoint if it's too steep. |
| ||
| Noel , no probs. I am still working on the uv layouts whilst skinning it. I did finish them , but I needed to rearrange some bits (as usual). Soon as I finish I will send you the SDK. |
| ||
| Ash, Welcome to the team! You can create tracks anytime. Just post your links here and I will move them to top post. dangerdave, The spacing between the waypoints can be adjusted. The scale of the game level must be accounted for. The editor will allow you to go thru and remove waypoints that land improperly. You can also set threshholds for waypoints to be removed. jfk, I call them Waypoint Markers. Yes, It supports multiple levels and the slope of the colliding ground. Just move and adjust the Guide, Right click to the drop the markers. I'm now adding open/save and other user-friendly features, but, it will lack a GUI. I will post the app when complete. |
| ||
| heres the WIP of the player model. been slow going but its getting to a reaosonable stage now. may have to remodel some bits of it, feet in particular and the knee pads. But I am sure now that it will get finished and look alright.  |
| ||
| Yeah it been hard because i am not really a concept dude, so i am kind of working on it as I go along. but anyway its early days yet, lots to improve on . colours are a a bit dirty in places right now. |
| ||
| I can do concept art. Been looking for a reason to keep at it. If you want I can start doing some stuff I just need to know what everyone wants. (Im not fast but Ive been told im good.) |
| ||
| Ruz, That is looking too sweet! Totally professional. a unique work of art, possessing futuristic edges and medieval finish. Keep up the good work. |
| ||
| looks great. up to date quality. |
| ||
| Looks super, Ruz! ------------- Shattered, post some art, image plane, if you can. I don't have enough imagination to come up with something decent, but would love to practice modelling. ------------- I'll upload the media to the website when it's ready. (If Frank doesn't do it first) ------------- I'm trying to find a more automated/easier way to let the plasma peeps upload and post news. |
| ||
| Please you like it so far guys. i will do some more on it tomorrow.it has a long way to go yet. , but I am taking my time on this one. I might give him some kind of head gear/goggles too dangerdave modelling is a pain sometimes( for me anyway). Its fairly easy to make it look good in the viewport, but making it so that its easy to texture and animate is another story. |
| ||
| Ruz, I was just thinking that those thigh plates and knee plates would like funny when animated if they weren't part of the model. |
| ||
| Danger dave- I have just rigged it and the knees work well, because the kneepads become part of the lower leg and it dfroms quite well( the kneepad is semi attached to the leg). Without it you have the problems of the knee deforming. Hard to explain but I will post some pics soon The thigh plates is just a tetxure, and is in fact leg geometry. The part Im having more probs with is the shoulder, but I will sort it out soon |
| ||
| I'll be happy to lend my musical talents and create some in-game music - pretty much whatever you need for a finished game / engine. Let me know if you wish to use my services. Mike Felker |
| ||
| you know the fact that we can't use weighted vertices is a real pain in the bottom.( pc swearing) I got the knees/elbows and even the groin area to deform quite well without weighting, but the shoulders are proving a real pain. I may have to start inserting extra bones to compensate |
| ||
| MusicMan - of course, you are welcome! Ruz - I feel with you :) But eh - shoulders don't deform that much, or do they? Anyway, you're the specialist, not me. |
| ||
| jfk, What information and data format (line delimited, binary, etc) would you like to save the waypoint 'markers' in. Once I have this I will upload the Waypointer Utility. Thanx |
| ||
| Uh - binary floats? int number of markers float x float y float z ... I think this is only a list of markers, not assigned to a space cluster, and no paths stored, right? I would really save them as a simple list. It will be easy to assign them to a 3D Grid, based on their position, and then do 6 linepicks from each marker, in every direction. If the surrounding markers can be picked or seen, there is no obstacle in between them. We could use a second Grid for the obstacles, and use it for the pathfinding stuff. |
| ||
| Yeah I sorted that problem JFK . its just a question of builiding the mesh in a particalar way. now I know it deforms ok I feel better.Thank goodness for shoulder pads More pics soon. |
| ||
| Team, I have finalized Waypointer - Waypoint Editing Utility (for the lack of a better name). For best results please read the instructions first. I made every effort to make it user friendly without a GUI:) If more instructions is needed, please advise. Thanx |
| ||
| I tried it but i am kinda confused. will one lmb rasterize the whole level? are the blue pyramids the markers? or how should they look? |
| ||
| jfk, The blue pyramids are nothing, but, you can use them to gain your bearing. You will not see any Markers until you drop them. Move the Marker Guide (Yellow Quad) Over the area you want to drop Markers. You can adjust the size of the Guide [F1] for Controls. Once you have the Guide where you want it, Press LMB to drop markers. |
| ||
| ah, ok, got it. But now I have 2 suggestions: You should scale the guide quad to the complete size of the Level. You can achieve this by parsing all vertices, using TFormPoint to get their real world positions and store both, the min and max of x and z. this complete x*z size will then be used as the guide size. you should also store y Min and Max, and drop the markers from Y max, and (see below) continue dropping them until they are out of Y-min. Second: Although it is possible to drop Markers on multiple levels/floors now, it cannot be done in one step. You should implement a feature that will -position a marker when it hits the ground -continue seeking for the next lower floor until it's out of the meshes Y-minimum. If both things are implemented, it will be a one-click job, and everything can be automated, including pathfinding etc. What do you think? |
| ||
| BTW we need a new thread, you can link to this one in the first post. |
   |