SWEET Dynamic Infestation omg something most of all games should take advantage off. Love the night vision thing really helps the aliens out when the power goes down in the sector or if the room is dark one thing the aliens should have the advantage of is in low lighting. Glade there is an alien who helps the commander out more now. Did I mention Dynamic Infestation is cool cause it really is I find it being a big plus.
<!--quoteo(post=1833430:date=Feb 19 2011, 08:50 AM:name=echs)--><div class='quotetop'>QUOTE (echs @ Feb 19 2011, 08:50 AM) <a href="index.php?act=findpost&pid=1833430"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Amazing patch. But I think the Whip should pull and slide itself across the terrain, seeing it walk looks very weird. :)<!--QuoteEnd--></div><!--QuoteEEnd--> I thought it looks kinda cute. Reminds me of the worms from Worms 2/Armageddon/World Party.
All Maps have GroundWaypoints, It would not surprise me if these where used in the mechanics of the DI growth as main paths to follow that lead to another hive or res node. There is a lot of code to be written before its Max's turn to do the Dynamic Mesh version.
<b>Just some random notes here addressing comments I have read all over the place.</b>
<b>Time Management, Keeping Everyone busy...</b> The team has to save as much time as possible, This means for example that Max sometimes does have to stop working on performance for a day or 2 now and then to add new technology to make sure the rest of the team has something new to constantly work on and not be left hanging in the air... or to make sure that they don't waste time working on an idea in a specific way when he has a much better method for them to use with much better results and visual appeal, he needs to get it in ASAP so the rest of the team can work with that and save the team a lot of time from having to re-do it again in a new way later, Time is money..
<b>Get the basics working....</b> Max only spends a very short time adding something new, that means it is going to be very quick and dirty code that he will have to add to the <u>end</u> of his "to optimize" list. So you are bound to see a performance drop somewhere when something fresh out of the box is added. After all you are not playing around on finished product.. hence why your purchase is a Pre-order.
<b>Optimize later when the concept is proven..</b> Anything new you see added in a week needs another few weeks/months worth of coding for it to work 100% as it is in draft form and it will remain in this draft from until the list of features/mechanics is done, When this list is done the game goes into the next phase of development where the fine tweaking and lot's more optimisation happens. This normally starts happening when the game is getting close to Candidate Release and this is when things like Skulk Leap, Lerk flight, settings, options, interfaces get a big touch up, Commenting on these things now wont get anything done now and your comments will probably get lost by the time the team is ready to take specific feedback on those.
<b>The right time to look at things...</b> I have noticed that the team does try to change little things now and then from the early feedback but some feedback is too early. So that progress is felt by everyone and it is important that progress is made because it affects moral, doing some quick easy tweaks or fixing an easy bug in the middle of a large daunting lengthy task <i>(something that is going to take few days/weeks constant work)</i> helps as a programmer maintain that sense of progress and boost their moral so they can continue to tackle the big task at hand and not fall into a depression pool of "I am getting no where, I have been working on this exact same thing for days now I need a break, I feel depressed now". ~Programming does this to you..
<i>"I feel like i am being ignored"</i> because nothing is done based on your feedback, the reason for this is because right now the team can only handle working on getting the game mechanics in and fixing the bugs and there are over a 1000 active reports, they are a rather tiny team compared to a other studios that have 50 to 260 workers, some projects have more! The basic functions of these mechanics and the way they handle will be addressed at the right time. Right now the people who are getting the most praise is those helping to debug the code, even submitting actual bug fixes and performance improvements, That's where the focus is right now so please hang on to your tweak based opinions they will get to you soon! :)
Thanks for that SgtBarlow, it puts some of my concerns at ease. I think that maybe you should get some moderators or playtesters to make lists of requested features or fixes, and categorise them, so that when the time comes, you can all get cracking on them. It also helps people to see what has already been suggested / what bugs have already been confirmed. The HoN forums does something interesting with bug reports and suggestions, and it really helps to categorise them well. I'll take some screenshots. It's very well organised. <img src="http://tinypic.cc/files/h/hon186617.jpg" border="0" class="linked-image" /> . <img src="http://tinypic.cc/files/h/hon281718.jpg" border="0" class="linked-image" /> . <img src="http://tinypic.cc/files/h/hon357336.jpg" border="0" class="linked-image" /> . <img src="http://tinypic.cc/files/h/hon410301.jpg" border="0" class="linked-image" /> . <img src="http://tinypic.cc/files/h/hon587428.jpg" border="0" class="linked-image" />
Obviously you don't need to go into nearly as much detail as this, at least prior to the game being released, but some of these categorisations could work really well. Just have a group of respectable volunteers to categorise them, so whenever the team is keen, they'll have a good starting point for all the tweak-based suggestions and such.
Major MopJoin Date: 2011-02-22Member: 83046Members
Oh man, this is the patch ive been waiting for. the big DI patch.....looking awsome already, adding so much more to the RTS aspect of the game, god keep it up UW crew, youve got a goty on your hands
Mmm... on the very first Dynamic Infestation teaser video the DI was 3d, it had form, depth... if you know what I mean.
I'm a little confused as to whats in game. It's more a transparent picture of DI that's just stretched on top of the floor? My graphics are on the highest setting.
This is a prototype of DI gameplay, so the devs are using the new Decal system for a placeholder graphic. When performance is considered stable, Max will work on making DI generate like it did in the teaser, and perhaps even better looking.
When you code an interactive feature, most of them come in 3's, 3 sets of code or stages however you want to look at it. This is the way I look at it:
<ol type='1'><li>Game play Mechanics</li><li>Rendering</li><li>Interaction/Control</li></ol>
Each one of these requires a lot of code to get working, so each is treated as a separate task but the 3 technologies most be coded to work with each other.
When creating your idea this is what you need to do in this order to save you the most time: <ol type='1'><!--coloro:#FFA500--><span style="color:#FFA500"><!--/coloro--></li><li>Find and research a <u>render method</u> and test it's function & visual appeal.</li><li>Code & test <u>game play mechanics</u> <!--coloro:#C0C0C0--><span style="color:#C0C0C0"><!--/coloro-->(Decide at this point to scrap or commit).<!--colorc--></span><!--/colorc--></li><li>Integrate <u>Render method</u> with <u>game play mechanic</u> & create <u>Interactions &/ Controllers</u><!--colorc--></span><!--/colorc--></li></ol>
<!--coloro:#C0C0C0--><span style="color:#C0C0C0"><!--/coloro-->The first DI test you saw was a prototype of a rendering method (2). So the other 2 stages are unrelated to it and in them selves a whole feat of coding. In the DI Render test video had a very quick and dirty Control (3) written in order to provide a way to spread it so they could test it, aka an invisible "DI Gun" to grow it wherever you fired it at a wall. So this DI Gun is one thing, the mechanics to automatically control it according to the status of the Game play/Environment/Interactions is a totally different ball game altogether (3).
DI in the current release is a test of (1) Game play Mechanics. Getting in & testing areas of effect and methods of spread. Of course how on earth are you going to see what's going on without a visual representation of the data? So because Decals is in the pipeline the clever, <u>fast</u> solution was to write a very simple & quick utilization of decals for the game play testing. Once all environmental/structural/player interaction has been clarified, tested, balanced & finalized then is time to spend the long haul of getting the <b>3D DI</b> render method hooked up and the code based ways of handling its <u>complicated</u> way on how to spread through a level on its own can be worked on versus the incredibly easy task in comparison to the DI Gun in the Render tech video used to spread it.<!--colorc--></span><!--/colorc-->
You are bound to so this happen with pretty much anything being written into the game while it's in the Beta stage, you should expect to see some very ugly things appear for a while before they have more time spent on them <i><!--coloro:#00BFFF--><span style="color:#00BFFF"><!--/coloro-->(you need to prove it works on a number of levels before you commit more time to its visual appeal just in case you scrap it or replace it with something else)<!--colorc--></span><!--/colorc--></i> , Exact same applies to the Alien Dark Vision, This is a render method researched and tested by applying the basics to an F key toggle. Once proven it can slowly evolve into more advanced FX and be used in other applications such as Sweep scan.
Comments
I thought it looks kinda cute. Reminds me of the worms from Worms 2/Armageddon/World Party.
<b>Just some random notes here addressing comments I have read all over the place.</b>
<b>Time Management, Keeping Everyone busy...</b>
The team has to save as much time as possible, This means for example that Max sometimes does have to stop working on performance for a day or 2 now and then to add new technology to make sure the rest of the team has something new to constantly work on and not be left hanging in the air... or to make sure that they don't waste time working on an idea in a specific way when he has a much better method for them to use with much better results and visual appeal, he needs to get it in ASAP so the rest of the team can work with that and save the team a lot of time from having to re-do it again in a new way later, Time is money..
<b>Get the basics working....</b>
Max only spends a very short time adding something new, that means it is going to be very quick and dirty code that he will have to add to the <u>end</u> of his "to optimize" list. So you are bound to see a performance drop somewhere when something fresh out of the box is added. After all you are not playing around on finished product.. hence why your purchase is a Pre-order.
<b>Optimize later when the concept is proven..</b>
Anything new you see added in a week needs another few weeks/months worth of coding for it to work 100% as it is in draft form and it will remain in this draft from until the list of features/mechanics is done, When this list is done the game goes into the next phase of development where the fine tweaking and lot's more optimisation happens.
This normally starts happening when the game is getting close to Candidate Release and this is when things like Skulk Leap, Lerk flight, settings, options, interfaces get a big touch up, Commenting on these things now wont get anything done now and your comments will probably get lost by the time the team is ready to take specific feedback on those.
<b>The right time to look at things...</b>
I have noticed that the team does try to change little things now and then from the early feedback but some feedback is too early.
So that progress is felt by everyone and it is important that progress is made because it affects moral, doing some quick easy tweaks or fixing an easy bug in the middle of a large daunting lengthy task <i>(something that is going to take few days/weeks constant work)</i> helps as a programmer maintain that sense of progress and boost their moral so they can continue to tackle the big task at hand and not fall into a depression pool of "I am getting no where, I have been working on this exact same thing for days now I need a break, I feel depressed now". ~Programming does this to you..
<i>"I feel like i am being ignored"</i> because nothing is done based on your feedback, the reason for this is because right now the team can only handle working on getting the game mechanics in and fixing the bugs and there are over a 1000 active reports, they are a rather tiny team compared to a other studios that have 50 to 260 workers, some projects have more!
The basic functions of these mechanics and the way they handle will be addressed at the right time. Right now the people who are getting the most praise is those helping to debug the code, even submitting actual bug fixes and performance improvements, That's where the focus is right now so please hang on to your tweak based opinions they will get to you soon! :)
<img src="http://tinypic.cc/files/h/hon186617.jpg" border="0" class="linked-image" />
.
<img src="http://tinypic.cc/files/h/hon281718.jpg" border="0" class="linked-image" />
.
<img src="http://tinypic.cc/files/h/hon357336.jpg" border="0" class="linked-image" />
.
<img src="http://tinypic.cc/files/h/hon410301.jpg" border="0" class="linked-image" />
.
<img src="http://tinypic.cc/files/h/hon587428.jpg" border="0" class="linked-image" />
Obviously you don't need to go into nearly as much detail as this, at least prior to the game being released, but some of these categorisations could work really well.
Just have a group of respectable volunteers to categorise them, so whenever the team is keen, they'll have a good starting point for all the tweak-based suggestions and such.
I'm a little confused as to whats in game. It's more a transparent picture of DI that's just stretched on top of the floor? My graphics are on the highest setting.
This is the way I look at it:
<ol type='1'><li>Game play Mechanics</li><li>Rendering</li><li>Interaction/Control</li></ol>
Each one of these requires a lot of code to get working, so each is treated as a separate task but the 3 technologies most be coded to work with each other.
When creating your idea this is what you need to do in this order to save you the most time:
<ol type='1'><!--coloro:#FFA500--><span style="color:#FFA500"><!--/coloro--></li><li>Find and research a <u>render method</u> and test it's function & visual appeal.</li><li>Code & test <u>game play mechanics</u> <!--coloro:#C0C0C0--><span style="color:#C0C0C0"><!--/coloro-->(Decide at this point to scrap or commit).<!--colorc--></span><!--/colorc--></li><li>Integrate <u>Render method</u> with <u>game play mechanic</u> & create <u>Interactions &/ Controllers</u><!--colorc--></span><!--/colorc--></li></ol>
<!--coloro:#C0C0C0--><span style="color:#C0C0C0"><!--/coloro-->The first DI test you saw was a prototype of a rendering method (2). So the other 2 stages are unrelated to it and in them selves a whole feat of coding.
In the DI Render test video had a very quick and dirty Control (3) written in order to provide a way to spread it so they could test it, aka an invisible "DI Gun" to grow it wherever you fired it at a wall. So this DI Gun is one thing, the mechanics to automatically control it according to the status of the Game play/Environment/Interactions is a totally different ball game altogether (3).
DI in the current release is a test of (1) Game play Mechanics. Getting in & testing areas of effect and methods of spread.
Of course how on earth are you going to see what's going on without a visual representation of the data? So because Decals is in the pipeline the clever, <u>fast</u> solution was to write a very simple & quick utilization of decals for the game play testing.
Once all environmental/structural/player interaction has been clarified, tested, balanced & finalized then is time to spend the long haul of getting the <b>3D DI</b> render method hooked up and the code based ways of handling its <u>complicated</u> way on how to spread through a level on its own can be worked on versus the incredibly easy task in comparison to the DI Gun in the Render tech video used to spread it.<!--colorc--></span><!--/colorc-->
You are bound to so this happen with pretty much anything being written into the game while it's in the Beta stage, you should expect to see some very ugly things appear for a while before they have more time spent on them <i><!--coloro:#00BFFF--><span style="color:#00BFFF"><!--/coloro-->(you need to prove it works on a number of levels before you commit more time to its visual appeal just in case you scrap it or replace it with something else)<!--colorc--></span><!--/colorc--></i> , Exact same applies to the Alien Dark Vision, This is a render method researched and tested by applying the basics to an F key toggle. Once proven it can slowly evolve into more advanced FX and be used in other applications such as Sweep scan.