Project PLASMA FPS 2004: Thread 4
Blitz3D Forums/Blitz3D Programming/Project PLASMA FPS 2004: Thread 4
| ||
Yay!! A new thread! OOPS! As I am sure you will notice Frank, there aren't any filename extensions specified for the images in your post. I will be looking at updating the website again with PostNuke and the UpDownload module as noted in the previous post. Hopefully, I will be able to do it today. Thanks Dave |
| ||
Looking for cool Helmet models for the RedBron character. dangerdave, The missing images appear to be a Blitz Forum problem. The forum is stripping off *. g i f extension. Test. I converter the images to jpgs. |
| ||
I updated the site. There is more to do. Please let me know if the accounts work. Please remember I set the password back to what it was. Thanks Dave |
| ||
why does he need a helmet frank.I designed the character without one for a reason because I thought it looked better. i really don't mind if other people reskin my work(I like that in fact) but I would rather they left my colours/design alone if thats ok . If there is a 'considered' design for a helmet I don't mind so much , but just to bung one on because it might look better I am not happy with. I did leave some space in the head uv layout in case we needed to add accessories in the future.I was thinking of giving him goggles on the top of his head , but didn't get around to it. |
| ||
RedBron is an excellent character design. My purpose for the armor helmet is a power up accessory. However, it is not a necessity. However, we should allow and promote the design of accessories and attachements for the character to encourage contribution to the project. |
| ||
jfk, I have only been able to get the bots to run using the waypoint recorder. Now I have to wrap my brain around animation. |
| ||
well long as they look good I have no problems with that. I should have explained before I started doing this work that the way I work is in stages. ie do the basic design , wait til the project moves on a bit then refine it, add some more. otherwise if the project dies, then a lot of work has been done for nothing. blame years of working on unfinished mods. hey good luck with the animation jfk, hope you make a better job of it than i am doing on my other project. |
| ||
I read from a recent post there was a website with a stock moves (model animation) archive, I'm sure you could find a lot of resources for that stuff on the net. If you needed to that is. |
| ||
Are you talking about motion tracking animation data files? I saw that, it's nice, but still I didn't see a way to assign them to B3D. Ruz - that was Frank, he said he's gonna use the Animations in the bot control. I didn't start animate the model yet. Maybe later. Dave - Site looks nice, but the image tags don't work in the middle cell. no more forum? |
| ||
I'm in the logo. Neat. :P Edit: And for the uninformed, I am indeed an android. |
| ||
Awesome work to Ruz and Noel on the models!! The stock moves i was talking about was from here: http://www.e-motek.com/stockmoves/ It looks like they're compatible with 3DS Max 3 and should be + from there, but I haven't downloaded the stuff so, I don't know. |
| ||
I might be overlooking a very basic Blitz3D command, but is one to control the each frame of animation? |
| ||
Aw, now I'm not ;) |
| ||
actuaally they seem like a bit of a waste of time codeD we have the basic anims anyway now . things like idle are not very hard to do anyway. That reminds me of an interview I had . whilst being shiown around they kept telling me that they used stock libraries for animation. so i asks them , 'did you use stock animtion for that shotgun sequence.?' hmmph no of course not came the reply. well tickle me with a feather , i didn't get the job, miserable gits frank , do you mean setanimkey? |
| ||
Ruz, 'SetAnimKey' is for recording a keyframe. I would like to have control over the each animation frame per loop. I desire this control to sync weapon fire etc with the character. I reckon I have keep track of the sequence and frames manually. |
| ||
Why not just pick up what frame it's on with animtime? That's what I use for footsteps, gunshots flashes and stuff. |
| ||
Rob Farley, I have yet to use that command. I will give it a try. |
| ||
Animseq is also a handy one to use in conjunction so you know what animation it's doing. |
| ||
Also if you want to animate manually frame to frame just extractanimseq for each frame making each animation 1 frame each. Then just animate each anim sequence one shot and set the transition time so it's smooth. |
| ||
you could use the the new handy, fix animation as you like it function. almost as cool as the get rich quick function I am working on. |
| ||
dangerdave, Good job on the website. I see that you have implemented PostNuke. Click on the PPF2k4 Banner in the top post to go to the PPF2k4 HomePage. I have been working on Bot AI and Animation. This is relatively new areas for me, but, im really enjoying it and learning a great deal. I would like to discuss my implementation for more feedback. I'm using Finite State Machine AI which is divided into primary 3 functions: botSensor, botReaction, and botMotor. The botSensor is where conditional checks are performed to set the bots state. The botReaction selects a 'Action' and Animation dependent on the state. The botMotor performs movement of the bot. At the moment, the AI States are geared around the RedBron animations, however, they can be easily expanded. Heres a list of the animations: run, still, runfire, stillfire, takehit, die1, die2, idle. The botSensor is a list of conditional checks arranged in lowest to highest priority order. Currently Seek&Destroy is the only Behavior simulated. However, I would to like add other Behaviors (ie Hit&Run, Sniper, grouping, etc). I will be adding checks to the botSensor to determine health and ammo, so that bots will seek health and ammo when depleted. Pathfinding is major portion of the AI. Bots must navigate from any point to another 'legally' and intelligently. I'm currently using a recorded track of Waypoints. There is no processing require with this technique and its really fast. Bots can transverse the level very easy. Bots can handle deadends with no problem. I really have to do some tweaking in this department to make the pathfinding more intelligent. Other stuff I've taken the liberty to write down some code structs for other objects: Switch (multipurpose trigger for actions and events) Ladder (verticle climb) Door (sliding, swivel) Platform (vertical/horizontal moving lifts) Prop (ie oil-drums, fans, etc) Spawner (bots, ammo, power ups) Teleporter Soundfield (sound) Light (flare, halos etc) I have not generated any code but can at a moments notice using Typewriter code generator. Considering bots may interact with some of these objects, I'm going to move forward with code. |
| ||
Thanks Frank! This last post is exactly what I would like added as a newspost on the site. Great stuff. =========================== I like the approach you are taking for AI. ============================== JFK and Ruz, I'm sorry to have you go through it again, but please log onto the site so I can add you as forum mods. Also Noel and Bob3D, and everyone else, Please create an account at the site as well. We'd like to have more input on the Project. Thanks Dave |
| ||
Frank please be careful with taking liberties (and declare other work as obsolete). From time to time I ask myself if we need some more coders in this team, to complete our lack of knowledge about the blitz programming language. I hope you agree. |
| ||
Frank please be careful with taking liberties (and declare other work as obsolete). Please remember this is a open source project and noone's work is declared obsolete. However, if you feel this is a concern perhaps we need a list of who and what is in the works.I agree we need more coders and hope some volunteer soon. Until more coders sign on, we should proceed. If a better system arrives we can always modify the code. |
| ||
What is a sound field? Isn't that already in the editor? |
| ||
A stationary 3D sound within the game engine. |
| ||
That's already in the editor. The example map that comes with the editor contains 3 sounds, didn't you hear that? You can choose a Sound file and position it in Space as 3D Sound. Whoever has ears to hear, let him hear. Anyway. |
| ||
That's already in the editor. The example map that comes with the editor contains 3 sounds, didn't you hear that? You can choose a Sound file and position it in Space as 3D Sound. jfk,Whoever has ears to hear, let him hear. Appearently, there is a misunderstanding. You are suggesting that Editor and Engine are the same. I was under the impression we were using Pledit to only orientate objects within the level and save them as PLD. I don't see a problem with fusing the editor and engine and would prefer to do this for true WYSIWYG. However, the pledit source is not perfectly structured and cleaned up. It will need a major rewrite for modularity. The engine and editor should use the same code modules. I must stress MODULARITY. The engine main.bb should be structured as whats described here to support a Modular design. This is very common and many coders develop their code in this fashion. Other coders could easy create code module and add it to the engine main file as long as they provide a 'Start','Update' and 'Stop' Function of some sort. Hypothetically, if I were to rewrite Pledit I would consolidate the following: 1. Use a configurable keymap for controls. 2. Replace the generic object with object structures directly. 3. Replace 2D Gui with InGame 3D Gui objects. 4. Add additional features WaypointRecorder, particle editor, ammo editor, etc. However, I want to avoid any of this. All that is required at the moment is using a conversion between object code structure and editor object structure. This is relatively simple. |
| ||
Uh- we have kinda communication problem. i need a break. |
| ||
jfk, Please advise what the communication problem is. You quoted in the first thread that your own project was opensource, but it became kinda disguised-in-shame-of-spaghetti-code. I fear that if we do not communicate specifically what our intentions are this will reoccur. I truly believe the reason why other coders have not joined the project is due to the lack of defined game objects and who is working them. Which is why I frequently request we develop a To-Do-List of game objects/properties and whos working them. As a modular game engine, I truly believe that more than one code module could be developed at once. Others could take a gander at the To-Do-List, pick an game object to work, and code it. I have stated many times that I'm working on BotAI and how I'm implementing it, however, I have no idea what others are coding :( Pledit is a great contribution. From my perspective, the only difference between the editor and 'engine' is the gui interface. The engine could use the very same load/save functions and gui for games. This is why I propose that they share the same code modules. As we improve code for one, we improve the code for the other, is this not more effecient? Shambler and others expressed that using generic set of data for game objects would be unsuitable. I would agree. However, this can be solved with translators implmented into the levelloader/saver to transfer info between editor object and engine game object code constructs. Shambler provided some code constructs for lift and soundfield game objects earlier in the project: 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 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 TypeAll that is needed is liftStart, liftUpdate, liftStop, soundStart, soundUpdate, soundStop functions for engine main. I could easily use the Typewriter to generate a code module for each of these constructs in a few minutes. In fact, the objectStart() could be used by the levelloader to load in the data for that particular game object. I have integrated your seek&destroy and waypoint recorder system into a modular system. It was relatively easy to do because I identified the common variables between our two systems and merge them. My point is, I used your code only modifying the labels, save myself lots of work. I'm doing the same for Pledit. The major problem with pledit is that the gui is 2D and directly integrated into the editor. Its a very nice gui, however, its not modular. I strongly believe that it will save us major heartache to convert the gui into a modular 3D gui (hud) which could be used in the games as well. The big benefit is that others could add new gui controls. I'm not declaring others work as obsolete. On the contrary I'm binding them to work together. Binding different code together is an extremely difficult task for a open source project. This is something that did not occur in the first PPF, thus, it r.i.p. In spite of the appearence, there is a significant portion of the engine completed we just have to bind the components together. |
| ||
You guys need help with the music? What kind of tunes?? Here's one of my original techno like songs with my own vocals too, if anyone wants to use it in non-commercial or commercial stuff that's fine but it is copyrighted so please ask before you use it (flamecoaster@...) and give credits!! Especially if you want to use it a commercial project (ask first) http://sites.gwala.net/tormented/transmission2.mp3 |
| ||
Thanks CodeD. |
| ||
It seems like I don't fit in this structure of teamwork, I mean, my workflow and code structure is diffrent from the one of all other coders of this project. (that's you) I thought we can use my Editor and simply rewrite the loader, but since some people told you my object structure is crap - it must be that way. So I better go back to my silly spaghetti code and let the real programmers with lots of practice do the job. lol. In fact I miss some respect. Since I am the only one in this team who actually produced a working FPS Engine, I thought people would listen to my suggestions. You lead the project, but now it turns out you even don't know a lot of essential Blitz Commands. What's the point. Finally I have to listen to the facts and to my feelings. Feel free to use my 3D Astar conversion, the Seek and Destroy AI, the Editor (GNU-released), the Test Map. Good luck. |
| ||
jfk, Thank you for your contributions. Wish you luck on your next project. |
| ||
CodeD, The soundtrack is very good. Can it be distributed freely? |
| ||
Did I mention this is where the project will most likely die? |
| ||
I was going to say the same thing. jfk I don't think you should leave , you bring valauable experience to the project.I think you and frank just have to find a way to work together.ie split up stuff and frank perhaps you should give jfk some slack. As he says he did produce a fps engine already. the editor was fine ie it worked well/good navigation and you could place stuff. thats all we need for now. I think the approach is a litle wrong here. in order to attract more people , you do things in small chunks. ie do a test level, get some bots running around, have one weapon. etc. then release the demo. Its fine producing the next be all end all game engine , but it needs other people involved. I wonder why no one is, since there are lots of coders around here. |
| ||
Hi, I've been following the developments on this thread since it began and I agree with Ruz's comments. jfk I don't think you should leave Just take a break for a week or two. Cheers, Rogue Vector |
| ||
Team, I don't understand why some of you feel the project is dying, but, I can assure you it is false. People come and go. It is the nature of an open source project. I'm not certain as to why jfk has chose to leave, however, he can return at anytime. Jfk has made several contributions in code and media. Most of jfk's concepts and code have been integrated into my own. What better form of collaboration. Collaboration is the key, and I have made efforts and will continue to do so. I must stress that MODULARITY for this game engine is critical. Build a base of game objects and add on top of them. The 'engine' is binding these game objects to work together. There is no design document, but, we do have a pretty good idea what game objects need to be developed as there are plenty FPS games. Currently, there are several game objects not defined. We know that FPS games contain Doors, Ladders, Lifts, Spawners, Keys & Switches, Props, Soundfields, Lights, and HUD(gui). These interactive game objects behave practically identical in every FPS. I cannot find a solid reason why they could not be developed now if their properties were defined. This brings me to the concerns with the Pledit editor. Currently, The Pledit editor uses a generic object management system the game engine does not. Developers can write code that define Doors, Ladders, Lifts, Spawners, Keys & Switches, Props, Soundfields, and Lights in a variety of ways. The engine loader will have to support this possibility, which is why a separate loader has to be developed. The Pledit GUI is directly integrated into the code of the editor. Its a very good one at that, however, if the gui was modular it be used for other tools. A 3D Gui would even serve a greater purpose as it could be used for in-game HUD. The Loader and GUI is only difference between the editor and game engine. What if the editor and engine use the same Loader and GUI? A Editor could be built directly into the Game Engine for true WYSIWYG content editing. The editor should be built around the engine not the reverse. A simple text editor could be used as a game editor for that matter. Now, with all this said. I'm using Pledit in its current form to slap together a test level and get some bots running around. But, the engine will require a different loader and GUI system. Ultimately, the current form of Pledit will be replaced with an Builtin Editor once thes game components are created. |
| ||
Hiyas, is a 4.6 meg .ogg file to big? I have a 128kbps music file with a time length of 4:52. Frank you may remmeber the Plasma Ace.ogg file I did, well this is the Full final version of it. I think I need to get rid of my vocal in there, but the song was made to be a "title" music style song. Anyways, I want to upload it to the Plasma website, but the uploader thingy a roo hasn't been implmented yet? I could put it on my site to download, but I wont have it on my site for long as it would kill my website's bandwidth limit if alot of interested people wanted to download it. Otherwise I'll just keep to allll my self. :) ---- "Ye of little faith that think Plasma will die? Never!!!", Pepsi[02-27-04] "Most of the matter in the universe is in the plasma state.", uhmmm ??? |
| ||
Ok, I'll have this link up to the plasma ace song for a couple days. Remmeber, like I said above, it's 4.6 meg... Please read above and let me know. Thanks. Download here! |
| ||
I feel like making a GUI. |
| ||
a gooey? |
| ||
Todd, Excellent Work! Well be in top post shortly. Noel Cower, I'm glad you feel that way, because gui programming can be challenge:) Are you making a 3D GUI? I do have some older code that was wip. Its available if your interested. |
| ||
Frank Taylor: 3D is the only way I'd go, since drawing it all in 2D isn't in my favor. I've got some ideas on how to do it. Though a few things I'm not sure about are resizing windows, events, and drawing multiple 'chunks' of a window (e.g., title bar, menu bar, left scroll bar, right scroll bar, etc.). If you have any code that can help me as far as those go I'd be happy if you shared it. |
| ||
Hi! This project seems to be very promising. If you need some 2D(Textures&Hud) Stuff let me know ! Here are some pics of my recent work : http://www.blitzbasic.com/Community/posts.php?topic=30496 http://www.blitzbasic.com/Community/posts.php?topic=30899 BTW: Is there any Background-Story behind Plasma ? |
| ||
bnot bad at all. did you shrink em down from a bigger size because they look a little blurry, but otherwise nice |
| ||
Noel, I agree, 3D is the way to go. Well, I can post what I have. Resizing windows has to be done carfully in order to maintain pixel perfect image. The gui should also support bitmap fonts. I hope you like using Blitz Types cause I use almost soley. Now dont let my massive Gadget structure scare you:) It has provisions for using meshes, animation, sound, and specialty gadgets. The use of this is totally optional, but, I'm converting my old 2D plasma gadget system code structure for use, so, I will be adding code. I will replace this gadget module code with what ever gadget code thats working. Bolo_Loco Great Stuff, Welcome to the team! |
| ||
Level Demo with walking bots coming soon! |
| ||
Thanks Frank for checking out me music, I will be taking that music file off of my website here soon. Looking forward in seeing the level demo! Nice textures, Bolo! |
| ||
Todd, I really love this track! You can remove the sound track off your server at will. Download the Wip Zip. This file contains the exact directory and files structure that I have been working with. You can locate the level demo in the 'Code' Folder labeled 'wiplevel.bb'. Heres what to expect from the 'wiplevel.bb'. The demo switches between a third person and stationary camera. FPS is available, but, requires some code mods. You will simply follow behind one of the bots. The level demonstates integration of contributions featuring: Ruz's RedBron Character jfk/Noel's Plasma level jfk's Props and lights FT's Loader jfk/FT's Bot pathfinding FT's rumblecam Todd's Plasma_ace music This demo is in a very rough form and will get cleaned up. The next demo will show off much more. |
| ||
looks good frank. I only got it running for while becuse this pc doesn't have a very recent vid card. I will check it on my proper pc later . but from what i saw it looked good. well done |
| ||
That's look'n cool, great job guys! The 8-10 second camera movement pause thing when following a character around gets carried over when you go into visibile mode. So when trying to move about in the level on your own, the pause thing became a tad annoying. But, you probably are already aware of that. I assume there isn't any delta time as everything seems to slow down at lower fps rates? Just curious, I havn't had the time to look over the available code for that yet. |
| ||
Hello people, I've been out of action due to nasty flu and cold. I'm still out but I just want to let people know that I am still here. I'm going to say this on the website too. thanks dave |
| ||
Ruz, Thank you for the Amazing RedBron character. dangerdave, Get well soon! Todd, You cannot go in FPS mode in the demo without changing some code. AI is not active. Thats coming up in the next demonstration. I only wanted to let everyone know, no effort is wasted. Team, Take a gander at the code, there are lots of modules, but, if one examines the code they can see just how modular this engine turly is. Anyone can write and add modules to this engine. Once a module is written, I can add it to the Loader. The main.bb should only require the objectStart, objectUpdate, and objectStop functions. We need models and textures for weapontry. As soon as I acquire them, they can be implemented. New characters and props are welcomed as well. The 3D GUI is very important as it will be used for both in-game HUD and Editor Interface. Noel and I would appreciate any help that can be offered in this department. |
| ||
I can manage the hand ok, but weapons are not really my thing. perhaps we can beg and borrow some. anyway I am a bit busy right now with my own project. will try and find some thome real soon |
| ||
I can make some weapons if you guys tell me what you want. |
| ||
I can make some weapons if you guys tell me what you want. Futuristic weapontry (ie: LaserGun, PulseRifle, and PlasmaCannon) with reload and recoil animation:) |
| ||
Sorry to mention this Frank, but instead of working on a GUI for this I've decided to work on one for Vein. It's in my best interests to put it before any community projects, so you'll have to find someone else to write one up. As for contributing to this project again, that won't be happening. I've my reasons. |
| ||
Noel, No problem. Good luck with Vein. |
| ||
I said I would do weapon models, I didnt mention animation. |
| ||
Just did this quick, gotta texturing it then ill probably donate it to the community. I'll get on some models to donate to the blitz community shortly in the style you guys need. www26.brinkster.com/bed1/thompson.jpg |
| ||
I said I would do weapon models, I didnt mention animation. Actually, you stated, "I can make some weapons if you guys tell me what you want." LOL.No problem if theres no animation, sound effects can substitute. BTW, the screenshot is looking good. |
| ||
aniamtion isn't difficult for the weapon. i can knock that up for you. all you basically need for starters is fire,raise weapon,lower weapon,idle. mm I think its a real shame that people are not getting behind this as they should. seems like a worthwhile endeavour. suppose FPS is not everyones cup of tea and we all have our own things to work on. |
| ||
I havnt gotten behind it because with what im working on, a genre specific engine is a waste of time... I'm willing to do art to support general community development, but I can't see putting time into something few will use. FPS's aren't ground breaking, and im more into people doing original things :). |
| ||
what makes you think I was referring to you. In fact I wasn't. I just looked at how much work frank has put in and the lack of help he is receiving and thought it was a shame. And if you feel its a waste of time why did you offer to help? |
| ||
Not being funny but why doesn't the demo have timing? And why does the title *pointlessly* take up the entire screen and slowly and annoyingly scale down? |
| ||
I am sure those things will be resolved at some point rob The demo is just a basic test, not a finished product. |
| ||
I couldn't forgive the basic test for it, sorry. Not being bitchy, it's just totally annoying and pointless having a logo that floats in front of you for at least two minutes. |
| ||
well you will have to ask frank about that,I only designed the character |
| ||
I couldn't forgive the basic test for it, sorry. Not being bitchy, it's just totally annoying and pointless having a logo that floats in front of you for at least two minutes. Have to say that I agree. The lack of timing isnt a big deal, as stated, its a WIP. However when your trying to take a good look at how well the models manipulate the map, and there is this huge logo in front of everything, it makes for a pointless demo. Granted, waiting 3 min for it to shrink down enough to get a good glimpse is a bit of a waste of time. 2 min prior to that I could have had my post on this thread with the "Great job guys, its coming along very well", but alas. Still though, Great job guys! Its coming along nicely! |
| ||
How about to post a screenie with RedBron running through the level? BTW I really hope you make this thing a working Engine asap. Looking forward to see a playable Demo-Game. As I said before - unfortunately I am just not compatible with the workflow. |
| ||
I am sure it would n't take too much effort to get the demo looking like a game. lets see, one weapon, killable bots=basic game in my book. basically you don't even need the weapon, just the weapon code. If no ones going to make a weapon I will give it a go. I have a blaster thing that i did for pearman a while ago which looks quite ok. i will make time this weekend to get that on the go. the models are easy , tis the texturing thats a bitch. I may go off and beg and borrow some weapons too.I know a few people from my mod making days who are quite helpful. |
| ||
Ruz, cool your jets. I was stating my reason(and possible reason others havnt helped) for not helping. If you don' want my help, which is what it sounds like, then I won't. I didn't mean to intrude. Later. |
| ||
I think it's a bit frustrating that exactly now, when the project has four excellent helping designer-hands (ruz and noel) Frank is the only coder of the core team. Because normaly every project has more than enough coders and a lack of designers. So, cmon, some of you blitzers, especially those object-oriented + modular thinking people, lend a hand. |
| ||
jfk: Actually, I left this project. |
| ||
classic crossed wires here shattered reality. course we need your help. if you can do the model, i can animate it . cheers jfk, shame you left and you noel. |
| ||
Well, I had my reasons. I think I made it clear. but anyway, you already have a lot of media content, so theoreticly Frank could finish a working aka playable Demo all alone, using the existing content plus some shotgun and stuff from 3Dcafe or whereever. So, Ruz, don't feel like we left you alone with tons of work. And as Frank said - it's an open source project, people come and go. |
| ||
ah its ok, I havent done that much work on it anyway. i think i would like to make a weapon , since I haven't done a lot of that. I fancy making a crate or barrel of some kind also. |
| ||
As requested some Screenshots of PPF2K4. Click to Vote. |
| ||
... |
| ||
Please still feel free to use my AlphaGUI library as you like. You may modify it anyway you see fit. I have included the source to the editor, and corrected some bugs in the latest update found HERE Or visit the website Btw, the project looks nice :) |
| ||
Jeppe Nielsen, Thanks a million. |
| ||
I don't know what it means but sounds good anyway. cheers Jeppe hey frank i made some headway on my animation control's( thanks to jfk),also finally got my 'line pick' for jumping control working. hooray so I feel happy enough to do some more work this weekend. I will bone the hand and stick a basic weapon in it, do a few animations too. I figured red bron looks a bit crap from the back, so the 3rd person view looks a bit dodgey. When the hand is in place we won't have that problem. Also notice the run fire animation is not as good as the run, will see to that soon. |
| ||
Good work on the demo guys!! Good work so far on the Engine!! |
| ||
Ruz, I'm glad your motivated. I am as well. The animation control sounds interesting. Why are line pick's used for jumping? (lack of knowledge about the subject on my part). I've seen some pretty simple jumping algos that rely on gravity, but, they didn't appear to use line picks. Jeppe's Alpha GUI was the first 3DGUI system developed with Blitz3D. Its ideal for ingame panels and menu systems and uses a very cool bitmapfont system. It comes with a very cool editor. Check out the download. Look forward to seeing what you come up with for the hand/weapon animation. I've been hoping someone would craft a cool weapon for use. Unreal Tournament uses very detailed and animated FPS weapons. Considering a weapon(s) can consume 1/4th of the screen, placing emphasis on it could boost the eyecandy factor IMHO. No matter what we I get, we will definately use it. Prior to PPF2K4, I was working on a Modular Weapon System:Gunvertor. The concept uses a Chassis (boned b3D mesh) to fasten a variety of weapon parts (non-animated|animated meshes) for barrels, chambers, magazines etc, to create a wide assortment of weapontry. I intend to resume development of GunVertor for my FPS titled 'GunVertor' when I complete the RiftWalkers MMORPG Project, following PPF2K4. Both are being developed on top of an FPS Game Engine. CodeD, Thanks. More to come... |
| ||
yeah frank the line pick was just so that you can't jump whilst in the air, thus jumping ever higher while you are pressing rhe jump key, been bugging. me for ages I was using if entity collided to do this previously, but this meant you could jump up the walls gunvertor sounds cool. i am going to do a weapons for my demo soon, planning on attaching it to the biped hand using find child. i did Unreal tournament mods for quite a few years, so i know a fair bit about how they work/animate etc. no expert coder though. I will check out jeppes dl tomorrow too |
| ||
Looks nice, but the RedBron seems to be a bit bright, maybe use entityColor redbron,200,200,200 or something. and the Scaling of the oildrums as well as the containers isn't correct. And the RedBron is too large. If one Blitz Untit is one meter then he's about 2.7 Meters high ATM. And the Light Flares are missing. |
| ||
yeah will tone bron down a bit this weekend. hmm that red is perhaps a bit harsh also |
| ||
. |
| ||
well i improved the hand a lot, grabbed an older weapon i was working on for a different project and started rigging the hand/gun. Don't expect this to be done quick ie fully finished quick, but I will let you have the b3d file, with a couple of animations, ASAP. the thing that takes the most time is the texturing and tweaking to make it loook nice in the viewport, what FOV will you be using frank?I would like to set up my viewport cam in max to match the in game camera as close as poss. its really help if you do that. BTW I improved the run animation by about 35 percent . I finally figured something important out. he he thats the concept of counterbalance |
| ||
Maybe for bron you could just overlay a mask over his armor layer, like a little rust/scratch/battle damage etc. to dull it down a bit?? |
| ||
Ruz, There is no rush on my part. Please take your time. I have a lot of coding to do. The new code wizard will speed things up significantly for me. I'm hoping others interested in coding for the project will at least try the code wizard as its specifically geared for its code convention. I do have concerns about optimization, as I'm uncertain about how much recoding will be needed to implement them and get everything running smoothly. Timing is critical and to be honest, I have never implemented any serious timing. I would appreciate help from those who have. |
| ||
sure frank no prbs. i will jsut do what i can and you can make use of it when you are ready. codeD the problem is one of balance really. when you design a character isolation from the environment, you will always have to tweak it a bit. I am still figuring on doing more work to red bron,when i get the time, but I am happy with how its looking, just small details need taking care of. i think it was full bright in the demo also he he. |
| ||
the greenish lightmapping in that "oval office" bites the red a lot. Guess it look much better with the yellowish lightbulbs and flares. Well, this was meant to be constructive critism. However. . |
| ||
Its ok JFK i would leave your ligths , they look fine. i wil somehow resolve the the red bron color scheme so it fit in better. |
| ||
what FOV will you be using frank?I would like to set up my viewport cam in max to match the in game camera as close as poss. its really help if you do that. Ruz, I'm not certain why you need a specific FOV value, but, we can code it in any fashion. Also, the FOV may vary for ZoomCam etc. I only anticipated attaching the Arm/Weapon to the player camera and adjust the position as needed. Please elaborate, thanx. |
| ||
the reason is that if for example you set the fov at 120 ,( suppsoe 90 is more normal or whatever that equates to in blitz) there gets to be a lot of distortion near to the camera, so if you are not careful your weapan can look like its ten miles long. if I know before hand what the fov equates to in max I can set up a camera in max and see exactly how it going to look in game. anyway its not essential, but would be helpful |
| ||
Ruz, Ok. I'm using the default FOV setting at the moment. I reckon if we have to alter the value, we'll compensate for the arm/weapon. Team, I'm 90% complete with the TypeWritterII Code Wizard. Once complete, I will be revising some of the code modules and restructuring the level loader for the modular implementation. Additionally, from this point forward, I will be heavily commenting code using the Cod2Doc format. This will ease the generation of documentation using the Cod2Doc utility. Most of my recent efforts have been focused on the level loader and defining game objects Doors, Ladders, Lifts, Spawners, Keys & Switches, Props, Soundfields, Lights, and Gadgets(3D Gui) for future development. I desire to refocus on BotAI as soon as possible. |
| ||
Typewriter][ quote Wizard is nearly complete. This quote Wizard has an significantly improved types-within-types management system. It uses independent *.object files to define the Objects (Blitz Types). It will automatically extract and parse 'subtype' properties for use in the CSV functions. This is a BIG advantage. The list object was removed due to size. A complete list is available per request. |
| ||
I have some serious multi-tasking going on:) Working out a new BotSensor Model for Bots. The idea is to create a conditional priority list in which FSM state behavior can be changed dynamically. Even if the bots do not use a dynamic behavior, this is a better way to handle AI as there is room for AI scripting using this approach. Sensor and Ai object properties can be loaded externally from .csv or aux data loader. The new model takes advantage of the binary heap priority queue used in the A* pathfinder. AI Conditions are prioritized from lowest to highest priority. Thus, the botSensor will simply loop through the Conditions setting the state if true. A higher priority condition will overwrite a lower priority as its further down the list. Ultimately the new model should make the AI more flexible so that a variety of Bot Behaviors (Seek&Destroy, Hit&Run, Sniper, Chicken, and Thief) can be implemented. The New and Improved BotSensor Model Type sensor Field id% Field typeid% Field entityid% Field process.queue End Type Type ai Field id% Field typeid% Field action.action Field return# Field compare% Field value# Field state% Field priority% Field life.clock End type Function sensorProcess%(this.sensor) ;Checks Process queue items (ai objects) For loop= 1 To this\process\queueitems% this\ai.ai=aiid(this\process\queueitem[loop]) If aiCompare(this\ai) state%=this\ai\state% Next Return state% End Function Function aiCompare(this.ai) this\return#=botaction(this\action) Select this\compare% Case 1;= if this\return#=this\value# Return True Case 2;<> if this\return#<>this\value# Return True Case 3;> if this\return#>this\value# Return True Case 4;< if this\return#<this\value# Return True Case 5;=> if this\return#=>this\value# Return True Case 6;<= if this\return#<=this\value# Return True End Select End function |
| ||
Long time since I looked at this thread so I've not read it all. I just had an idea about how many people could code the same game keeping their own programming style in the main yet integrating with the rest of the project. All you have to do is set the input and ouput semantics of each function as a standard, treating functions as black boxes, as long as they satisfy the i/o rules then anything goes. This would allow everyone to contribute without being completely bound with programming style constraints. [Edit] I think it was JFK mentioning early in the thread my structs for lift and sound entity types. He then mentioned that all that was needed was a StartLift() StopLift function etc. That's not the way I've programmed SARE engine. Instead there is one function 'Update_Lift()'. Along with this is a set of states and inputs which decide what happens at that particular frame. This way the lift reacts to inputs without interaction from the main program. I use a global variable which acts as a trigger between for example a button and the lift. Every entity in the SARE engine is programmed this way, in fact every entity has just 3 functions Create() Update() Destroy() |
| ||
It wasn't me. But I would agree with your IO Guidelines. |
| ||
Your right, t'was our man Frank. |
| ||
Shambler, Good to hear from you. It was me:) However, the liftStart, liftStop, and liftUpdate functions I referred to behave like create, update, and destroy. I could have label these Init, Remove, etc. I agree with you and proposed this structure earlier with the Main.bb. I've written a Code Wizard that generates common initialization, deletion, load, save (I/O) functions and few others. Its designed specifically for this project. No one is force to use it, however, it could save one some coding time. The only restriction is that its designed to work with types. I would like folks to at least give it a open-minded try and provide some feedback. The type 'objects' above were written to help fill in the void of object definitions. These objects could be designed in variety of ways, but at least now there is something to start with and can be modified as needed. |
| ||
shame I don't know enoug coding to get involved in the debate here frank, but i do look at what you do , but it s a bit over my head right now. I finally sussed my animation controls for my demo. what a freakin nightmare if I see a 'flag' ever gain I will go mad. did a bit of work on the hand,will post some screenies this week |
| ||
TypeWriter][ is complete! Tonight I will be restructuring the levelLoader and code modules with the new modular loaders. |
| ||
Frank: I'm curious, how exactly does 'TypeWriter' work and what does it do that makes it worth using? I haven't got the time to go over the source code and find out for myself, so I'm hoping you could elaborate on its purpose(s). |
| ||
iwas presuming it was some kind of template generator for types |
| ||
Noel Cower, Complete instructions on how to use it, coming up. Ruz is correct it is a template generator for types. |
| ||
Checkout TypeWriter][ Code Wizard for PPF2K4. Comes with two demos: writeobject.bb, writeobjects.bb; and objects files. Please read included help.htm file. |
| ||
Quite the lack of visible activity, aye? |
| ||
well i am still working on my hand/weapon. |
| ||
Whats in the Works: Improved Engine Resource management using Managed ID referencing. This is implemented in most of the code modules and new ones will include it. What is Managed ID Referencing? Well, in a nutshell, I use Blitz custom Types to package every 'object' in the engine. An array of types is used to store and reference each object by an id (index) number. A specific MAX number of objects is defined for ids. A FILO stack is used to track what objects IDs are in use or not in use. IDs are push and popped of the stack as needed. I found this form of management to provide the best flexibility and control for both dynamic and predetermined events. I will be setting up objects to reference others by id. My work with Databases is a heavy motivator for this implementation. Its also known as "Table Oriented Design." Blitz3D Catagory Code Modules. These are modules that package many of the Blitz2D/3D Catagory Objects (ie: Mesh, Sound, Texture, etc) into its own code module for use by the engine. These 'catagory objects' will contain pratically every Blitz property needed to define Brush, BSP, Camera, Entity, Light, Listener/Audio, MD2, Mesh, Mirror, Pivot, Plane, Sprite, Surface, Terrain, Texture. I have found it much easier to edit catagories only referencing or copying them as needed for other objects. Improved Bot AI. Using both Recorded Waypoints and Pathfinding Algo for collision avoidance. I'm going to extend seek and destroy algo to seek out specific waypoints. A variety of Game objects/items can be placed at the 'target' waypoint in which bots seek them out. I have not quite worked out the collision bug in my A* so I'm considering a rewrite. Bots will need some form dynamic pathfinding in order the their behavior to seem more realistic. Improved level Loader. Implementing modular Loader functions in the code modules. Loads game data in ASCII format from CSV and Data files. Managing the level data in CSV is relatively easy. In fact, I'm using Microsoft Excel as level editor to modify the CSV contents. Improved Type Writer][ Code Wizard. I use this utility to generate code, saving much time. The improved version generates initialization, update, destruction, csv loader/saver object functions for use with Level Loader, Editor, and Game Saving. All is that remains for the coder is to write is the modifier and interactivity object functions and modify as necessary. The functions produced are are specifically designed to support the Main.bb framework. Checkout the help file here. Game Objects: Doors, Ladders, Lifts, Spawners, Keys & Switches, Props, Soundfields, Lights, HUD(Gadget), and Special FX (Particles, Flares, Decals, Dynamic Light Maps) Code Structure (Blitz Type) have been defined and written. Just need to write needed modifier and interactivity functions for Update functions. Guns & Ammo Code pending. (In need of Futuristic weapontry (ie: LaserGun, PulseRifle, and PlasmaCannon) with reload and recoil animation if possible:) I anticipate the implementation of ammo will be similar to particles, however, they will use meshes w/ more polys and have properties for damage effects, etc. |
| ||
Well I have a considerable amount of code for all game objects. In fact I have implemented switches, gadgets, flares, reactors (particles), warps, soundfields, and modules. They work in very basic manner at moment and will be expanded. However, there are a few that need some time. The Ladder object aka Climber. The Ladder object is a 'field' in which the player or bot moves vertically up or down upon collision, dependent on the direction of travel. I'm pondering over the implementation of this game object. My current idea is to simply turn off gravity and jump to the player within the field. The player can move freely up or down, but, once out of the field gravity is turn on. If any one else have implemented Ladders, please sure your thoughts. Platforms aka Lifts are moving game objects that transport player and bots. My current platform design will move horizontally, vertically, and patterns using waypoints. Although most cases these are platforms in which players stand on, they dont have to be. Platforms require dynamic collision detection and gravity is applicable. Dynamic Collision is tricky, but, others have managed it and I'm looking for ideas to do the same. Now some of you may be wondering what are soundfields, warps, and modules. Soundfields are basically pivot points with blitz sphere or cube collision applied. They emit sound upon collision. The idea behind them is to shape 3D sound emissions. Collision can also be used to trigger AI sensors etc. A Warp Object is a cubic field that simulate gravatational forces on players/bots/particles. I have been able to effectively simulate gravity, anti-gravity, wind, and turbulence. You can also use these for vacuum tubes accelerators etc. The Module Object is an object that stores a pool of the entities for recycling. Great for creating and managing LOD mesh sets, particle sprites, etc. This object also serves us great in optimizing the overall game engine. For example, if only 5 bots entity can be seen at once at any given time, why load or copy 20 entities? You dont! You simple recycle 5 bots entity when in view. This methodology can be applied to replicated game objects. Reduce the number of entities copied and loaded, reduce loadtime, memory consumption. |
| ||
Noel BTW I been reading over your Vein engine source. Its very modular indeed. I'm very impressed. Who knows what we could be achieved if you were back on the team. |
| ||
Frank, I have no intentions of assisting this project (directly, I mean, indirect help such as providing code that more than just this project can use is of course going to happen most likely) in the future. If you want to use parts of Vein for any reason, the source code is there for the taking. Have fun, and don't get in over your head. |
| ||
Noel, Have you developed a game with the vein engine? |
| ||
Nope. At least I haven't finished one with it, since it's still in development at the moment. |
| ||
CallBuilder Code Wizard. Builds an ActionCall() Select...Case from a list of Function prototypes. The code wizard is Designed specifically to be used with the Action System. ;The CallBuilder Code Wizard by Frankie 'Techlord' Taylor ;Purpose: Reads and Parses Prototype File, Writes Select Case Tree File. Dim RFileNames$(0),METHODPar$(0),METHODS$(1024) Function TreeBuild(RFileName$,WFileName$,AppendFlg=False,Argument$="this\",DataTypeI$="i%",DataTypeF$="f#",DataTypeS$="s$") Dim RFileNames$(256),METHODPar$(16) RF=ReadFile(RFileName$) DebugLog "Reading RF "+RFileName$+" "+Str$(RF) If RF WF=WriteFile(WFileName$+"call.bb") WriteLine(WF,";"+Upper$(WFileName$+" ACTIONCALL")) WriteLine(WF,"Function "+WFileName$+"Call(this.action)") WriteLine(WF,"If this\method%") WriteLine(WF,"Select this\method%") Repeat Line$=ReadLine(RF) If Left$(Line$,9)="Function " Or Upper$(Left$(Line$,8))="Method " Funct=Funct+1 ArgStart=0 ArgCt=0 For Char = 1 To Len(Line$) Ch$=Mid$(Line$,Char,1) If Ch$="(" Then ArgStart=Char If Ch$="." And ArgStart Then Obj=True ;getObject If Obj Then ObjS$=ObjS$+Ch$ If Ch$="," Or Ch$=")" ArgCt=ArgCt+1 Ch$=Mid$(Line$,Char-1,1) METHODPar$(ArgCt)=DataTypeI$ If Ch$="#" Then METHODPar$(ArgCt)=DataTypeF$ If Ch$="$" Then METHODPar$(ArgCt)=DataTypeS$ ;If Ch$="=" Then If Ch$="(" Then ArgCt=0 If Obj METHODPar$(ArgCt)=Left$(ObjS$,Len(ObjS$)-1) Obj=False ObjS$=Nil$ EndIf EndIf Next Method$=Right$(Left$(Line$,ArgStart-1),Len(Left$(Line$,ArgStart-1))-9) Par$="(" For ArgList = 1 To ArgCt ;If argseq Select METHODPar$(ArgList) Case DataTypeI$ datatypeicount=datatypeicount+1 Par$=Par$+Argument$+METHODPar$(ArgList)+"["+Str$(datatypeicount)+"]" Case DataTypeF$ datatypefcount=datatypefcount+1 Par$=Par$+Argument$+METHODPar$(ArgList)+"["+Str$(datatypefcount)+"]" Case DataTypeS$ datatypescount=datatypescount+1 Par$=Par$+Argument$+METHODPar$(ArgList)+"["+Str$(datatypescount)+"]" Default Par$=Par$+"this"+Right$(METHODPar$(ArgList),Len(METHODPar$(ArgList))-1)+METHODPar$(ArgList) End Select ;Else ; Par$=Par$+Argument$+METHODPar$(ArgList)+"["+Str$(ArgList)+"]" ;EndIf If ArgList<ArgCt Then Par$=Par$+"," Next Par$=Par$+")" WriteLine(WF,"Case "+Str$(Funct)+":"+Method$+Par$) datatypeicount=reset datatypefcount=reset datatypescount=reset EndIf If Left$(Line$,7)="Append " Incl=Incl+1 AppendFlg=True RFileNames$(Incl)=Left$(Right$(Line$,Len(Line$)-9),Len(Right$(Line$,Len(Line$)-9))-1) EndIf If Left$(Line$,6)="Macro " Funct=Funct+1 Macro=True MacroLabel$=Nil$ METHODMacro$=Nil$ For Char = 7 To Len(Line$) Ch$=Mid$(Line$,Char,1) If Ch$="}" Then Exit If Macro Then MacroLabel$=MacroLabel$+Ch$ If Not Macro Then METHODMacro$=METHODMacro$+Ch$ If Ch$="{" Then Macro=False Next WriteLine(WF,"Case "+Str$(Funct)+":"+METHODMacro$+";"+Left$(MacroLabel$,Len(MacroLabel$)-1)+" MACRO") EndIf Until EOF(RF) CloseFile(RF) WriteLine(WF,";+"+Str$(Funct)) WriteLine(WF,"End Select") WriteLine(WF,"EndIf") WriteLine(WF,"End Function") CloseFile(WF) Else CloseFile(RF) EndIf End Function |
| ||
frank i updated red bron, improved the animations again.i will send it on soon as my email starts working |
| ||
Ruz, Sounds good. Look forward to it. Lots of code completed. New demo coming. |
| ||
cool. I did some more work on the hand/weapon, but haven't got THAT far with it yet. Its hard finding the time at the moment. i did this litle update because i need to show some samples to a client. anyway posting it real soon |
| ||
Ruz, I truly thank you for the continuous support. The design of this engine will be one of my greatest programming achievements. The engine's modular design is very robust and will go beyond developing FPS games. Implementing an object-based programming methodology and strict code convention has allowed me to develop TypeWriter][ Code Wizard which generate common initialization, deletion, update, open, and save functions. Code is consistent for all objects. Productivity increased 10 fold due to reduced code writing. My object-based programming methodology is based on Blitz Custom Types. Per Blitz Documentation Custom Types are implemented similar to records in a database. I've adopted the database methodology, devising a flexible Resource Management system using Primary ID keys. The Resource Management System relies on Array of Types, ID field in the Blitz Custom type, and a dedicated FILO Stack. Each type stores a unique index number in the id field. A single element array of types stores a reference to the game object matching the id%. A FILO stack is used to track the ids in use. All game objects can be linked to another by id%. All game entities (meshes, sounds, etc) and game objects(bots, props, powerups, etc) are implemented like particles in which they are recycled as needed. |
| ||
Perhaps you would have more help if you didn't rely on flashy catch phrases no one understands. Especially since their things most everyone has done or uses every day. Not to be too harsh, but perhaps not giving every code structure a flashy name, and rather a brief description will make people think it's worth their time to look into. Rather then something they would rather just code themselves. |
| ||
Perhaps you would have more help if you didn't rely on flashy catch phrases no one understands. Especially since their things most everyone has done or uses every day. ShatteredReality, I dont rely on catchy phrases, but, code. I have produced code and documentation will follow. Taking time to download, view, and understand the code is a choice, just as it is a choice for one to make a contribution. |
| ||
jeez frank lots of harsh criticism here. it would be nice as you say if people took the time to look at stuff before passing judgement,otherwise it just comes off as sounding like sour grapes. |
| ||
Ruz, It is to be expected my friend. Communication is very tough in a project with no solid game design plan. I've constantly ask for input what should go into this engine. I've known at the beginning it would be very difficult to write a game engine without a plan. With a few notions of how the FPS should play and what type of engine we wanted to design, I've pieced together a plan: 1. Define game play objectives: The next step was to define the game engine requirements. This was only step that received any input and it was very brief. "The engine should be modular." This requirement in itself required more detail as many had not written a modular game engine. From my previous experience with other FPS game engines to include: Torque, Quake, Cipher, and others, I was fully aware that game object would have be divided in to small code modules each with a specific purpose. An object-based designed would support a modular design. There were many other engine requirements not mentioned, thus I had to defined them.a. Player should be able transverses Level Map with a FPS Weapon. Player should be able to Walk, Run, Jump, Duck, and Strafe with gravity and collision applied. Player should be able to fire weapons in these positions. Player should be able to climb ladders and ride moving platforms. b. Player should be able to shoot Enemy Bots and destructable props. Player should be able select a variety of weapons each different in appearance. Weapons should vary in ammo. Ammo should vary in shape, flight path, damage effect, and particle effects. c. Player should be able to pick up Powerups and Keys d. Player should be able to unlock doors and trigger switches which activate events and ai. e. Player should have a goal(s) to complete the level and move to next: shoot all bots, find exit, and find item. f. Bots will use finite state machine AI to select an action and pathfinding algos to transverse level. Bots should walk, run, jump with collision applied. Bots should be able to fire weapon in these positions. 2. Game Engine Requirements From the game play objectives and game engine requirements, I had to identify interactive and non-interactive game objects to build modular systems needed to acheive these objectives and requirements. I identified many game objects and subobjects, each with their own purpose.a. Modular Engine Design b. Resource Management System for Optimized memory consuption and performance c. Optimized Rendering using Portals, Level Of Detail, Mininized Surface Count for trees, particles, and ammo. d. Server Client Multiplayer Support with minimized bandwidth requirements. 3. Define game objects and suboobjects. I designed these objects to meet the needs of an a FPS game and beyond. a. Bots - Intelligent game entities that engage the player in combat. b. Props - Non intelligent game entities that the player can interact with. c. Weapons - A game entity held in the FPS Arm, generates ammo. d. Ammo - Ammo game entity that causes damage upon impact to player, bot, props, and level. e. Particles and Flares - For visual effects f. Platforms - For verticle lift Elevators, hortizontal Moving Tiles g. Warps - for influencing gravity, anti-gravity, wind, vacuums, turbulence on player, bots, and particles. The bottomline: you cannot just slap an engine together for it to be modular, expandable, and reusable. It needs planning, continuity, and documentation. This requires standards to be in place. Successful development teams implement standards. I have written tools to assist the effort standardizing and minimize code writing. I can only speak through my actions. Its either put up or shut up. As I stated in the Thread 2," 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." I truly appreciate all the hard work and efforts from those who have and are making contributions. I hope others will take time to download, view, and understand the current code and media and make a choice to contribute. |
| ||
Perhaps you would have more help if you didn't rely on flashy catch phrases no one understands. Especially since their things most everyone has done or uses every day. ShatteredReality, I dont rely on catchy phrases, but, code. I have produced code and documentation will follow. Taking time to download, view, and understand the code is a choice, just as it is a choice for one to make a contribution. I think you are missing the point frank, shattered was trying to tell you that using far too complex terms to describe an engine, that's actualy fairly simple in construction, is not gona help you attract people that will want to work on it. Infact it'll scare quite a few of the kind of people your looking for off! Why talk about database methodology, your system doesn't come close to resembling one? Object oriented methodology, while you could just say using blitz types and functions belonging to them in neat modules. A "primary ID key!", so you've numbered/named your types and put em in an array, big deal. Oh and the best one, a dedicated FILO stack, instead of just saying you keep the unused types in memory and use the next available one, which btw. has nothing to do with stacking and most definately nothing at all with order, since there's no difference in objects that are all of the same state (unused). All in all your cool lines and descriptions might sound realy nice to you, but most of the average blitzers will think it's over their heads, while it's realy nothing hard to work on... The more advanced users will just have a good laugh and wonder how on earth you'd describe a system that's actualy complex. Sorry if this sounds offensive, but try to see it as a piece of advice, you're making a community project as untransparent as you possibly can by using terminology you shouldn't be using for something this trivial. |
| ||
Hopefully this isn't too off-topic, but I noticed you decided to call my 'RedBron' skin 'RedBosser'. It already had a name: 'Pasatone'. Do not change it and do not alter it. In any case, 'RedBosser' is the most retarded name I can imagine... Edit: I mean.. seriously.. that's a hideous name. |
| ||
RetroBooster, Yes, I use a few phrases like 'object-based methodology', FILO Stacks, and Primary Keys. These programming and database concepts have existed for decades and I explain how I implement them in this engine. If one does not understand these terms, they can ask me to elaborate or conduct some do-it-yourself research online. Ultimately, making a contribution is a choice. Noel Cower, I apologize, I was unaware (or didn't pay attention) of the name at the time I posted the screenshot. It has been corrected. |
| ||
I really felt a detailed explanation of my Database methodology was in order. I have used the concept of Primary ID Keys to devise a flexible Resource Management System that may be useful in other projects. My Resource Management System relies on Array of Types, ID field in the Blitz Custom type, and a dedicated FILO Stack. Each type stores a unique index number in the ID field. A single element array of types stores a reference to the game object matching the id%. A FILO stack is used to track the ids in use. All types can be linked to another by id%. Thus, if you need to know "What invader shot that defender and witch vampire bit some ghostships? And why is everything moving in slow motion? Oops; where did those 10.000 guided missiles come from?" you can store a id reference to it. ;Example of missile object Const MISSILE_MAX%=100 ;<-- Predefined maximum number of missiles Global missileIndex.stack=stackIndexCreate(MISSILE_MAX%) ;<-- Dedicated FILO Stack Type missile ;<-- missile Game Object Custom Type Field id%<-- Primary Key Field typeid% <-- Composite Key Field shipid%<-- Foreign Key Field entityid% Field targetid% Field state% Field life% Field damage% End Type Dim missileID.missile(MISSILE_MAX%) ;<-- Array of Types (Reference) Function missileNew.missile() ;<-- initiallizes a new instance of object aka constructor this.missile=New missile this\id%=0 ;<-- Default values (optional) this\typeid%=0 this\shipid%=0 this\entityid%=0 this\targetid%=0 this\state%=0 this\life%=0 this\damage%=0 this\id%=StackPop(missileIndex.stack) ;<-- Pops available ID off FILO Stack missileId(this\id%)=this ;<-- assign Primary Key to object matching array index/object id Return this End Function Function missileDelete(this.missile) missileId(this\id%)=Null StackPush(missileIndex.stack,this\id%) Delete this End Function Function missileCreate.missile(typeid%,shipid%,targetid%,state%,life%,damage%) this.missile=missileNew() this\typeid%=typeid% this\shipid%=shipid% this\entityid%=stackPop(missileEntity.stack[this\typeid]) this\targetid%=targetid% this\state%=state% this\life%=life% this\damage%=damage% End Function Function missileDestroy(this.missile) stackPush(missileEntity.stack[this\typeid],this\entityid%) missileDelete(this) End Function Function missileUpdate() ;<-- update function included in primary game loop For this.missile = Each missile Select this\state% Case 1 ;flight movement and collsion Select this\typeid% ;<-- Case 1 ;guided missileGuide(this) Case 2 ;heatseeker missileHeatSeek(this) Case 3 ;rocket missileMove(this) End Select Case 2 ;impact missileDamage(this) Case 3 ;detonated missileDestroy(this) End Select Next End FunctionI've developed the TypeWriter][ Code Wizard for Project PLASMA FPS 2004 to generate common initialization, deletion, update, open, and save functions from a Custom Type based on my object-based programming methodology. The code produced takes into count the Resource Management System, types within types, and type arrays. Ultimately its all about the design of your game objects. |
| ||
Thank you, Frank. Looks like TypeWriter][ is coming along nicely, by the way. |
| ||
My opinion may not be appreciated, but I'm going to give it anyway in the hopes that it will. Your project looks good, and I considered jumping in, but your project has a learning curve which is (IMO) a bit steep. I have read some of your code, and you have a few very minor issues with consistancy, some (IMO) issues with simplicity in naming, and some definate problems with 'overinforming'. You call things stuff that's not exactly simple/explicit, and give information that isn't neccessary to give. For example; Markerset/Waypoint- I don't know what the differences in your utilization for these terms are. FILO Stack- Saying 'First in, Last out' can't kill you. "If one does not understand these terms, they can ask me..." doesn't work as well as not 'complicating' things to begin with. Yes I know the terms are accurate and expressive- but you know someone working on another part of your lib will possibly never need to care- especially if they've been 'scared off' by the 'apparent complexity' of the engine. The code itself doesn't look that complex- but I spent way too much time trying to figure out how your 'big picture' explanations coincided with the actual code. No one knows (but Mark pretty much) what's inside his routines- they are black boxes that do things, take vals & return vals. Well, not exactly, but you get my point- if you had a routine, then you can keep it simple by saying it sorts an array up or down, 'Sort (Up=TRUE)' or by saying it was a radix sort that took a boolean value to determine ascendancy (or some such) 'RadixSort (Ascend=TRUE)'- bad, exaggerated example, just making a point. One encourages people they will have no problem helping out- the other will likely make some people frown & move on. I would suggest that if it was at all possible, to liken your project routines to be blitz command extensions, and name, code & document accordingly. ie- anything that works on terrains (or meshes which represent terrains) can be named like & be 'made compatable with' the blitz terrain commands. I'm not saying use terrains- just work in a manner that is 'terrain familiar' if possible. I'd like to see an example of what the 'Typewriter Code wizard' does, as I have only a vague idea- ie- I could tell someone else what it's supposed to do, but I don't know how to use it. I could make other suggestions, but I'd really have to understand what you're doing more first- I honestly could be wrong about many things I've pointed out as I haven't sat down & tried to cram it all in. You could assume it's because I'm lazy, an inferior coder, or whatever- and that could be true as well- but if your documentation gets a bit more focused & explains things better, I think you'll find there are more good coders out there. Anyway, good luck to you. |
| ||
Well maybe Frank is just after the Job of Ari Fleischer and he has a good chance to get it :) just kiddin. So, Frank, you want to use unique IDs. But "unique" is french, better say "freeneek IDs". At least until November. However, don't you think that the need of an indexing Array to access Types is complicating the whole thing? Ok, it's just my personal Opinion, but I found a simple but working direct Index of a global Bitz Array much easier. And much faster. I think I used to read that you came back to a generic Object Structure to make it easier to copy objects. Is that right? Well if so then I ask myself what's the reason for not using a number of Arrays instead. People contribute a lot, but, example given, Frank you didn't even link to http://www.stewartsoftware.ca/~plasma/index.php , anywhere in your sig or the head of this thread, although this is a Page that was created dedicated to this Project, isn't this kinda bit of a shame? |
| ||
Biofellis, I have made many efforts to explain exactly what I was doing in the most simplest terms over the past 500+ post associated with this project. It has been very difficult. I will attempt to explain what I'm doing here in the most simple way I can (no promises:)). I will attempt to keep my explanation brief and focused on the engine. So here it goes... Currently, there are 4 parts to the engine: Level Data File, Level Loader, Resource Management, and Main.bb. The engine are the objects created working together. Level Data File - Is a ASCII Comma Delimited Format (*.csv) file that stores all the data needed to load and create Resources: Entity (meshes, sounds, images) and game specific objects (bots, platforms, etc). Level Loader - Parses the Level Data File *.csv loading/creating resources for use within the engine. The level loader can also parse children mesh labels from *.B3D or *.3DS level map geometry to create resources. Resource Management - All resources (entities & game objects) in the engine are designed to be uniquely identified and recycled. Resources are recycled like particles in a typical Particle System. The idea is to load once, use and reuse as needed, and remove upon exiting the engine. This is were things get tricky and the words 'Primary Keys' and 'FILO Stacks' voice themselves. Stacks are used to recycle Resources and IDs (Primary Keys) are used to reference them. Main.bb - The engine design is modular. With each game object and subobject that performs a specific purpose contained in its own module (*.bb file). All the modules are included in the main.bb. All objects provide a 'Start','Update' and 'Stop' Function to be included in the main. The reasons above are why I was able to developed TypeWriter][(download) for Project PLASMA FPS 2004. TypeWriter automatically writes common intialization, deletion, load and save functions for use by the Level Loader, Resource Management and Main.bb. The functions produced are exactly the same for all objects, promoting consistency. END continue at your own risk... Object Based Design The core of my Object-based design is the Blitz Type. Blitz types package multiple properties into one structure. Naming Convention. A verbose Naming Convention is a crucial part of my object-based design. It groups all functions, variables, arrays, subtypes, globals, constants, etc associated with a particular object. Naming Convention: [Object][Purpose](ie: ClockSet) [Object][Property][Purpose](ie: ActionIntSet(myaction,index,255)) [Object][SubObject][Purpose](ie: DatabaseRowNext(db)) [Object][SubObject][Property][Purpose](ie: CameraRumbleXSet(camera,2.0)) |
| ||
jfk, If you click on the PPF2K4 Banner or take a gander at the top post Section Links it takes you to dangerdave's work. |
| ||
"...is a crucial part of my object-based design." YOUR design. That's symptomatic. Let's look back. People come and go. Most times they go.Veni, vidi, vadi. That's the point. Ever tried to find out why? Maybe because they don't believe that you can make something real out of your theories? Well, then show us that they where wrong! I did a fully playable FPS engine in less than 2 weeks, so you could do this too. Show us a fully playable level with all kinds of stuff sometime this year. |
| ||
Ah, ok, then I was wrong with this link issue, sorry about that. |
| ||
My point isn't that the information isn't somewhere within your 500 posts- your explanation is appreciated, and informative- but not the exact point. The engine could be broken into any number of parts, each named after an arbitrary Snow White dwarf, season, or constellation. Though it will help organization to some degree, it likely does not affect the functioning or coding of the engine greatly if at all- especially considering the code dependancies do not respect the implied separation of structure. The level loader could save to binary, csv, or packed factored primes- long as it works I don't care unless I'm coding it. The filetypes supported are important though. Resource management sounds automatic, or easily managable at least. Again, as long as the program doesn't hog all the memory, bog the system, or crash- the architecture it uses internally to accomplish this is functionally irrelevant unless I'm coding it. The nature of this functionality (automatic, integrated into functions?) is again, more important- although if automatic, it is functionally irrelevant except as a (hopefully) transparent feature. Is the main a skeleton for building? does it suport timed events/simulated multithreading? I am assuming 'game objects' are just your abstracted way of saying 'code which uses the engine', though I could be wrong. Again, your explanation of the Typewriter left me without any clue as to what is input into it (blitz code?), and what you set/do before it does it's magic. Further, is this optional, or manditory? The naming convention I can handle- that's pretty straight forward. I'm not trying to be a bug- I'm just saying maybe it's time to take a quick break, review the thread, and integrate others questions/concerns into a new draft of your core ideas- along with some expectations for expansion. For example; I don't know where your routines are (or should be) for a number a functions, or what expectations you'd have if they needed to be coded. These include things from inventory, player status and conflict resolution up to level control, vehicle control and state changes. You've been at this a while, so it's second nature to you now. A fresh pair of eyes may help- print out your stuff & show it to a fellow coder- ask them what they think. If you find you're explaining a lot that they didn't get from your docs, change a few things/add a bit in- otherwise, maybe it's just me. I think though you will find that a few changes will help a bit, but again- just my opinion. |
| ||
Biofellis Establishing a design plan and standards are crucial to the organization of any project. Its implied by many that because this project is Open Source its anything goes. But we cannot go anywhere without a plan from point A to point B. This has been my stance from the very beginning. Due to the lack of input on a game design plan, engine design plan, and standards earlier in the project, I have devised my own game design to move the project forward. The level loader could save to binary, csv, or packed factored primes- long as it works I don't care unless I'm coding it. The filetypes supported are important though. Yes, its true data could be saved to binary, csv, or packed factored primes, etc:). The Level Loader could be designed to read these formats as well, however, I chose csv as a 'standard' for its popularity. Any coder who knows this standard, knows exactly how to get the data into the loader. Resource management sounds automatic, or easily managable at least. Again, as long as the program doesn't hog all the memory, bog the system, or crash- the architecture it uses internally to accomplish this is functionally irrelevant unless I'm coding it. The nature of this functionality (automatic, integrated into functions?) is again, more important- although if automatic, it is functionally irrelevant except as a (hopefully) transparent feature. The Resource Management model is standarized and designed for complete control and speed. The notions of infinite types are eliminated as the maximum number of objects created have to be specified. There are many ways to manage game entities and objects. The model employed here is recognizable and consistant. Is the main a skeleton for building? The main.bb is the main executable. It brings all the objects together. It is the 'engine'. A standard has been established for it as well: "All code modules should be stored in a independent *.bb and provide a Function for Initialization, Game Loop Update, and Termination (Memory Removal) to be used in the Main.bb. These are the only functions allowed in the main.bb." does it suport timed events/simulated multithreading? These features have to be implemented in the object. Each object has its own update function. The main.bb merely cycles through each object's update function in the main game loop. The 'switch' object is designed to manage timed and triggered events within the engine. I am assuming 'game objects' are just your abstracted way of saying 'code which uses the engine', though I could be wrong. 'Game Objects' are objects with specific interactive properties within the game. Examples: Bots, Switches, Platforms, Props, etc. Each game object behaves differently and have their own code module that contains all the needed functions to manage their interactivity. Again, your explanation of the Typewriter left me without any clue as to what is input into it (blitz code?), and what you set/do before it does it's magic. Further, is this optional, or manditory? I have developed TypeWriter][ specifically to meet the design standards I've established.It produces object-based functions that are used by the game engine's level loader and resource management system. Please read the TypeWriter][ Help File or download the code for explanation and demos. I'm not trying to be a bug- I'm just saying maybe it's time to take a quick break, review the thread, and integrate others questions/concerns into a new draft of your core ideas- along with some expectations for expansion. Until recently, there has not been much input on the programming side and the recent input has been in regards to my programming terminology. To be quite honest, I'm too far into the engine to back up or back out. There is now a game design plan, engine design plan, code and media in place. I have put a great deal of time into design process and feel comfortable with my implementation. For example; I don't know where your routines are (or should be) for a number a functions, or what expectations you'd have if they needed to be coded. I apologize for not pointing out the Link in the top post labeled Project PLASMA 2k4 03/01/04 Frank Taylor. It contains the most recent code and media as I update once a week. Unfortunately, there is no documentation at the moment. The source is open and available for expansion and improvement. If you have a improved loader, resource management system, action system, optmized rendering technique, network, etc present them. If you have an idea on game play present them. If you have models, music, sound, and images present them as well. The demo showcases the following game objects or features that have been implemented: Level Loader Switches Warps Reactors(Particle Systems) Flares Props Lights MusicTracks Soundfields Gadgets The todo list includes: Builtin Editor Platforms Weapons Ammo Bot AI Network Console(optional) Ultimately, if one wants to contribute source code, they will have to apply the standards. The standards keep everyone in sync. If the standards need to be improved, then it should be presented and implemented, otherwise, there is no excuse not to use them. Over the past 3 years, I have made several attempts to program a optimized and modular FPS game engine. I have participated in two Open Projects (both failed :( ). These experiences tought me something new. It is this experience that I have brought to this project. So, many will not agree with my standards, my coding style, my terminology, my point-of-view. Its to be expected. However, 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. I rest easy knowing that in some form or fashion I contribute. |
| ||
frank when its done , could it be possible to make a 3rd person type game also. I would like to give that try rather than struggling on writing my own stuff for my demo. I can ssee your problem her frank, you are the one orgnanizing the project and each and evry coder has a different way of doing stuff, so I am afraid you will get a lot of flak until we have something that looks cool and plays well . stick to your guns. |
| ||
Ruz, Thanks for your confidence. Third Person Cam is already implemented my friend. Just simply change the camera object typeid to 3. New demo coming soon! |
| ||
I am a bit confused with pld and csv. if I want to make my own level and save it from jfk's editor as a pld , why can't I load it. I get a blahh.csv not found error.I take it there is no PLD load function yet and only 'csv' is supported.What format is that? |
| ||
Again, your replies are quite enlightening, but I am not asking you to code differently or recode what's done- I'm just talking about your documentation style which I think is prohibative of people joining your project. I think charting out a standard & design plan are very strong showings of a good cohesive design- I'm simply suggesting that the way you present the information for that standard makes it seem a bit prohibitive to be a part of (IMO). I saw the link at the top of your thread, and none of the things I pointed out seems to be implicitly part of any of those libs. I didn't search every lib for them, and my point is I shouldn't have to. So- if they are there somewhere, one should be able to tell without digging- if they are not, my point was (& still is) that a pseudocode shell for the function's performance might not be a bad idea. Anyway, I get the impression you feel I'm attacking your project, which is not the case- I am just expressing my viewpoint on how some minor changes in documentation may encourage others to join in. Again, good luck to you. |
| ||
Biofellis, I do not feel that you are attacking the project at all. In fact a great deal of clarification has come out of this discussion. I will put this into the documentation. There is no documentation for code and its really needed. Documentation is on the to do list and I'm going use RepeatUntil's Cod2Doc to assemble it. Ruz, The current version the engine uses ASCII Comma Delimited Format or Comma Seperated Values(*.csv). I have added many game objects which are not supported by the Pledit. I have been using a spreadsheet which exports to *.csv to manage editing. I modified pledit to export to *.csv. |
| ||
is there an update for pledit for our use also? |
| ||
The updated version of pledit is included in the current zip. However, a PLD loader will have to be written. |
| ||
ok , cheers frank. |
| ||
... |
| ||
Is there a playable demo of plasma? You guys have been working on this for 4 months but I havn't noticed any. Did I miss it? |
| ||
yeah there is a huge playable demo you just were n't good enough to find it |
| ||
huge playable demo I don't think it was huge.. nor playable in the sense of interacting with it. Then again, I haven't seen it in a good while. Cheers. |
| ||
yeah there is a huge playable demo you just were n't good enough to find it Actually, I'm good enough that I spend my time coding and not looking at the Plasma thread. Secondly, if what your refering to as a: huge playable demo means the 7 meg download that has me immediately falling through the floor, then I'm more dissapointed then when I thought there was no demo at all. |
| ||
Shattered. Opps, I'm trying to fix the 'falling thru the floor', its a prob in the player start location. You can teleport to correct location by pressing [2]. What is working: LevelLoader, Reactors, Flares, Warps, and Simple AI. Its work in progress. |
| ||
'Actually, I'm good enough that I spend my time coding and not looking at the Plasma thread' well thats why you missed the demo, silly |
| ||
Frank, make sure when you position your player you turn off collisions by hiding the object. I bid you a farewell. |
| ||
ShatteredReality, Thanks for the tip. I corrected the problem. It was due to turning on collision prior to setting the initial position. Hiding the pivot could have solve this as well. This may be the problem with my bot pathfinding, this is definately noted. I've updated the demo and docs. |
| ||
Cheers. |
| ||
Nurse, defilibrator! |
| ||
LOL The machine thats goes 'ping' has stopped going 'ping' |
| ||
its a bit difficult getting ,motivated to do this right now, since I am so busy with my own project at the moment. I will try and find time to do the hand model though and the gun. the gun is more or less done. I just have to change it from a gun with four textures, to one. |
| ||
Ruz, No problem. Take your time. |
| ||
Frank, can you maybe start Project PLASMA FPS 2004: Thread 5 soon? |
| ||
I'm with skidracer, this thread is a real pain to load. Sort of reduces interest in checking up on the progress of the project for me. |