ArchieChoke
New member
Would love to read your feedback.i find game developement real fascinating.
Buggy Games: Lazy devs or sneaky tactic?
- Thread starter MalicE
- Start date
Blazzok
New member
Read the thread while drinking my first cup of coffee for the day, very interesting and nice to see the input from the guys that actually do development/coding for a living.
What Hammer said is basically what I think as well, I don't think the devs go out of their way to screw over customers or that they are lazy. Late design changes or additions to the game probably also contribute to bugs as these things have to get added late in the development phase and now have to tie in to things that have already been finished.
I think the same principles apply for development as for any big engineering project. Changes early in the concept phase are fine and low cost and still relatively easy to tie in with everything.. The later on in the project you make the change, the higher the cost impact and it also becomes much more difficult to tie it into the project, especially if additions/changes come during execution phase of the project. Some things are already built and finished, but now they want to change something and it becomes quite the bugger-up. Obviously they also want the changes/additions to be made while sticking to the original timeline, which is mostly impossible.
So you either do a scrappy job to get it to fit into the timeline, or you move the final delivery date to a later one.
What Hammer said is basically what I think as well, I don't think the devs go out of their way to screw over customers or that they are lazy. Late design changes or additions to the game probably also contribute to bugs as these things have to get added late in the development phase and now have to tie in to things that have already been finished.
I think the same principles apply for development as for any big engineering project. Changes early in the concept phase are fine and low cost and still relatively easy to tie in with everything.. The later on in the project you make the change, the higher the cost impact and it also becomes much more difficult to tie it into the project, especially if additions/changes come during execution phase of the project. Some things are already built and finished, but now they want to change something and it becomes quite the bugger-up. Obviously they also want the changes/additions to be made while sticking to the original timeline, which is mostly impossible.
So you either do a scrappy job to get it to fit into the timeline, or you move the final delivery date to a later one.
FarligOpptreden
New member
What works best is building frameworks that accommodate configurability. Once you're in a specific environment long enough (usually 6 months should be enough) you get a feel for how things generally tend to work. You can then identify certain trends in the way projects get built and the architecture (hardware and software) that should be adhered to. You can then review 5-10 projects that were recently delivered and identify the commonalities between them. Once you have that scoped, you can easily identify a framework or pattern that can be implemented to build similar projects in the future. I tend to take those projects I identified as case studies and convert them to use cases for the new framework.
With this philosophy I've managed to build 2 specific frameworks at our biggest (in-sourced) client (one of the 4 big telco operators in ZA) that currently cater for about 70% of the requirements. Where a project was usually scoped for 3 weeks minimum, we can now do it in roughly 2 days. Our biggest achievement yet was being able to deliver a 1100+ hour project in just under 200 billable hours (which equated to less than a month between 2 people) - our direct client (that sources us in to the telco provider) smiled all the way, as they had sign-off for the 1100+ hours and we could immediately start on new projects. Because the scope of that project was so large, we managed to identify certain patterns to build another framework for future projects. These frameworks depend purely on database and properties file configurations, so no new "code" has to be built to meet the requirements of a project. This allows for more testing and QA to be implemented, which in turn results in projects that are much more stable and require the absolute minimum maintenance and support.
DieGrootHammer
Daddy TK
But remember, Batman was an exception more than the rule. It was released completely broken to the point that it was removed from sales, twice. That does not happen often, if ever.
ArchieChoke
New member
Quick question.
Your QA team, do they rely on the use case documentation as a guideline for testing. If they do, how much deviation from the flow process is a must. I.e. advising the QA team to follow the document, but at the same time attempt to break the system by deviating the step by step process.
Not sure if that make sense.
MalicE
Party time! Excellent!
ok yes, a rare occurrence I admit. I'm more interested in how it happens THREE TIMES.
Also, Beta testing! and this happens more often. games are released for alpha/beta testing, whether it be open or closed testing, they get all the feedback from the public testers and then release the game completely ignoring the beta feedback.
it feels beta testing has become more of a marketing gimmick these days
FarligOpptreden
New member
Luckily there's a completely separate test team that does QA and UAT. I'm a very strict perfectionist by nature, so I do a first round of code-reviews and "QA" with my team. The test team has a set of test cases they need to work through, but I always make sure to build fault tolerant systems that can deviate from the process or attempt to clean dirty inputs. I also try to implement timed retries for integration (via message queues) to make sure there is guaranteed delivery (because network connectivity can sometimes be down between disparate servers). If business rules were violated or data could not be cleaned, we have custom dashboards for the operational team to monitor and attend to.
ArchieChoke
New member
Luckily there's a completely separate test team that does QA and UAT. I'm a very strict perfectionist by nature, so I do a first round of code-reviews and "QA" with my team. The test team has a set of test cases they need to work through, but I always make sure to build fault tolerant systems that can deviate from the process or attempt to clean dirty inputs. I also try to implement timed retries for integration (via message queues) to make sure there is guaranteed delivery (because network connectivity can sometimes be down between disparate servers). If business rules were violated or data could not be cleaned, we have custom dashboards for the operational team to monitor and attend to.
Thanks for the response.
What languages you familiar with? Are you still making use of DFD, FTDD's, ERD's, etc... ?
DieGrootHammer
Daddy TK
Don't get blinded by one game release that's been broken as all hell and assume ALL games do not have proper testing procedures. Fallout as well had more than it's fill of bugs and glitches, but most other games that I've played have been as smooth as a baby's bottom.
Yes, giving people access to open beta's are a way of getting some much needed hype and word-of-mouth advertising that games so desperately need in this extremely saturated market. But it's also a big gamble. Having a bunch of people play a beta, they will form incomplete or incorrect opinions about a game that's not even done yet, and still have a lot of bug fixing and testing to be completed. So it's just as much a marketing gamble as it's a marketing tool. Beta's are much more technical showcases to see if the game is currently performing as what the developers have planned.
FarligOpptreden
New member
If you're talking about development languages, the stacks we currently use are Oracle (Java / PL\SQL / Glassfish) and Microsoft (C# / T-SQL / IIS). When building web applications, the technologies are the same (HTML5 / CSS3 / JavaScript & jQuery), but we use MVC-type approaches for server-side view rendering (Spring MVC for Java and our proprietary Handlr framework, which is very loosely based on ASP.NET MVC, but much lighter).
Regarding business documentation, the business analysts do still make use of DFD's, ERD's etc (the open standard in this environment is GraphML, so we all just use yEd), but since the architecture of the projects we deal with are fairly similar and we implement an agile project management approach (scrum-like), we rather iterate features over a short period of time to make sure we meet the requirements. In a fast-paced environment like telco, you don't have the luxury of month-long projects with meetings upon meetings upon documents upon documents. The sign-off from the executives usually takes longer than the actual delivery of a project.
ArchieChoke
New member
Fills me with sommuch joy to hear the sh*t im being taught is actually used. Thanks for the replies much appreciatedIf you're talking about development languages, the stacks we currently use are Oracle (Java / PL\SQL / Glassfish) and Microsoft (C# / T-SQL / IIS). When building web applications, the technologies are the same (HTML5 / CSS3 / JavaScript & jQuery), but we use MVC-type approaches for server-side view rendering (Spring MVC for Java and our proprietary Handlr framework, which is very loosely based on ASP.NET MVC, but much lighter).
Regarding business documentation, the business analysts do still make use of DFD's, ERD's etc (the open standard in this environment is GraphML, so we all just use yEd), but since the architecture of the projects we deal with are fairly similar and we implement an agile project management approach (scrum-like), we rather iterate features over a short period of time to make sure we meet the requirements. In a fast-paced environment like telco, you don't have the luxury of month-long projects with meetings upon meetings upon documents upon documents. The sign-off from the executives usually takes longer than the actual delivery of a project.
FarligOpptreden
New member
Pleasure man! Hope your teachings pay off... Best is just to always read up and predict where the industry is going. Not all "best practices" end up being implemented and quite often get deprecated a year or so down the line. Rather use the past couple of years' trends as an indication of where the industry is going and follow their developments.