Take 2?

[vinylrake]

Yes. I get bombarded with requests for mapmaking features from Graydon on a regular basis because of it.

Whatever happened to people developing projects based on the actual environment?


EVERYONE STOP BOTHERING MYRD SO HE CAN FINISH 1.7!!! I want TEXTURES and I wants em NOW!!

Any further pestering of Myrd for new features will result in my driving to your house (yes, I have land-water car so I don't care if you are on a different continent) and slapping you upside the head. Repeatedly, until you stop bothering him!

SO DON'T MAKE ME DRIVE OVER THERE YOUNG MAN!!!

[Graydon]

Features make things bettur. mmmmm. Features.

[Pyro]

It's not like Myrd says yes to all ideas! He says no a lot, or else there would be a longer to-do list for 1.7.

[vinylrake]

Yeah I know features make things better (assuming the features are good of course and don't inadvertently break something else), but it's better to have a release with a small set of features actually get released and into the hands of people who will use it rather then keep adding features and extend it's development lifespan indefinitely.

Even asking about a feature means Myrd has to stop to think about the request and decide if it's completely impossible or if it might be possible, and if it might be possible then then he probably has a followup conversation about what specifically is being asked for, pokes around a but to see how convoluted the code is and thinks about how he would make the change and any implications of making the change. All that takes TIME, time he could be spending finishing 1.7 - and that's BEFORE he even starts coding or testing.

To make a hypothetical parallel analogy to maps, I would MUCH rather play a fun, self-contained single-level solo map that actually gets FINISHED (like Fortress of Doom), then wait years for a mega multi-level campaign that is pushing the envelope of features and which may never get finished. I like the approach the Special Forces team took - they realized they had been working on the project for years, and they weren't going to be "done" for the foreseeable future, so they released what they have so far with the understanding that it's going to continue to be enhanced with new versions. Myth 1.7 should be the same - not the last chance to get features into Myth II, but the next step in Myth II's evolution, with more versions to follow down the road.

Let's get Myth II v1.7 out the door and give Myrd a break before we completely sap his enthusiasm for working on Myth II completely dry.

note: Opinions in this comment are not meant to apply specifically to any projects mentioned recently in this topic.

[GodzFire]

No worries. My love for Surfin Myrd keeps him going!

[Death's Avatar]

I don't think asking myrd is really wasting any time...

He knows how to handle the feature requests, have faith in the man!

[Pyro]

Yeah, what DA said. Myrd says no even with stuff he thinks is possible to code in time. You forget about the features he wants to code into it which is probably why it still needs some time.

[Renwood TWA]

Myrd has fun clicking away and adding stuff, much like we all enjoy making all new myth content.

But yes there is a certain point where its better to release what evreybody is happy with, then to just keep adding stuff forever.

only things missing really in the myth builds are:

1.More monsters on the screen at once
2.More projectiles
3.Ai scripting tags for units (Unimplemented completely Bungie TFL feature that Myrd knows how to do, even if its very difficult)

4.Futher camera Zoom out distance/viewable area
5.units that can attack WHILE moving
6. and various things talked about with PPE and prominent mythers about what could be added to marius.net code or to the myth builds to add to the multiplayer EXP. like being able to save vets to a "Bank" for use at future times. Like bringing in your 17 kill vet War and 9 kill vet J man into a game of ffa gimble CTF. Also things like being able to rejoin a game in progress with a password given when the host started the game. If you join a game you werent allready in when it started then you can only observe until the next game. These would all be options for the host to choose so nobody is forced to play with these types of changes/additions.
and other things along these lines that i cant think of right now that PPE and a few Magma people have said we _could _implement.

Yea #6 was pretty long huh?

So if none of the above things are going to happen (I dont see it happening for various reasons we all have been through and understand, not wanting to increase system specs or break functionality with older builds) There should be a release of 1.7 for public BETA.

We all seem to be happy with the state of things, and half the time other stuff is added it breaks other things and then we all have to spend a few more versions of builds testing and fixing shit.

While this is all kinda fun and evreything we could keep it up for a really long time. But lets Release 1.7 for PUBLIC BETA to find any glaring bugs, get a huge pool of testers to see if we missed anything And get this bad boy called 1.7 out there for final release!

-Renwood

P.S allmost forget #7 did we indeed fix the whatever value in units pathinging code that was incorrectly altered? (doobie or some magma guy long ago told me it was real and was noticed that the value was altered -1 instead of +1) the one that makes units now LEAD the enemy they are chasing instead of the BUNGIE style ai pathfinding where if you click on an enemy your guy wont LEAD and go to where the enemy is GOING to be, but will just run AT the enemy and start chasing behind him and hacking him.

The way it is now since your unit allways trys to lead where he is moving to to intercept the enemy at a ceratin point, Players on myth have been exploting this for years now making dorfs and other units run around in little circles and zig and zag in certain patterns to make your unit that is trying to inercept the enemy try to lead to the spot that the enemy IS GOING TO BE instead of where he IS at the time. this leads to HAVING TO BABY SIT your units just to keep them from being fooled by these changes in direction, MUCH like how you can fool an archer with walking and then stoping as soon as he starts to fire because he is LEADING the target. With missle units this is needed and works fine, but if your MELEE units start doing that its really a buncha BS. Most of the really high ranked people use these tactics, i see them do it all the time and none of them deny it when i accuse them of it. They do it because it works and i dont blame them for it, but its because of a bug or incorrect value that makes it possible.

It shows itself the most when you send 1 melee unit to kill an enemy dorf, and the dorf just zigs and zags and runs around in little circles making both units just kinda spend all their time turing in place giving the dorf's teamates PLENTY of time to run up and kill your melee unit that kept being stupid and trying to lead the dorf instead of just running AT him and hacking him.

Whew that was a longer post then i imagined it would be heh

Please respond with your thoughts guys!

[Renwood TWA]

O wait few more ideas!

#8. Make it so you can MAP in prefs the MOUSE WHEEL BUTTON to bring up inventory. beacause as it allready is now you have to hit I then use mouse wheel to SELECT the inventory, BUT if you coulld just hit the mouse wheel to bring up inventory, and then again to select that item OR you click on the enemy/freindlys/or the ground to use slected item.

This would REALLY increase the speed with wich people could use inventory, and certainly make its a lot more easy during intenes battles where you cant take the time to hit I and then a # on the keyboard, because your taking fingers off other keys you need to be using.

#9. A reflexive key mappable for units to use a special abbillity.
Like being able to hit Shift or a mouse button with a warrior selected and he would block and arrow with his shield. instead of how it is now where you have to go into inventory, select "shield block" then hit T. kind of hard to do that in the split second you have while the arrow is flying at you, but if you could hit a KEY to use a reflexive abbillity it would be easy.

#10. a kinda of ctrl click for telling units to MOVE to an area, so if you accidently told somebody to go somewhere but instead missclicked on an enemy or freindly unit your unit would go there. Kinda like how you can ctrl click on a big blob of enemies and your unit goes there to attack it with whatever weapon.

[Myrd]

Now look what you started VR.

[vinylrake]

Now look what you started VR.

Just IGNORE them Myrd, this was a much better example of wasting your time than i could come up on my own.



ps. To the naysayers that I don't trust Myrd - I have lots of faith in Myrd, I also know as a developer that at some point you just need to say 'This is what it will be and no more", put the blinders on, crank up the tunes and stop answering questions and suggestions from 'helpful' users who will (in their quest to get as much functionality as possible into the next release) scope creep the project to death with perfectly nifty but really involved (if not all but impossible) 'enhancements'.

[Renwood TWA]

no vr your missing the point of why myrd gets bugged to add things, myrd likes to the do changes that are quick and maybe less harmless. its the complicated things that dont get added too often. ~8^)

but for the record, myself, ooga, Road and toxyn all think 1.7 should be in public beta soon-ish rather then the first quarter of 2010.

But there is still a lot of work with textures and choosing maps to add and stuff so that no matter what, it couldnt be released tomarrow. Then there is Oak and umm Ambery-Oak. i dont know how close to being finnished their creators think they are. i havent played with them much so i cant say, but i imagine they could be or will be sperate downloads anyways and maybe wouldnt need to be finished when the 1.7 patch would be released.

blarg

[vinylrake]

no vr your missing the point of why myrd gets bugged to add things, myrd likes to the do changes that are quick and maybe less harmless. its the complicated things that dont get added too often. ~8^)

No, I completely understand WHY Myrd gets bugged to add things, BUT as a software developer myself, I also understand (unlike many people who do not write software so don't really grok the complexity of modifying someone elses code) that even 'quick and maybe less harmless' modifications need EXTENSIVE testing to make sure the 'little change' hasn't caused something else to go all wonky.

It is this EXTENSIVE testing which is CRUCIAL and which adds time to the project, and since (as I am sure Myrd or anyone involved in beta testing previous versions of Myth II can attest to) the source of some new wonky behavior isn't always logically direct the more modifications you make to code, the more time it's going to take to debug ANY glitches or bugs.

ex#1. I make a change today, a few people test the change over the course of a week so everything appears to work great. Release the code to a wider testing pool and another 3-4 weeks of testing doesn't reveal any unexpected complications or bugs so the fix worked and it's ready to release to general public.

Ex#2. I make a change today, a few people test the change over the course of a week and everything appears to work great. I make another change next week(week#2) same week of good results, then on week#3 I make a change and a week of testing shows good results, so now my new version with 3 modifications is rolled out to the wider beta testing group and when people start testing it some odd glitches are found. So - is the change due to week#3 change? Probably, but not necessarily - maybe some different conditions were met in the week#3 testing which weren't in week#1 or week#2 so the problem is back with the fix made in week#1. But because there wasn't time to extensively test each individual change the developer is left debugging several possibly overlapping fixes.

Executive summary: Unless you disagree with my basic premise that adding more features (even small ones) and fixing bugs increases the time it takes fo finish ANY code development project, you don't need to reply to this.

[GizmoHB]

maybe myrd should focus on making myth play on its own, without user interaction, that way people wont request more features... simple... =)

...Giz

[Graydon]

VR, your whole post there, perhaps though not intended, seems to be somewhat targetting all these 'features' you talk about to potential _gameplay_ bugs that could be found.

Where in reality, many 'requests' that are made arent for new _features_ per se... not gameplay features by any means.

For my example: Prior to build 311? of 1.7, Myth 2 Overhead Map .bmp files had maximum dimensions of 384x384 pixles. Anything larger than this and your overhead simply doesn't show up. I got myrd to look into these restrictions and expand them to something large... 4096x4096 i think are the dimensions he went with.

Now.. using this example, I'm curious as to how anything gameplay related whatsoever could possibly have changed?


This example, obviously, isnt the only type of request myrd gets... but my argument is this: keep in mind, not EVERY request is going to require extra extensive weeks of testing. Before it wouldnt load... now it does. Thats all. Overhead maps dont affect gameplay directly (short of user input based on what they read off that overhead). So please dont assume I'm personally holding up the production of 1.7

I think it's a safe bet to say that _generally_ GUI changes aren't going to delay things anymore than the physical time it takes to code them. Would you disagree with this statement?