SEN StarCraft II August Map Contest!
- Finding solutions to problems -
Just like the first contest, the idea is to help promote map making in general for StarCraft 2. There's a little twist with this one, however. Instead of producing a specific map for a theme or concept, you'll have to find solutions to problems. On top of that,
there isn't any specific deadline! The point is just to solve the problems, and the more you solve, the more points you earn. Granted the contest can't go on forever, therefore whomever collects the most points by the end of August is our winner.
Specifications:- If you are the first one to solve a problem, you earn 2 points.
- Once the first solution has been discovered, any different solution is worth 1 point.
- If the problem mentions a "simulation," the most realistic entry earns 2 points. Other submissions will receive 1 point if they were original enough (to the discretion of the judges).
- One can propose multiple solutions for the same problem and earn points for each of them. Just make sure each solution is different enough from the previous ones.
- The problems will be revealed on August the 1st to ensure no one has the advantage of time over others.
- The contest ends as soon as a valuable solution has been proposed for every problem, or by the time the end of the month comes.
- Rewards will be distributed to winners once judges are done evaluating all the materials.
- You must have a SEN account to submit material.
- Keep in mind the point of this contest is to help out map making in general, so please keep submitting solutions even if the contest has ended!
Judges:- payne
- DevliN
- TBA
Rewards:First Place: $20, 4 Contest Points, and TBD Minerals
Second Place: $10, 3 Contest Points, and TBD Minerals
Third Place: 2 Contest Points, and TBD Minerals
Consolation prizes amounting to 1 Contest Point and/or varying Minerals will be awarded to anyone who has submitted valuable material as well, supposing they don't win.
The 13 Problems!
- Good luck & Have fun -
-> Simulate trees following the sun's movement (rotating).
-> Find a way to by-pass the maximum number of cliff-levels the Galaxy Editor allows us to use.
Basically, I guess if you can reach 5 cliff levels, you can reach any number, so let's just set the number to 5.
-> Create a perfected 'Jump' ability.
Precisions:
- Players must have the control over the height they'll reach through a power bar.
- It must detects collision based on the height of units. This means a Marine jumping over an other marine should not collide with him, though trying to jump through a Thor should make it stop and deal some damage, while making him falling on the ground.
- Players must not be able to control their movement once they've jumped.
- Two units jumping into each other should collide.
-> Make it so projectiles shot by units collides with any positive height variation and explode.
This should include Cliffs as much as Doodads or Terrain Height.
For example, a Stalker should not be able to shoot an other unit situated on the other side of a wall even if it has vision. As it is right now, the projectile would just pass over the wall and hit the unit.
NOTE: Thanks to Centreri for making payne realize he forgot to mention the projectile shouldn't get any z-axis fluctuation, including if the slope variation is negative.
-> Control the flow animation of water and make it affect the movement of units in/on it.
-> Create a map with two moving suns.
We must see two shadows (implicitly linked to each sun) for all elements (units/doodads/terrain).
-> Manipulate a unit so it flips on itself (in-game!).
For example, you could make a Marine doing a back-flip.
Precision: The point of this is to manipulate the z-axis rotation of a unit. We can already make units face a certain point (x,y) point. Now, it is time to try to make it face (x,y,z).
-> Simulate a
dam rupture.
Precision: The main point here is to locally make vary the height of water.
-> Simulate the high and low tide on a lake.
-> Simulate a rainy day which accumulates rain into puddles. This rainy day must be followed by a sunny day.
Implies the use of an evaporation system.
-> A burrowed units moving around must create a slight terrain elevation at its actual position.
The terrain elevation is set back to its initial value as soon as the unit leaves its actual position.
-> Modify units' visions so the players actually only gets to see what is in front of each unit.
Precision: A bit as if the units players were controlling had flashlights.
-> Create the most epic waterfall you can.
Triggers allowed: be imaginative!
This one is just for the artists that wanted to participate!
Currently Working On: My Overwatch addiction.
Relatively ancient and inactive
So... what's the point of contest points? Bragging rights?
None.
Basically yes. They may be renamed to "Achievement Points" since they essentially serve the same purpose.
Currently Working On: My Overwatch addiction.
Probably would join this if it doesn't really take much time from my primary map.
None.
The 13 (>:O) problems will be posted tonight.
Stay tuned and good luck to everyone!
None.
The 13 Problems!
- Good luck & Have fun -
-> Simulate trees following the sun's movement (rotating).
-> Find a way to by-pass the maximum number of cliff-levels the Galaxy Editor allows us to use.
Basically, I guess if you can reach 5 cliff levels, you can reach any number, so let's just set the number to 5.
-> Create a perfected 'Jump' ability.
Precisions:
- Players must have the control over the height they'll reach through a power bar.
- It must detects collision based on the height of units. This means a Marine jumping over an other marine should not collide with him, though trying to jump through a Thor should make it stop and deal some damage, while making him falling on the ground.
- Players must not be able to control their movement once they've jumped.
- Two units jumping into each other should collide.
-> Make it so projectiles shot by units collides with any positive height variation and explode.
This should include Cliffs as much as Doodads or Terrain Height.
For example, a Stalker should not be able to shoot an other unit situated on the other side of a wall even if it has vision. As it is right now, the projectile would just pass over the wall and hit the unit.
EDIT: Thanks to Centreri to make payne realize he forgot to mention the projectile shouldn't get any z-axis fluctuation, including if the slope variation is negative!
-> Control the flow animation of water and make it affect the movement of units in/on it.
-> Create a map with two moving suns.
We must see two shadows (implicitly linked to each sun) for all elements (units/doodads/terrain).
-> Manipulate a unit so it flips on itself (in-game!).
For example, you could make a Marine doing a back-flip.
Precision: The point of this is to manipulate the z-axis rotation of a unit. We can already make units face a certain point (x,y) point. Now, it is time to try to make it face (x,y,z).
-> Simulate a
dam rupture.
Precision: The main point here is to locally make vary the height of water.
-> Simulate the high and low tide on a lake.
-> Simulate a rainy day which accumulates rain into puddles. This rainy day must be followed by a sunny day.
Implies the use of an evaporation system.
-> A burrowed units moving around must create a slight terrain elevation at its actual position.
The terrain elevation is set back to its initial value as soon as the unit leaves its actual position.
-> Modify units' visions so the players actually only gets to see what is in front of each unit.
Precision: A bit as if the units players were controlling had flashlights.
-> Create the most epic waterfall you can.
Triggers allowed: be imaginative!
This one is just for the artists that wanted to participate!
Everything will be updated in the OP as soon as Devlin or an other Admin/GM sees this post. Sorry for the inconvenience.Everything is updated in the OP!
Post has been edited 2 time(s), last time on Aug 1 2010, 4:44 am by payne.
None.
Relatively ancient and inactive
-> Make it so projectiles shot by units collides with any positive height variation and explode.
This should include Cliffs as much as Doodads or Terrain Height.
For example, a Stalker should not be able to shoot an other unit situated on the other side of a wall even if it has vision. As it is right now, the projectile would just pass over the wall and hit the unit.
Lol. Answer to #4: Track the slope of the projectile using the same system I used in Mech Combat (record x, y and z info at two points and constantly recalculate) and if the slope ever goes above a certain number, make it explode.
In fact, Mech Combat DOES have that. You can't shoot up a cliff. Which fulfills the requirement. Your question is a poor one, because, as one would see by trying my system out, the projectile would face a myriad of other problems, such as going DOWN being unrealistic (due to the pathing following the ground). And tree-collision. And a whole ton of other stuff. Really, tracking z and making it work flawlessly with fluctuating-z terrain is hell. I didn't figure it out.
Lol, owned.
None.
Really, tracking z and making it work flawlessly with fluctuating-z terrain is hell. I didn't figure it out.
That's what the problem is about. ;o
... just forgot to mention they shouldn't follow the terrain when it has negative slope.
Devlin, please fix?
None.
Relatively ancient and inactive
I ANSWERED THE QUESTION. You can't modify the damn question after I answered it. It had a very specific request, which I answered. I could work on it a bit more and maybe give the full version (for extra credit), but I definitely expect my two points (and extra if a simulation gives extra:
http://www.staredit.net/topic/10916/ ). : /
Also, 11 is vague. The way you worded it, it sounds like the following would suffice as an answer:
Provide terrain with varying elevation; random. Put water over it, but below the terrain.
Set weather to rainy, increase height of water by three over five minutes.
Set weather to sunny, reduce height of water by three over five minutes.
Post has been edited 1 time(s), last time on Aug 1 2010, 4:42 am by Centreri.
None.
I ANSWERED THE QUESTION. You can't modify the damn question after I answered it. It had a very specific request, which I answered. I could work on it a bit more and maybe give the full version (for extra credit), but I definitely expect my two points (and extra if a simulation gives extra:
http://www.staredit.net/topic/10916/). : /
No u.
I am the host the contest, I am God, I do what I want. >:D
The problem was meant to not let projectiles go down either. ;o
None.
The Problem #4 got changed due to a little flaw. Take note of the 'EDIT' please.
Sorry for any inconvenience.
-> Make it so projectiles shot by units collides with any positive height variation and explode.
This should include Cliffs as much as Doodads or Terrain Height.
For example, a Stalker should not be able to shoot an other unit situated on the other side of a wall even if it has vision. As it is right now, the projectile would just pass over the wall and hit the unit.
EDIT: Thanks to Centreri to make payne realize he forgot to mention the projectile shouldn't get any z-axis fluctuation, including if the slope variation is negative!
None.
Relatively ancient and inactive
Yeah. Because that's going to assuage me, adding a 'thanks' at the bottom.
None.
Also, 11 is vague. The way you worded it, it sounds like the following would suffice as an answer:
Provide terrain with varying elevation; random. Put water over it, but below the terrain.
Set weather to rainy, increase height of water by three over five minutes.
Set weather to sunny, reduce height of water by three over five minutes.
I did not think it was that easy to realize. Anyways, if it is that simple, well, as mentioned in the rules, if the problems mentions a "simulation", the best result of all will earn the points.
For example, you could try to detect where a rain drop hits the terrain and create a rain-drop unit there and make it follow the biggest negative slope from its point. ;o
Yeah. Because that's going to assuadde me, adding a 'thanks' at the bottom.
Yep.
None.
Relatively ancient and inactive
... Except that that's retarded, because it would put too great a strain on a computer. Constant recalculations on my projectiles slowed down the game (they were, admittedly, inefficient, but still). RAINDROP-PHYSICS? IN THE SCII ENGINE? REALLY?
Lol, I got points for 11 too.
None.
Relatively ancient and inactive
For the burrowed-unit terrain deformation one:
Do
this every .2 seconds for every unit that is burrowed and moving. Remove the old deformation actor before adding the new one.
I'm more confident about that way. An alternate way that might work but I don't know anything about actors so it might not: Attach the deformation actor to a unit if its burrowed.
What do you mean by 'simulate high/low tide'? Would 'set water height to 3 over five minutes'/'set water height to 2 over five minutes' fit?
None.
For the burrowed-unit terrain deformation one:
Do
this every .2 seconds for every unit that is burrowed and moving. Remove the old deformation actor before adding the new one.
I'm more confident about that way. An alternate way that might work but I don't know anything about actors so it might not: Attach the deformation actor to a unit if its burrowed.
What do you mean by 'simulate high/low tide'? Would 'set water height to 3 over five minutes'/'set water height to 2 over five minutes' fit?
First of all, describing how people should realize a problem isn't considered as a "valuable material".
You must actually apply your concept in a map and post it.
A complete wiki article about how to achieve a solution is also considered as a 'valuable' material, though it has to be in-depth.
Wikis and/or posting a map in the DLDB might also get you some extra-minerals due to "contribution to the community".
Secondly, learn what's a tide: one side of the river is higher than the other, due to the attraction of the moon.
In the facts, the main point of the problem is to make the water's height vary on a certain slope equation (varying in the time, in the case of the simulation).
None.
Relatively ancient and inactive
Then I'll just tell people how to do it and they'll do it. I don't even have an editor. The knowledge that I kicked the contest's ass is enough for me. WONT BE MANIPULATING ME WITH ACHIEVEMENT POINTS. Also, Payne, stfu
.
You can't make water height vary on a slope equation. The closest thing one can do to simulate that is to grab several different waters, lay them all out in some weird pattern, make their stats the same so they look identical, and then edit their heights so that the height of the water steadily increases from one end to the other - but unless the difference is tiny that'll look ugly.
The editor is
limited. That one can conceive doing something doesn't make it doable. And it definitely doesn't make it doable by SENners.
Answer to the vision-in-one-direction: Assuming there's no easy answer, the best way to do this would be to set the unit vision radius to zero, create invisible, no-collision unkillable dummy units with a small sight range and constantly arrange and rearrange them using triggers. They'll be at an offset from the unit in the direction the unit is facing - a simple configuration that could work is unit-1-2-3, where each number represents the number of dummies perpendicular to the direction the unit is facing there. Naturally, the more of these dummy units you add, the less circular and the more convincing it'll be.
Diagram, where UNIT is unit and X is dummy sight-range unit:
X
X
UNIT X X
X
X
Positioning can be done fairly easy using point-manipulation triggers such as "at angle offset". Several ways to do it, really. And, I don't know about this, but it might be more efficient to set their movement speed to something absurdly high and order them around instead of killing/creating. Sillier method: Arrange/rearrange sight blockers. That could actually be easier... Not sure, but you might only need to arrange three and have it perfect (block sides and back). But that'll also mess with other player's vision. Still, if it's possible to modify sight blockers so they only effect certain players, this could be a nice way to do it.
Post has been edited 7 time(s), last time on Aug 1 2010, 6:47 pm by Centreri.
None.
I am aware we cannot have water heaight vary on a slope equation directly using the Terrain layer, but there are some alternatives I came up with, though I never got to try to apply them.
Also, the use of Third Party program or really anything is allowed, as long as you can host the map on B.net and make it work on Multiplayer without requiring players to download anything but the map.
None.
Relatively ancient and inactive
I like where this is going.
None.
I like where this is going.
There's still 30 days to the contest... Keep faith!
None.
