Goblin Squad Member
|
well for once I cannot argue with you... but here it comes. If GW concentrated for the next 6 months on conversion would they have a more enticing product than the wave of indi developers that has been born with the Free UDK4 release? Would they be among the first mmo's released using a cutting edge 2015 game engine? Would they have a better set of development tools? Would they have support from a game engine company with a future rather than one that is about to become irrelevant? Would they have a game engine that the most talented young professionals know how to use in a year from now when they are looking at hiring?
|
Goblin Squad Member
|
Maybe. I have yet to see a Free game that was truly worth playing. Most of them end up very WoW oriented to me and become all about "how do we get to level 50 and raid constantly for gear?" PFO is very different from that. Free also attracts idiots by the horde. I'd prefer not to have those folks about. Birthing this game is painful, but it should be.
|
Goblin Squad Member
|
Maybe. I have yet to see a Free game that was truly worth playing. Most of them end up very WoW oriented to me and become all about "how do we get to level 50 and raid constantly for gear?" PFO is very different from that. Free also attracts idiots by the horde. I'd prefer not to have those folks about. Birthing this game is painful, but it should be.
Do you know what a game engine is?
| 2 people marked this as a favorite. |
He's calling Goblinworks idiots! Get 'im!
Or, alternatively, join him and start complaining about something like overly fancy grass. Whatever floats your non-implemented boat.
|
Goblin Squad Member
|
He's calling Goblinworks idiots! Get 'im!
Or, alternatively, join him and start complaining about something like overly fancy grass. Whatever floats your non-implemented boat.
Complaint? This thread is by no means a complaint. It's a sujestion that could supercharge this game. To not at least consider my arguments is a mistake. The question that must be asked is how long would converting to UDK4 take?
|
Goblin Squad Member
|
Pyronous Rath:
I don't think changing is currently a real option for few reasons.
1) GW has licensed Unity's source code (which cost probably somewhere around 150k)
2) Unity just put out version 5. If GW feels there's benefit in changing, U5 has many upgrades.
3) Unreal takes 5% cut when you actually start making money with the product. Considering GW aims to have a subscription based game that runs for years, that 5% will be more expensive than Unity.
And in the end, no matter which engine you are using, _most_ of the visuals depend on the amount of time spent making models and textures, not the latest and greatest tech. :)
|
Goblin Squad Member
|
| 1 person marked this as a favorite. |
I don't know much about the Unity engine or the Unreal engine. I did experience the Hero engine in SWTOR and it was a true nightmare when you entered a PvP battleground. The lag when you got more ten 6-8 players in one area was difficult at best to play in. Glad that Hero engine is not in use here.
|
Goblin Squad Member
|
I think this thread has made one thing abundantly clear. Most of you would rather open your mouth to naa say rather than take any relevant argument into actual consideration. You have the internet too you know. You could have easily gone and taken a look at UE4's capabilities and tool set. Hell you could have downloaded it like I did and imported a height map. You could have then run around on said hightmap(much nicer than the PFO map if I do say so myself(has things like you know erosion...)). Meh I only care what the devs say for the most part anyways this whole threads intention is that they review the strengths and weakness to switching to UE4. I don't care weather they reply so im sure you can all guess how much I care weather you do. That is unless of course one of you can reply to any of the point's I made rather then just saying things equivalent to "dats noo good gobinwooks not dun dat soooo nope nope daaaat baaad..."-generic fanboy
| 2 people marked this as a favorite. |
The problem here is that you don't really understand how any of this works. Switching from Unity to UE4 is close to completely starting over for probably the majority of their code-base, it's not something you can just copy and paste. They would only get to keep their database.
As to cost...unless they have restructured it since I last read their royalty fee legalese it's applied to the gross revenue of the product that includes the engine. That ends up including subscriptions and store items. While not the majority, it's enough money for the lifetime of the product to be a concern.
You are basically making a proposition that has an incredibly high chance of killing the game straight up because it's not quite pretty enough for you. Which has pretty much nothing to do with the engine anyways. I say that because they aren't going to be using the coolest tricks UE4 can do in an MMO for reasons completely unrelated to graphics fidelity and everything to do with communication bottlenecks.
|
Goblin Squad Member
|
The problem here is that you don't really understand how any of this works. Switching from Unity to UE4 is close to completely starting over for probably the majority of their code-base, it's not something you can just copy and paste. They would only get to keep their database.
As to cost...unless they have restructured it since I last read their royalty fee legalese it's applied to the gross revenue of the product that includes the engine. That ends up including subscriptions and store items. While not the majority, it's enough money for the lifetime of the product to be a concern.
You are basically making a proposition that has an incredibly high chance of killing the game straight up because it's not quite pretty enough for you. Which has pretty much nothing to do with the engine anyways. I say that because they aren't going to be using the coolest tricks UE4 can do in an MMO for reasons completely unrelated to graphics fidelity and everything to do with communication bottlenecks.
Actually it is you that does not understand how much of pfo in man hours is not code all of wich would be transferable. The data base is only a part of that. There is a ton of work that is pure systems design. There are all of the graphics and audio assets. That 5% does not matter if it means 100% better chance of success. Who the hell cares about 100% of a failure which is exactly where this project is headed atm.
The failure of PFO will not alone sink anyone's career. There are talented people at GW. That being said the failure would be remembered by the mmo community in fact many would probably only hear about it in the past tense. I would not want to be the figure head associated with the project especially considering it was funded with trusting prospective customers.
|
Goblin Squad Member
|
| 1 person marked this as a favorite. |
At this stage, moving to Unreal would be a terrible idea. There has been 2 years worth of programmer that would be thrown out. Art and animation assets may also need converting and changing to what unreal uses. Also what Unity offers over Unreal is amazing developer tools for small teams. Unity has a very good pipeline that Goblinworks would then be missing.
It is fully possible for Goblinworks to use unity to make the game appear much better. But that is not a priority. Even if they were using Unreal I would expect the game to look relatively similar the looks right now as the computer graphics are not a priority.
Actually it is you that does not understand how much of pfo in man hours is not code all of wich would be transferable. The data base is only a part of that. There is a ton of work that is pure systems design. There are all of the graphics and audio assets. That 5% does not matter if it means 100% better chance of success. Who the hell cares about 100% of a failure which is exactly where this project is headed atm.
The failure of PFO will not alone sink anyone's career. There are talented people at GW. That being said the failure would be remembered by the mmo community in fact many would probably only hear about it in the past tense. I would not want to be the figure head associated with the project especially considering it was funded with trusting prospective customers.
I am baffled by your interpretation of how code development works. It only takes a few hours to plan months of work that will produce a hundred thousand to millions of lines of code. The idea that just because they already designed the high level systems on paper that 'most of the work is done and reusable' is laughable at best. Changing the more generic aspects of their codebase from C# to C++ syntax is a time consuming task, not to mention libraries, scripting, and engine API specific differences they will undoubtedly have to resolve. The only thing that's close to reusable is their database as they are standalone anyways and possibly their art/sound assets as they are often convertible formats that are from third party tools. I'm also not sure if UE4 has acceptable networking libraries for an MMO, they would possible need to write those from scratch, I know Cry Engine does not. And after all this work that would take months to most of a year to accomplish and the conversion is done...there will be no significant change in graphics.
As to the 5% Royalty I said it was a concern, I don't know their expected net profit margins for this product but typically you need at least an average annual of a few percent to grow your product. That 5% royalty is on gross which could be several orders of magnitude higher than their net. (As an example in 2009 Amazon posted a gross of 22.57% but only a net of 3.7% profits) For long term operations it is usually more cost effective to buy your engine outright to reduce yearly recurring costs. For single-player games it's not as big a deal as the profitability is centered around a single release point.
That all said while I know you are just another troll, if anyone finds this information educational or useful these posts are not a complete waste of time.
|
Goblin Squad Member
|
| 1 person marked this as a favorite. |
Not a troll, but for sure short tempered, abrasive and prone to resort to personal insults when people disagree with him. I guess this community is just too nice sometimes. People even gave him some benevolent smiles about the grass thing which was annoying as hell.
The guy has been on ignore for a long time now.
| 1 person marked this as a favorite. |
It's not his opinion that makes him a troll, it's his staunch refusal to face facts and separate them from his opinions that make him one or at least indistinguishable from one. This particular thread is a prime example of his troll like behavior, we all probably can agree that UE4 is a better engine even if that is technically an opinion. We're not discussing that though, we're discussing the feasibility and advantage of converting from Unity to UE4. Several of us have clearly explained the problems or potential problems with his proposition and his response is 'no ur dumb shutp fanboi' and throwing out a few pieces of jargon in a feeble attempt to imply a deep a knowledge of complex systems yet fails to actually respond to anyone's specific points. If that is not troll behavior than it is one other possible thing that I will not explicitly state to avoid directly insulting someone on these boards.
|
Goblin Squad Member
|
It's not his opinion that makes him a troll, it's his staunch refusal to face facts and separate them from his opinions that make him one or at least indistinguishable from one. This particular thread is a prime example of his troll like behavior, we all probably can agree that UE4 is a better engine even if that is technically an opinion. We're not discussing that though, we're discussing the feasibility and advantage of converting from Unity to UE4. Several of us have clearly explained the problems or potential problems with his proposition and his response is 'no ur dumb shutp fanboi' and throwing out a few pieces of jargon in a feeble attempt to imply a deep a knowledge of complex systems yet fails to actually respond to anyone's specific points. If that is not troll behavior than it is one other possible thing that I will not explicitly state to avoid directly insulting someone on these boards.
Actually you are the only one who explained a specific point of argument(code conversion) and I specifically addressed your point. What no one has done is address a single point I made. Here they are again in case you missed them while furiously implying that I am dumb unreasonable and have never worked on a game(wrong).
1. If GW concentrated for the next 6 months on conversion would they have a more enticing product than the wave of indi developers that has been born with the Free UDK4 release?
2. Would they be among the first mmo's released using a cutting edge 2015 relevant game engine?
3. Would they have a better set of development tools?
4. Would they have support from a game engine company with a future rather than one that is about to become irrelevant?
5. Would they have a game engine that the most talented young professionals know how to use in a year from now when they are looking at hiring(I happen to know many collages have been using unreal engine)?
|
Goblin Squad Member
|
1. No, because all that time spent converting is time not spent making the game any better.
2. Possibly. Relevance?
3. No, since their current toolchain has been customized to fit their needs already.
4. Unlikely. Also [citation needed].
5. My friends in the Indie circuit have experience in all the major engines, so (I happen to know that this point is moot).
|
Goblin Squad Member
|
1. If GW concentrated for the next 6 months on conversion would they have a more enticing product than the wave of indi developers that has been born with the Free UDK4 release?
2. Would they be among the first mmo's released using a cutting edge 2015 relevant game engine?
3. Would they have a better set of development tools?
4. Would they have support from a game engine company with a future rather than one that is about to become irrelevant?
5. Would they have a game engine that the most talented young professionals know how to use in a year from now when they are looking at hiring(I happen to know many collages have been using unreal engine)?
The problem is, you are asking insufficient questions. The questions of more concern to most of us are:
1) If six months is enough (which is far from established, since the exact same number of programmers have been working on it for more than a year, and Artists can't just be magically re-purposed to code) Would any enticing advantage be enough to make up for having essentially stopped the game in its tracks for six months?2) What if they were? The primary audience for PFO is not people who are looking for the best graphics. Is drawing people who's primary interst is the graphics quality a big enough draw to make up for the people they will lose by just turning off the lights for six months? Is it fair to the people who have given them a huge amount of money for this project, and who have spent more than half a year testing the existing system?
3) We don't know if the UDK engine would provide better tools or not. It's very possible it would provide better graphics tools, but graphics are only part of the game. Perhaps people who know the project and code would become worthless because a different set of skills would be needed and they'd have to hire new programmers who don't know what's already done.
4) Has it been established that the Unity Developers are becoming irrelevant? Has it been established that the developers of UDK won't be irrelevant in six months when something else comes along with better grass?
5) For thousands of years, humans under 30 have presumed that because they and their peers are better at using society's newest tools than people who are over 30, they will inevitably produce better work. They are often right, but it sometimes takes them a decade to get there, because they have pretty much always failed to account for a decade of experience with getting the old tools to actually do stuff.
Because: The graphics engine is not the most important part of any game, except games for which graphics are the most important part. PFO is not one of those games.
|
Goblin Squad Member
|
Actually it is you that does not understand how much of pfo in man hours is not code all of wich would be transferable. The data base is only a part of that. There is a ton of work that is pure systems design. There are all of the graphics and audio assets. That 5% does not matter if it means 100% better chance of success. Who the hell cares about 100% of a failure which is exactly where this project is headed atm.
The failure of PFO will not alone sink anyone's career. There are talented people at GW. That being said the failure would be remembered by the mmo community in fact many would probably only hear about it in the past tense. I would not want to be the figure head associated with the project especially considering it was funded with trusting prospective customers.
I am baffled by your interpretation of how code development works. It only takes a few hours to plan months of work that will produce a hundred thousand to millions of lines of code. The idea that just because they already designed the high level systems on paper that 'most of the work is done and reusable' is laughable at best. Changing the more generic aspects of their codebase from C# to C++ syntax is a time consuming task, not to mention libraries, scripting, and engine API specific differences they will undoubtedly have to resolve. The only thing that's close to reusable is their database as they are standalone anyways and possibly their art/sound assets as they are often convertible formats that are from third party tools. I'm also not sure if UE4 has acceptable networking libraries for an MMO, they would possible need to write those from scratch, I know Cry Engine does not. And after all this work that would take months to most of a year to accomplish and the conversion is done...there will be no significant change in graphics.
As to the 5% Royalty I said it was a concern, I don't know their expected net profit margins for this product but typically you need at least an average annual of a...
LOL A few hours for planning months of coding and you have the gall to say"The problem here is that you don't really understand how any of this works.". You know there are additions for visual studio to convert C# to C++ automatically right?!? Oh nooos not du du du THE LIBRARIES. I don't know why you think there would be ANY problem converting game assets. Do you even own a PC or ya just on your Iphone lol.
|
Goblin Squad Member
|
Oh nooos not du du du THE LIBRARIES. I don't know why you think there would be ANY problem converting game assets. Do you even own a PC or ya just on your Iphone lol.Sadly, now you are starting to turn into a troll.
I know I know but not everyone brings out the best in me. I have a low tolerance for bs.
| 3 people marked this as a favorite. |
LOL A few hours for planning months of coding and you have the gall to say"The problem here is that you don't really understand how any of this works.". You know there are additions for visual studio to convert C# to C++ automatically right?!? Oh nooos not du du du THE LIBRARIES. I don't know why you think there would be ANY problem converting game assets. Do you even own a PC or ya just on your Iphone lol.
Go find a large project on GitHub in C# and convert to C++ using one those tools, let me know how well it compiles. While your fixing those compile errors that are literally everywhere you'll discover that it doesn't have any of the libraries you were referencing and in any decent size project there will be many both of your own and third party, let me know how long it takes you to find their equivalents or rewrite them and change all your code to account for those. Now at this point (several weeks from now at best) you might actually get it to compile and run! Of course you'll immediately start running into memory, pointer, and general logic flow issues as the conversion tool is incapable of inferring nuance and can only swap basic syntax. Then spend a few weeks adding debug code trying to find those hidden cases that are causing strange effects without any obvious errors.
You'll then discover performance problems that didn't exist before! Where did those come from? Couple options: either you're using your new libraries incorrectly, using the engine API incorrectly, or it converted to completely different STL container types that all have their own performance quirks, and depending on how you are interacting with them are completely different from their C# equivalents.
And I'm glossing over the fact that there are features that can't be directly converted between the two languages that could result in massive architecture changes or that you'll also have to convert whatever scripting you are using as it will probably not have a 'simple tool' to use.
But clearly it's a piece of cake and a conversion tool will do most of the work (but still set you back six+ months?). I suppose I could be completely wrong, it's not like I do this for a living or anything.
As to your points:
1. Not really, people use different languages and engines for different reasons, if they didn't their wouldn't be the amount of variety there is today.
2. Relevancy?
3. Opinion, not a fact and has a lot to do with their workflow which we know nothing about.
4. Considering Unity 5 was just announced and has been picked up by several major games I think we need a bit more proof before calling it 'dead'.
5. If you are going to college for game design you have already made several mistakes and should probably not be hired by anyone that cares about their development teams anyways. General CS or Software Engineering with a concentration in Graphics will be infinitely more useful and sell-able as a skill-set than a gaming design degree (most of which aren't even accredited anyways). Especially since you would predominately be using a 32 year old language that is one of the primary languages taught in other programming courses...
|
Goblin Squad Member
|
Just as a clarification, is it a Game Design course, or a Game Development course? Because the former are almost always basically production management courses rather than actual programming focused courses. Saying that you are doing a Game Design course and suggesting it provides insight into actual programming technique is probably about as laughable as if Dancey said he was their lead systems engineer.
|
Goblin Squad Member
|
LOL A few hours for planning months of coding and you have the gall to say"The problem here is that you don't really understand how any of this works.". You know there are additions for visual studio to convert C# to C++ automatically right?!? Oh nooos not du du du THE LIBRARIES. I don't know why you think there would be ANY problem converting game assets. Do you even own a PC or ya just on your Iphone lol.Go find a large project on GitHub in C# and convert to C++ using one those tools, let me know how well it compiles. While your fixing those compile errors that are literally everywhere you'll discover that it doesn't have any of the libraries you were referencing and in any decent size project there will be many both of your own and third party, let me know how long it takes you to find their equivalents or rewrite them and change all your code to account for those. Now at this point (several weeks from now at best) you might actually get it to compile and run! Of course you'll immediately start running into memory, pointer, and general logic flow issues as the conversion tool is incapable of inferring nuance and can only swap basic syntax. Then spend a few weeks adding debug code trying to find those hidden cases that are causing strange effects without any obvious errors.
You'll then discover performance problems that didn't exist before! Where did those come from? Couple options: either you're using your new libraries incorrectly, using the engine API incorrectly, or it converted to completely different STL container types that all have their own performance quirks, and depending on how you are interacting with them are completely different from their C# equivalents.
And I'm glossing over the fact that there are features that can't be directly converted between the two languages that could result in massive architecture changes or that you'll also have to convert whatever scripting you are using as it will probably not have a 'simple tool' to use.
But clearly...
If development is organized none of that is an issue. The converters are not perfect but they are a HELL of a lot more capable than you imply http://visualstudiomagazine.com/Articles/2005/11/01/Convert-C-Code.aspx . More like performance increases maby you should read this article it may help or better yet try using UE4...http://blog.digitaltutors.com/unity-udk-cryengine-game-engine-choose/
|
Goblin Squad Member
|
EARTH HAS 4 CORNER
SIMULTANEOUS 4-DAY
TIME CUBE
WITHIN SINGLE ROTATION.
I even took the time to actually link to mine.
| 2 people marked this as a favorite. |
If development is organized none of that is an issue. The converters are not perfect but they are a HELL of a lot more capable than you imply http://visualstudiomagazine.com/Articles/2005/11/01/Convert-C-Code.aspx . More like performance increases maby you should read this article it may help or better yet try using UE4...http://blog.digitaltutors.com/unity-udk-cryengine-game-engine-choose/
Organized development has absolutely nothing to do with anything I last posted, you would be subject to all the possible issues I mentioned if you have the best organized code in the world or the worst, it would just be a lot more of a time-sink in the latter case. Everything I mentioned is a sheer side effect of attempting such a transition and has nothing to do with code quality. That said if you spend any time among professional programmers you would very quickly discover that the best laid plans always fall into traps somewhere, either of their own design or due to the limitations of the tools they are using. There's a reason this is a meme that 100% of the programmers I've dealt with have referenced.
As to the tool you linked I did some research and can find pretty much no one but the marketing spiel from their site praising it's wondrous capabilities. If you search for more generic advice like 'convert C# to C++' you'll find this, this, this, and this along with a bunch of marketing spiels for a few such tools on the first page. You won't find a single testimonial of praise for such a tool from any of the usual corners of the internet where programmers congregate to solve problems. It's almost like we understand the technology we are using...
Ironically I happened upon this rant today that nicely encapsulates some of the problems between the game, it's engine, and the GPU interactions and some of the difficulty that goes into making a modern game simply function. Quasi related to the topic on hand as you would solve all these problems for one engine only to run into a different set on the other engine plus of course language swapping side effects related to interacting with the engine.
Interesting read if you are unaware of how Graphics Card Drivers work and get made. The final conclusion is that it looks like it's getting better with the newer direct APIs like Mantle, but it's still in it's infancy.
|
Goblin Squad Member
|
If development is organized none of that is an issue. The converters are not perfect but they are a HELL of a lot more capable than you imply http://visualstudiomagazine.com/Articles/2005/11/01/Convert-C-Code.aspx . More like performance increases maby you should read this article it may help or better yet try using UE4...http://blog.digitaltutors.com/unity-udk-cryengine-game-engine-choose/Organized development has absolutely nothing to do with anything I last posted, you would be subject to all the possible issues I mentioned if you have the best organized code in the world or the worst, it would just be a lot more of a time-sink in the latter case. Everything I mentioned is a sheer side effect of attempting such a transition and has nothing to do with code quality. That said if you spend any time among professional programmers you would very quickly discover that the best laid plans always fall into traps somewhere, either of their own design or due to the limitations of the tools they are using. There's a reason this is a meme that 100% of the programmers I've dealt with have referenced.
As to the tool you linked I did some research and can find pretty much no one but the marketing spiel from their site praising it's wondrous capabilities. If you search for more generic advice like 'convert C# to C++' you'll find this, this, this, and this along with a bunch of marketing spiels for a few such tools on the first page. You won't find a single testimonial of praise for such a tool from any of the usual...
Part of organized development would be proper comments and and keeping track of variables and library's something I think GW already does. I don't think we should talk any more. You refuse to comprhend anything I write it's downright wacky. meh
| 3 people marked this as a favorite. |
Part of organized development would be proper comments and and keeping track of variables and library's something I think GW already does. I don't think we should talk any more. You refuse to comprhend anything I write it's downright wacky. meh
Every time you try to continue this debate you keep making statements that show your complete lack of experience in this area. Your throwing around buzzwords without actually understanding the context on how to use them.
Comments are nice, but what does that have to do with anything we've been talking about? Comments tell you what you already know or did in case you forget by the time you come back to that code later. While that would be handy in converting code to some degree in case you forgot what a chunk does, they don't magically tell you everything about the new language and engine you're converting to. What magic bullet function do they serve in converting code? (As an aside self-documenting code is all the rage now and minimal comments are becoming more of a thing, I have no idea which philosophy GW is using.)
Tracking variables? What do you mean? Are you saying that each one has a comment? I hope so or at least a very obvious name, but what does that do if you have to rewrite your classes and data structures for the new language and engine? It just gives you a rough guideline of functionality that you probably already know. Not much help in figuring out why the new engine's shader function you swapped in isn't working right or is suddenly causing frame-rate drops. That's of course long after you fix all involved objects' types and collection issues that the compiler is squawking about, and you've implemented memory management properly.
A project of this scale probably has hundreds of classes and thousands of data constructs, do you think there is some document out there tracing the life cycle of every single one? I would bet my left kidney they did not spend that much time documenting. Nobody but groups like Microsoft occasionally documents things that well and they spend a lot of time and money doing it. They most likely have some systems documents (outlining the high level rules and formulas for the game) and rely on general comments combined with well named classes and objects to convey architectural nuance.
I certainly hope they know what libraries they are currently using, it would be very awkward if they were randomly adding them for no reason. Are you implying that libraries are universal and that simply knowing which one they currently use will make converting easier? Because they are not universal and knowing the type you want doesn't mean it's exactly the same in syntax and function across languages. In most cases, especially one where you are completely swapping out one piece of tech for a different one (like a graphics engine), they aren't even close.
The problem here is that your statements don't have anything to comprehend. There is no evidence, referenced projects, or experience to back up your claims. You just keep stating your initial opinion in different words and occasionally Google something to try and prove a point, and so far those few attempts have been easily refuted. This isn't a dialogue because you aren't adding anything, it's just a free lecture about some basic coding concepts from me at this point. I can do this all day, I have faith in my knowledge and expertise in this area to refute, elaborate, or discuss coding concepts if you really want to do that. But that's not what you want, you want to either A. Push your graphics agenda regardless of all evidence or B. Troll.
If the former I'm explaining at the highest level of detail I can without pulling out code examples. If you want to Google parts of what I have said you will find sources discussing the things I have mentioned in varying levels of detail. I'm not making all of this up, that would be an impressive feat itself considering my consistency and ability to elaborate as needed.
If however you are in fact the latter case than at least this has been an educational exercise for anyone following this thread. If you are trolling and you think you're successfully getting a rise out of me, I unfortunately must inform you that I am not the least bit distressed by this, I enjoy teaching quite a bit.
This project almost certainly uses agile development. Everything the devs say implies its an agile model.
I'm pretty sure they do and seem to have shifted from the traditional two week sprint to a three week sprint. Agile has very little to do with code architecture, tools, or style. It's a process designed to simplify organizing your work and focusing on smaller chunks that you can iterate over much faster. The old favorite was Waterfall but that has some drawbacks in terms of turn around time on alterations as it was much more heavily based around accomplishing milestones over compilable and structurally sound bits of code. In addition there were very different philosophies about overhead tasks.
The biggest impact Agile has on your code is how you breakup tasks, you want to avoid having a particular piece of code require time longer than a sprint. This doesn't mean you somehow code less, it just means you organize your chunks better so you can run tests and possibly patch at the end of every sprint, even if a piece of code isn't 'active'. If you aren't going to patch it usually means you run some unit tests and do a high level manual hand-wave before you move onto the next related component.
At my company we do two week sprints, but try to patch on a two month cycle (as needed). We code for two sprints with unit testing and high level manual testing, basically making sure the code doesn't horrible fail and throw errors at the user. During this time the testing team is usually writing their test plans based on design meetings and playing with our daily dev builds. After those two sprints we make a release build and hand it off to testing for about three weeks of manual in-depth, automated, and stress testing. During this release period we (the devs) spend half our time fixing any issues testing finds and the other half either planning our next pair of sprints or if it's already planned we get a bit of a head start on the next body of work.
The release phase's length does change depending on the size of your project and the level of thoroughness you want/need. The other product my company makes has an almost two month release process when they need to do a thorough rel test.
Following a tight sprint cycle like GW is doing is fairly impressive and I'm sure has some nail biting towards the end of each one. I'm actually fairly happy they shifted to three weeks, it should give them a little slack and reduce the chances of having to rollback a patch.
I hope this has been an interesting look into how Agile can be used.
|
Goblin Squad Member
|
| 1 person marked this as a favorite. |
@Pyronous Rath and Thannon Forsworn
I think both of you get lost in detail and you miscommunicate because you argue different issues.
Changing the game engine is a major untertaking and would have a major effect on the game. I think so far both of you agree.
The next step is were likely the disagreement stems from. Here is how I see both sides - correct me if I misinterpret you.
For Pyronous Rath the current game is doomed because of the quality of graphics and he places the issue on the game engine. Provided this is true and that the alternate game engine can improve the graphics there can only be an upsite. Any risk or downsite associated with a change can be neglected because the alternatives are too dire anyway.
For Thannon the current choice of game engine produces a viable product and all further development can only improve it. As such any risk or delay would be a negative.
There might be more disagreement how severe (or not) a change at this stage of the process would be - but even if you agree on this part - you will never agree if you start from a different premise where the project is right now.
I thought I point this out as an observer - even if there might only be a small chance it actually helps.