Article description:
A trick for improving player movement through your single or multiplayer level. Touches on the proper use of prop_physics, player clips, and layout techniques.
1
Re: [article] Gameplay Optimization
Posted by Riven on Thu Dec 31st at 11:33am 2009
Riven
super admin
1639 posts
802 snarkmarks
Registered: May 2nd 2005
Location: Austin, Texas, USA
Occupation: Architect
Posted by Riven on Thu Dec 31st at 11:33am 2009
This is a discussion topic for the article "Gameplay Optimization" by Riven which can be found here
Article description:
A trick for improving player movement through your single or multiplayer level. Touches on the proper use of prop_physics, player clips, and layout techniques.
Article description:
A trick for improving player movement through your single or multiplayer level. Touches on the proper use of prop_physics, player clips, and layout techniques.
Riven
super admin
1639 posts
802 snarkmarks
Registered: May 2nd 2005
Location: Austin, Texas, USA
Occupation: Architect
Re: [article] Gameplay Optimization
Posted by G4MER on Thu Dec 31st at 2:59pm 2009
Posted by G4MER on Thu Dec 31st at 2:59pm 2009
Great Tutorial Riven. I learned a few new things from it. I cant do the player clip tut now.. but that is ok, I think you did a much better job of explaining than I ever could. 
I like how you laid the tut out as well on several pages. Made the content easy to follow and read.
I like how you laid the tut out as well on several pages. Made the content easy to follow and read.
Re: [article] Gameplay Optimization
Posted by Gwil on Fri Jan 1st at 2:12pm 2010
Gwil
super admin
2864 posts
293 snarkmarks
Registered: Oct 13th 2001
Location: Derbyshire, UK
Occupation: Student
Posted by Gwil on Fri Jan 1st at 2:12pm 2010
Great tutorial Riven - picks up on a finer nuance of gameplay that people might otherwise miss when finishing up a map.
Gwil
super admin
2864 posts
293 snarkmarks
Registered: Oct 13th 2001
Location: Derbyshire, UK
Occupation: Student
Re: [article] Gameplay Optimization
Posted by G4MER on Fri Jan 1st at 2:40pm 2010
Posted by G4MER on Fri Jan 1st at 2:40pm 2010
Hey Gwil.. good to see you.
Hey Riven, did you do that tut on site or off and then just transfer it.. I want to do that adding player spawns without decompile tut... and want it to look as nice and professional as yours. We may also need to add the program in the tools here to be downloaded. Help.. =)
Hey Riven, did you do that tut on site or off and then just transfer it.. I want to do that adding player spawns without decompile tut... and want it to look as nice and professional as yours. We may also need to add the program in the tools here to be downloaded. Help.. =)
Re: [article] Gameplay Optimization
Posted by Riven on Fri Jan 1st at 4:43pm 2010
Riven
super admin
1639 posts
802 snarkmarks
Registered: May 2nd 2005
Location: Austin, Texas, USA
Occupation: Architect
Posted by Riven on Fri Jan 1st at 4:43pm 2010
This tutorial was done completely On-Site. I've thought about re-creating other tutorials from other sites and adding them to the SnarkPit, but I would want to do it under the account The SnarkPit because it's not an original tutorial. And I don't have access to that account anyway. But before bothering with that, sometimes I think about all the clean-up that needs to be done with the articles and downloads we already have. A lot of them are missing images, the HTML for other articles clutters everything up, and the games for the maps section still need banner images and descriptions (check the L4D2 banner and look for the info button to see what they could all have). It's a great feature larchy implemented, that I'd like to get around to filling-in.
Beyond that, It was not too difficult to write the tutorial on-site; It's like any other post with BBcode enabled. Although without the admin abilities, I couldn't find a way to preview my article before submitting it, I might had just missed it. But the way it works is, when you're done typing your new article, and you click 'submit,' It gets sent to the admin approval page where an admin has the opportunity to check the article's thoroughness and content and basically preview it before it get's posted on the main site for everyone to see. If it's approved, it goes on with any changes the admin might had made; if it get's denied, a few notes could be written about it, but then it is sent back to the author for revisions and re-submittal. Now, remember, there is no way for the author to preview his work before it get's submitted to the main site, and even when it does get approved, there is no way to edit it (as the author) after it's been posted. The admin check/revision period can go on for as long as the admin deems necessary.
So, It's a nice system that works, but I'll propose a few suggestions in the feedback thread having now had first-hand experience with it.
If it weren't for my admin abilities, it would have take a bit longer to get this posted in the condition that it is.
Beyond that, It was not too difficult to write the tutorial on-site; It's like any other post with BBcode enabled. Although without the admin abilities, I couldn't find a way to preview my article before submitting it, I might had just missed it. But the way it works is, when you're done typing your new article, and you click 'submit,' It gets sent to the admin approval page where an admin has the opportunity to check the article's thoroughness and content and basically preview it before it get's posted on the main site for everyone to see. If it's approved, it goes on with any changes the admin might had made; if it get's denied, a few notes could be written about it, but then it is sent back to the author for revisions and re-submittal. Now, remember, there is no way for the author to preview his work before it get's submitted to the main site, and even when it does get approved, there is no way to edit it (as the author) after it's been posted. The admin check/revision period can go on for as long as the admin deems necessary.
So, It's a nice system that works, but I'll propose a few suggestions in the feedback thread having now had first-hand experience with it.
If it weren't for my admin abilities, it would have take a bit longer to get this posted in the condition that it is.
Riven
super admin
1639 posts
802 snarkmarks
Registered: May 2nd 2005
Location: Austin, Texas, USA
Occupation: Architect
Re: [article] Gameplay Optimization
Posted by G4MER on Fri Jan 1st at 5:01pm 2010
Posted by G4MER on Fri Jan 1st at 5:01pm 2010
Then, I may have to write it up and send it to you.. because I don't have your admin abilities to make it easier and quicker. =) Thanks for the info.
Maybe we can get a preview option added later on. Would also be nice to update the old tuts on here.
Maybe we can get a preview option added later on. Would also be nice to update the old tuts on here.
Re: [article] Gameplay Optimization
Posted by larchy on Fri Jan 1st at 6:08pm 2010
larchy
super admin
496 posts
87 snarkmarks
Registered: Jan 14th 2008
Location: UK
Occupation: kitten fluffer
Posted by larchy on Fri Jan 1st at 6:08pm 2010
There are some issues with the way articles work that means adding previews was quite troublesome if I did it the same way as forum posts.... however I think I've thought of quite a good way around it that I'll try and add over the weekend.
larchy
super admin
496 posts
87 snarkmarks
Registered: Jan 14th 2008
Location: UK
Occupation: kitten fluffer
Re: [article] Gameplay Optimization
Posted by Le Chief on Sat Jan 2nd at 12:52am 2010
Posted by Le Chief on Sat Jan 2nd at 12:52am 2010
Pretty good tutorial man although the title is a bit confusing for me, I'm not really sure what "gameplay optimization" entails and it seems in the tutorial you were discussing good multiplayer level design from a gameplay and performance standpoint.
Also I couldn't understand what you were trying to say in the open z-axis section.
Also I couldn't understand what you were trying to say in the open z-axis section.
Re: [article] Gameplay Optimization
Posted by larchy on Sat Jan 2nd at 12:35pm 2010
larchy
super admin
496 posts
87 snarkmarks
Registered: Jan 14th 2008
Location: UK
Occupation: kitten fluffer
Posted by larchy on Sat Jan 2nd at 12:35pm 2010
I've added a preview system to the new article page. It's a bit different to the forum system because the parsing for articles is pretty complicated... there are a few issues and I've spent about 4 hours coding something that hopefully works ok.
It won't show images (because they don't get uploaded until the form is submitted, and there's no AJAX system in place for this bit), but will show placeholders for image tags.
Pagination is also... problematic.... so everything gets shown on one page. You can still see the article index and where each page starts/ends ok though.
I could get round the problems by temporarily shunting everything into the db, but that's not really ideal and brings it's own issues.
Anyway have a look and see if what's there is ok.
If your button is green, refresh your stylesheet.
It won't show images (because they don't get uploaded until the form is submitted, and there's no AJAX system in place for this bit), but will show placeholders for image tags.
Pagination is also... problematic.... so everything gets shown on one page. You can still see the article index and where each page starts/ends ok though.
I could get round the problems by temporarily shunting everything into the db, but that's not really ideal and brings it's own issues.
Anyway have a look and see if what's there is ok.
If your button is green, refresh your stylesheet.
larchy
super admin
496 posts
87 snarkmarks
Registered: Jan 14th 2008
Location: UK
Occupation: kitten fluffer
Re: [article] Gameplay Optimization
Posted by haymaker on Sun Jan 3rd at 4:12am 2010
Posted by haymaker on Sun Jan 3rd at 4:12am 2010
Nice piece of homework here, very well done. A lot better than I could pull off so quickly 
The main niggles I have with it is your approach to prop_phys and prop_mp, section 2, in saying large props should be _phys and small should be _multi... Technically this system will work as you have stated, but I would like to point out further refinement.
I have found in my many hours with hl2dm, at least, that props must serve a definite purpose or they are just wasting resources.
Sure, it is possible to build a kitchen with throwable pots and cans etc, but that is terrible gameplay. If an author really feels he must illustrate such a place, I would urge that anything under 32units be prop_static and non-solid. There's plenty of instances where players just get stuck on stupid junk, and it's an avoidable frustration. I frakkin HATE those keyboards and buckets and stuff in the Valve maps. By converting to _static you can place proper clips to allow smooth movement and also fade these things out quickly ( if they are placed in cubbies etc ) to allow the server to attempt better hit registration, which is widely known to suck in Source.
Also looking for simpler, more rectangular models for real physics interaction will result in better server performance, which will result in better gameplay. Along these lines it's also advisable to consider placing what you think is a good amount of physics props, and then taking a few out; too many of these things and you have a boring map.
I don't think the article touched on _respawnable either, but it's worth noting that these can cause bad server performance if they are carelessly integrated, especially the explosive ones.
The main niggles I have with it is your approach to prop_phys and prop_mp, section 2, in saying large props should be _phys and small should be _multi... Technically this system will work as you have stated, but I would like to point out further refinement.
I have found in my many hours with hl2dm, at least, that props must serve a definite purpose or they are just wasting resources.
Sure, it is possible to build a kitchen with throwable pots and cans etc, but that is terrible gameplay. If an author really feels he must illustrate such a place, I would urge that anything under 32units be prop_static and non-solid. There's plenty of instances where players just get stuck on stupid junk, and it's an avoidable frustration. I frakkin HATE those keyboards and buckets and stuff in the Valve maps. By converting to _static you can place proper clips to allow smooth movement and also fade these things out quickly ( if they are placed in cubbies etc ) to allow the server to attempt better hit registration, which is widely known to suck in Source.
Also looking for simpler, more rectangular models for real physics interaction will result in better server performance, which will result in better gameplay. Along these lines it's also advisable to consider placing what you think is a good amount of physics props, and then taking a few out; too many of these things and you have a boring map.
I don't think the article touched on _respawnable either, but it's worth noting that these can cause bad server performance if they are carelessly integrated, especially the explosive ones.
Re: [article] Gameplay Optimization
Posted by Riven on Sun Jan 3rd at 7:59am 2010
Heh, re-reading it with an outsider's perspective now, I can see the confusion. I seem to start off strong and then quickly disintegrate without even properly wrapping-up that particular section. I'll edit it to be sure and make it a bit more clear and perhaps add some more info. -Thanks for pointing that out!
Duly noted haymaker. I feel there should be some clarification also on some of the spawn flags that are common for both phys_ entities. Just because it's phys_mp doesn't mean the player can't pick it up; there are other settings to be checked for THAT to happen. However, what you stated about turning them into static props in fact can't be done for most of those keyboard, bucket, etc... models unless you could recompile them with their QC files. So, if say you turned off their collision with the player, and turned off their ability to be picked up, the only calculation the server would be performing on them would be anytime they hit another prop_phys(_mp). Otherwise, the server turns off their collision hull until they actually do come in contact with something that is allowed to hit them (via the flags). You can see this very clearly if "mat_fullbright 1" is turned on in a map. But yes, you are right for pointing that out, and I'll be sure to edit that info into the article. Thanks for pointing that out!
The fade property may be out of the scope for this article, but I could mention it nonetheless.
About the respawnable props: I honestly don't have much knowledge on the effects of _respawnable props, but it is probably worth mentioning; I'll do some more homework
Thanks again for the feedback guys.
Riven
super admin
1639 posts
802 snarkmarks
Registered: May 2nd 2005
Location: Austin, Texas, USA
Occupation: Architect
Posted by Riven on Sun Jan 3rd at 7:59am 2010
Quoting aaron_da_killa
Also I couldn't understand what you were trying to say in the open z-axis section.
Heh, re-reading it with an outsider's perspective now, I can see the confusion. I seem to start off strong and then quickly disintegrate without even properly wrapping-up that particular section. I'll edit it to be sure and make it a bit more clear and perhaps add some more info. -Thanks for pointing that out!
Quoting haymaker
Sure, it is possible to build a kitchen with throwable pots and cans etc, but that is terrible gameplay. If an author really feels he must illustrate such a place, I would urge that anything under 32units be prop_static and non-solid. There's plenty of instances where players just get stuck on stupid junk, and it's an avoidable frustration. I frakkin HATE those keyboards and buckets and stuff in the Valve maps. By converting to _static you can place proper clips to allow smooth movement and also fade these things out quickly ( if they are placed in cubbies etc ) to allow the server to attempt better hit registration, which is widely known to suck in Source.
Duly noted haymaker. I feel there should be some clarification also on some of the spawn flags that are common for both phys_ entities. Just because it's phys_mp doesn't mean the player can't pick it up; there are other settings to be checked for THAT to happen. However, what you stated about turning them into static props in fact can't be done for most of those keyboard, bucket, etc... models unless you could recompile them with their QC files. So, if say you turned off their collision with the player, and turned off their ability to be picked up, the only calculation the server would be performing on them would be anytime they hit another prop_phys(_mp). Otherwise, the server turns off their collision hull until they actually do come in contact with something that is allowed to hit them (via the flags). You can see this very clearly if "mat_fullbright 1" is turned on in a map. But yes, you are right for pointing that out, and I'll be sure to edit that info into the article. Thanks for pointing that out!
The fade property may be out of the scope for this article, but I could mention it nonetheless.
About the respawnable props: I honestly don't have much knowledge on the effects of _respawnable props, but it is probably worth mentioning; I'll do some more homework
Thanks again for the feedback guys.
Riven
super admin
1639 posts
802 snarkmarks
Registered: May 2nd 2005
Location: Austin, Texas, USA
Occupation: Architect
Re: [article] Gameplay Optimization
Posted by Riven on Mon Jan 18th at 9:44am 2010
I finally took the opportunity now that the new article system is up and running to make edits to the article.
I added a whole new paragraph to the 'prop_physics' section, and I completely re-did the 'open Z-axis' part under the 'layouts techniques' page so that it should make more sense and have much more meaning.
I took into account you guys' suggestions so be sure to look for the updated info!
Riven
super admin
1639 posts
802 snarkmarks
Registered: May 2nd 2005
Location: Austin, Texas, USA
Occupation: Architect
Posted by Riven on Mon Jan 18th at 9:44am 2010
----Article Has Been Updated----
I finally took the opportunity now that the new article system is up and running to make edits to the article.
I added a whole new paragraph to the 'prop_physics' section, and I completely re-did the 'open Z-axis' part under the 'layouts techniques' page so that it should make more sense and have much more meaning.
I took into account you guys' suggestions so be sure to look for the updated info!
Riven
super admin
1639 posts
802 snarkmarks
Registered: May 2nd 2005
Location: Austin, Texas, USA
Occupation: Architect
Re: [article] Gameplay Optimization
Posted by Le Chief on Tue Jan 19th at 11:59am 2010
Posted by Le Chief on Tue Jan 19th at 11:59am 2010
I get what you're saying for the z-axis section. You're talking about height variation in terms of gameplay not aesthetics.
1
© Snarkpit.net 2001 - 2023, about us, donate, contact
Snarkpit v6.1.0 created this page in 0.0122 seconds.
Snarkpit v6.1.0 created this page in 0.0122 seconds.