Assignment Frenzy #1: Detailing

[Ravidge]

Just as you're reading this, time is ticking away. That's right the assignment has already started. We're starting off with something familiar, a detailing task. However, time is limited so you better not waste it by doing something useless like sleeping or eating.

To participate you must create a scene in hammer. The requirement is that it is using a mining theme. Gold, Silver, Copper or Quicksilver, it doesn't matter, the scene does not even have to have an actual mine in it.
Abandoned or thriving, desert or forest, desolate or full of crazy people singing songs about glittering stones.. You choose, but remember to make it look bloody amazing.

Rules:

• 54 hours to complete the task. [Link to countdown clock] [List of local times that correspond to 1:00am UTC]
  
  UTC: 1:00 am (Monday 18th)
  BST/UK: 2:00 am (Monday 18th)
  CEST: 3:00 am (Monday 18th)
  EST: 9:00 pm (Sunday 17th)
  Central: 8:00 pm (Sunday 17th)
  PST: 6:00 pm (Sunday 17th)​
• Scene can not extend beyond 2048x2048, height is unlimited.
  
  Brushes may not stretch outside the boundary. Try to keep all props meshes within the scene space, origins must be inside the scene. Meshes may extend outside boundary in rare cases (within reason). (updated)​
  Brushes purely used for sealing your scene from the void may have their origin outside the 2048x2048. These brushes must be textured in either "tools/toolsskybox" or "tools/toolsnodraw".​
• Publicly released custom content is allowed (released before this post).
• All self-made custom content is allowed.
• No collaborations
• 3D sky is okay. sky_camera entity may not be in a space larger than 512x512x512

Additional Requirements:

• bsp filename should be af1_<forumname>.bsp (no capital letters, no special symbols) example: af1_ravidge.bsp
• At least one info_player_teamspawn

How to submit your work:

1. Compile your map, build your cubemaps, pack custom content and take up to 2 screenshots.
   
   Screenshots should be of the highest quality you can offer. No HUD, no weapon and no watermarking.​
2. Send me (Ravidge) a forum PM with links to your bsp and screenshots. If you feel like it, put "AF #1 submission" in the PM title, would make it much easier for me.

A voting thread will be opened once I've gone through the entries. Rest assured that the voting will also be fast paced.

There you go, It's very simple and familiar. Who will come out on top of the leaderboard after this assignment I wonder, it should probably be you because the challenges aren't going to get any easier!

Site staff can not score points in this assignment, due to unfair advantage.

 

[littleedge]

Brushes may not stretch outside the boundary. Props need to have their origin within the scene.

So skybox brushes must be in the 2048x2048 area?

 

[Locutus]

So skybox brushes must be in the 2048x2048 area?

Well since the height limit is...unlimited...I'd assume you have plenty of space above and below the map to hide your 3d skybox.

 

[zpqrei]

I presume this is meant, where the skybox brushes extend outside the 2048x2048 boundaries.

 

[Tyker]

[Link to countdown clock]

Awesome countdown clock! And thank you for the steam announcement and front page news!

 

[Ravidge]

So skybox brushes must be in the 2048x2048 area?

Sealing brushes don't need to be within the 2048² space, considering you could use cordon to compile.
I'll update the main post to reflect this.

 

[Jetti]

Does it have to be a player-navigatable space?

 

[gamemaster1996]

So, this doesn't have to be very playable just look pretty???

 

[Ravidge]

Does it have to be a player-navigatable space?

You should assume that players may want to spawn and look around at your scene in game.
One spawn point entity is required.

 

[Jetti]

But do they have to be able to feasibly get from place to place (for example, do I have to making working stairs or elevators), or can I just have a chasm drop?

EDIT: Also, do they have to be optimised?

 

[DaBeatzProject]

;________; i only get home tomorrow evenig so this assignment is already a no-go for me... and it's one i really looked forward to hope the next one is just as exciting!!

 

[Locutus]

But do they have to be able to feasibly get from place to place (for example, do I have to making working stairs or elevators), or can I just have a chasm drop?

EDIT: Also, do they have to be optimised?

Well, I'd assume that they don't necessarily need to be able to get from place to place...there's always noclip.

As for optimizing, it doesn't NEED to be playable, just look pretty. So any optimizations you do wouldn't hurt but aren't as necessary.

 

[Ravidge]

But do they have to be able to feasibly get from place to place (for example, do I have to making working stairs or elevators), or can I just have a chasm drop?

EDIT: Also, do they have to be optimised?

I already answered both these questions:

You should assume that players may want to spawn and look around at your scene in game.
One spawn point entity is required.

You don't have to make your map traversable, nor do you have to optimize it.
But keep in mind that if a scene of this size drops a users FPS to ~5, and they cannot move around the scene properly. It's not going to leave a good impression, is it?

There are no official judges for this, so if you want to win you need to appeal to the voters (which are all of you forum members, hopefully all of you).
This is just friendly advice.

 

[Locutus]

But keep in mind that if a scene of this size drops a users FPS to ~5, and they cannot move around the scene properly. It's not going to leave a good impression, is it?

Agh, that makes me a little nervous because I have one of the best GPUs on the market and have no real footing as to how low other peoples' FPS will go. :blushing:

I'll just have to keep it simple, despite it being in a relatively tiny space anyways.

 

[Fruity Snacks]

2048x2048 shouldn't cause issues. if you can make something that size drop ppl's fps to ~5, then you deserve to win something.

 

[grazr]

prop meshes can only extend a couple units beyond the boundary. Are we talking 16, 32, 64 units? Will it be case by case?

Obviously exploiting this for large props is just keniving but i'd like to think people would be pretty reasonable about it and that as long as a props origin resides within the bounds it should be fine for most medium to small props. A couple units limit also seems silly when you're allowing a 3d skybox.

P.S. You can change the scale of the 3d skybox to be greater than 1/16th. I could create a huge skybox in 512x512 by duadroupling the fraction ratio in the sky camera.

 

[Ravidge]

prop meshes can only extend a couple units beyond the boundary. Are we talking 16, 32, 64 units? Will it be case by case?

Obviously exploiting this for large props is just keniving but i'd like to think people would be pretty reasonable about it and that as long as a props origin resides within the bounds it should be fine for most medium to small props. A couple units limit also seems silly when you're allowing a 3d skybox.

P.S. You can change the scale of the 3d skybox to be greater than 1/16th. I could create a huge skybox in 512x512 by duadroupling the fraction ratio in the sky camera.

As long as you''re not trying to obviously bend the rules (ex compiling props with extremely off-center origins or very large props) I'm not going to have an issue with it. For normal props (not made to break rules), consider the "origin within the scene" to be the rule.

You are free to change the scale in the sky_camera. I considered the fact that it was possible, but in the end said nothing about it. I guess I kinda wanted to see someone try it.

 

[grazr]

Yea, though i guess it does stop you using most skybox models (unless you make them even smaller yourself). Anyway, the 512 3dskybox converts to over 8000 standard Hammer Units so i'm not sure that's even necassery.

Thanks for clearing that up.

 

[grazr]

Double post madness.

 

[Bockagon]

Lookin good grazr. I don't think I'll have time to finish mine