Jump to content
  • Advertisement

chervenkoff

Member
  • Content Count

    27
  • Joined

  • Last visited

Community Reputation

102 Neutral

About chervenkoff

  • Rank
    Member
  1. I didn't call it failure, but a disappointment, for most of us... maybe not the young kids demographic. But that aside, it really depends on how you define failure. They failed at satisfying (and in return monetizing) a large audience. Maybe they weren't really aiming at this audience. Even if this was the case, I am sure the overwhelming bad reviews resulting from the disappointment did not help sales. It is a curious case
  2. [color="#171E29"][font="Arial"]That’s quite interesting. Do you think then, that setting the right user expectation is key to the success of a game? I know it’s what you’ve been saying, but I’m thinking of how marketing generally works, and I will draw a parallel between an industry I believe is quite similar in many aspects – the movie industry. When a film is marketed nowadays (and I hate how they do it), they practically get all the good moments of the movie and put them together to make sure they get the potential viewer’s expectation as high as possible. I never understood that. True, it would bring in more people on the opening weekend, but ultimately, the high expectations will (in most cases) yield disappointment when people realize they’ve already seen the good parts over and over again. I know I am generalizing, but I firmly believe it is the model-case of what happens. The following weekend, people will know (generally either from critics or friends) the movie is bad and won't go to see it.[/font] [color="#171E29"][font="Arial"]I think this scenario isquite similar to what happens with games, except games seem to suffer even more as they generally rely on long-term sales and not on opening-weekend sales. The point I am trying to get across I guess is that marketing principles seem harm sales with overhyping (as you pointed out with SPORE), resulting in disappointment. So, making sure the customer knows what the core/creative vision is during development or keeping them fully in the dark look like the best options in my opinion. Maybe you don’t agree, in which case I’d love to hear why.[/font] [color="#171E29"][font="Arial"]This is why I think, whatever the solution to formulating the core/creative vision is, it shouldn’t be introducing any significant overhead. A wiki seems like a good concept, until you realize you need to motivate people to use it, and that, atleast from what I have learned from my Knowledge Management course, is a close-to-impossible task, unless you somehow convince all users (of the repository) of the “return on investment”.[/font] [color="#171E29"][font="Arial"]I am thinking about an abstraction of the core vision, something that could be utilized fast to see if a particular requirement is in line with the vision; practically a “synonym” of the initial pitch, where the main requirements are semi-formally described and unambiguous. Should allow for evolution of the vision, but in a semi-formal, structured and modular way. Maybe, part of the definition should have some classifications (see my reply to Zethariel’s comment) that can help in quickly assembling a definition of the vision. [/font] [color="#171E29"][font="Arial"]Would love to hear your (and any other expert’s) ideas and comments on such an approach to defining thecore/creative vision. Any alternatives and criticisms are more then welcome as well [/font] [font="Arial"]As I said earlier, I think the answer to my search is probably hidden in the way of doing a good “pitch” and then sticking to what made the pitch get a “green light” – the point of excitement, the selling points.[/font] [font="Arial"]Got any literature on pitching a game design? Or maybe even some pitch examples? If I get my hands on some pitchcases, I think I'll be able to understand the problem better.[/font] [font="Arial"]As for the “higher up” person with understanding of the core concepts, that seems like a good idea, but again, how do you make sure he understands what the core concepts – tacking the same problem here. [/font] Thank's for the help again
  3. [font="Arial"]Appreciate the comment Zethariel [/font] [font="Arial"]What you are saying is quite logical and I guess by theme and experience you refer to the same thing I call core/creative vision. What I am looking for is for a way to describe what this means in simple terms, hence an abstraction explaining what the right amount and structure of information describing the vision/theme/experience of the future game is. As you pointed out, this artifact should facilitate change/evolution of the concept(s). Such an artifact could be used not only to communicate a common understanding of the project at hand, but could also be used to prioritize requirements that have similar cost/risk, by comparing if Req. A is in line with the vision.[/font] [font="Arial"]This pretty much sums up what my research aims at, and if you could share any ideas on how can the vision/theme/etc. be formulated, and what would the right depth of detail be, you’d be helping me immensely.[/font] [font="Arial"]What you say here gives me the idea of classifying the vision in several levels: technology used, story, art style… maybe genre? Hmm… I guess classification of these levels might be a good start for describing the core/creative vision. If you care to comment on idea and maybe suggest what you think would be most appropriate as classifications, I’d be real grateful.[/font] [font="Arial"]As for the pitch, I think what I’m looking for hides in the definition of “the best possible pitch”. Only question is, what would that be? [/font] [font="Arial"]Darwinian logic Seems quite fair by natures laws, but my intentions are to help save some of “the endangered species” In other words, develop some generic and easy to apply method or guideline to defining a clear (core/creative) vision and use that definition to communicate it between stakeholders, preserve it throughout the project life cycle, and also use it as an extra dimension for prioritizing requirements. Moreover, such a method should be helpful when defining the initial pitch.[/font] [font="Arial"]I hope you’ll agree this isn’t really that ambitious and would help me out with any suggestions that come to your mind, as you and everyone else here are the people with industry experience. I couldn’t possibly realize my research relying solely on academic literature.[/font] [font="Arial"]Thanks again for the comment.[/font]
  4. Neat ideas here Bigdeadbug! Thanks! I think what you are proposing is quite logical. I see you say "the experience I wanted for the player", but what happens when you are working in a larger project, with more people who assume the role of defining the importance/priority of a requirement/idea, how do you communicate the desired experience with the rest of the people involved. How do you make sure everyone knows what that player experience is? I'm curious. That's interesting, why do you think SPORE failed then? And you bring up an interesting issue here - the communication problem between designers and developers - what would you say is the reason(s) for this poor communication of ideas? Great! Thanks for the literature, that will be quite useful for the research I think your ideas are pretty interesting. About the first one - a single person in charge of keeping a game in line with the core vision - who do you think should be in charge - the designer? Or the person who came up with the idea for the game? Or maybe someone else? About your second idea, the wiki - as an information science student, I have come across too many cases of companies (... true, business companies) that have trouble using a shared repository (such as the wiki you propose). What would make/motivate the people involved in the project use this wiki? And how do you think this wiki should be laid out - how would you structure the information in it? Would you put everything in there (i.e. the whole game design document content) or would you select only what is important to be shared with the rest of the team. In the case of the latter, what would you say is important and needs to be made clear across all involved in the project. That's my general hypothesis as well, but here comes the hard part How do you outline the core concepts? How do you check if an idea "sticks to those concepts"? You suggest an outsider, someone involved in neither the design, nor the development. Seems like an important role. Who do you think can be entrusted with such an important task? I understand you think it shouldn't be a designer or a developer, what is your logic behind it? I think that is spot on! And also shows how important requirements/idea prioritization is when selling/pitching the idea. I always thought that if there is a guideline/method for prioritizing game requirements, it should be available and applied before pitching the game idea, which means that it's game designers that should be using it. This is exactly why I'm here, talking to designers. It became quite clear that it's not the job of developers, even thought I think it might be quite important that developers at least understand the reasoning behind the prioritization. I'd love to hear more on those issues.
  5. The main idea, the backbone of the game, the concept... The core vision, the most important and simplest representation of the game design. It is a very good question, as I would like to hear the definition of this term by designers - what do you think is the core/creative vision? How would you define it?
  6. True, however I am interested in the designer's perspective, and after speaking to one of the moderators here, I was advised to make this one. As for the other topic, I'll make sure I get back to it soon... Had a busy month
  7. Dear game designers and creative minds, My name is Alex Chervenkoff and I am a master student at Utrecht University, The Netherlands, doing my thesis project on Requirements Prioritization for the gaming industry. This post is a continuation of my search for expert opinion (meaning your opinion) on the topic of prioritizing game requirements – “How it’s done today?”, “How can it be improved?”, and generally, “How can the core/creative vision of a game project be preserved during the pre-productionand production stages of game development?” To illustrate the problem I’m focusing on, think of agame such as SPORE, where a perfectly brilliant game idea was smothered by the studio’s inability to prioritize and focus on the requirements/ideas that make-or-break the game – ultimately resulting in a disappointment proportionate only to the initial hype SPORE created. In software development, requirements prioritization generally evaluates the cost of implementation (time, money, people etc.) andrisks of implementation (e.g. new and untested technologies, dependencies between requirements etc.). However, as sunandshadow put it on a related topic: Of course, this is an oversimplification of the problem, but it illustrates the logic quite well. To try and summarize my intentions with my thesis: I am trying to develop a method for requirements prioritization for game development where the dimensions of cost and risk are supplemented with another dimension – the degree to which the core/creative vision of a game project is dependent on aspecific requirement/idea. In simpler words, how important is a specific requirement to the core idea of the game. In order to be able to do this, I need your help in understanding the process of prioritizing features in the game industry today. The developers I have talked to generally take little or no interest in the prioritization process or in the notion of preserving the core/creative vision of a game idea. In my opinion, this has to do with the fact that developers get blocks of already prioritized requirements (think agile development, SCRUM etc.) and all they need to do is code, code, code. On the other hand, the few designers I’ve talked to had a greater interest in having a clear definition of the core/creative vision of their "child". This is why I end up here, asking for help in answering the following questions: How do you decide if feature A or B is more important to your game design? (regardless of their cost or risk of implementation) Do you think it is important to preserve the core/creative vision throughout the development? How do you do that? Do you think it is a good idea to prioritize requirements not only based on their cost and implementation risks involved, but also according to their importance to the core/creative vision of the game design? How would you do it? (P.S. The product of my thesis revolves around this question and it’s answer.) I will highly appreciate help answering any of these questions! Moreover, if anyone is interested in closer collaboration on developing a method for requirements prioritization for game development, I will be extremely happy – just PM me! The final thesis and any product will be publicly available, and will hopefully provide novice designers and developers a good practice for requirements prioritization and preserving the core/creative vision of a game development project. If you have any questions, I will be glad to answer them. If there is any need for clarification, just say so, and I will try my best to explain. Also, since there is a similar topic based on the same research, but from the developer's point of view, you can check out the detailed explanation of the reasoning behind my research there.
  8. What is your position on always carrying an umbrella with you? [/quote] Point taken! Everybody is providing very interesting insights that will definitely help not only my (and hopefully other readers') understanding of the industry, but also my research. There are quite a few of the comments here that I would like to address, but over the next few days I will be busy preparing for an exam, and I think all posts here deserve more than just a one-line reply. Hope I'll hear more by anyone caring to comment on the subject!
  9. And again, it's a flawed premise. What this describes has been a solved problem since cca. 2005. It's called agile development (with variations Agile, Scrum, XP, ...). On business level, it's called Lean development/Lean company. The entire process can be summed like this: 1) build minimum viable product (if it's a technology service, might as well do it manually at first) 2) launch it 3) measure hourly, daily, see what works with market 4) kill features which aren't working, improve on what does 5) goto 3 Some relevant examples: - Ycombinator, Seedcamp (hundreds of companies launched, many exiting at tens of millions all during ~3 years) - Zynga (they don't have design teams, they copy, then measure to see what works) - Google (multivariate testing, "cost of experimentation is 0", design by metrics) - Facebook (continuous integration, see tech reports) - Starcraft 2 (pvp was king, it kept SC alive for 12 years, so they ran public beta test for 6 or so months, measuring every parameter and tweaking until they reached perfect 50/50/50% pvp balance) - World of Warcraft (find articles: we built it, then asked ourselves: "is this fun?" if it wasn't, the feature was scrapped) - See Mass Effect development logs on how they chose what to improve Counter-examples: - Spore (unproven technology, never before tested in market nor tested during development) - Star Wars Galaxies (radical, over-night changes, released without warning or testing) - Duke Nukem. Development hell with not a single release. Short version: - Cost of testing in actual market itself is 0. Don't theorize - launch it, measure with actual customers - Don't plan, don't have long pipelines. Iteration time should be measured in hours. The faster the releases, the more features can be tested (see Continuous integration, Continuous Deployment, integration testing and related) The above are hard proven techniques that improve "quality" by orders of magnitude. They are not only theoretical, they are the foundation that built the companies mentioned above. They work, are the norm and are proven. They do no work in regulated (legal, government, medical) B2B environments, even though they are slowly adopting variations of agile techniques. The reason 2005 is mentioned is because it represents inflection point where hardware became cheap enough for everyone to fully implement required technologies. Same pattern is seen elsewhere, from mobile app publishing to book writing (AOL content farms, see their conversion requirements), music generation. The technique is old (see movie screenings), in world of software it can just be automated to extreme degrees. It works, it's proven in real world. The research these companies are interested in these days is data mining. The CS part is involved with improving data mining tools (hadoop, see Yahoo!'s spin-off) as well as new approaches to databases for n-dimensional analytics over ad-hoc data sources. Perhaps the most important part to understand is that none of the above do requirements gathering in traditional sense. There are loose guidelines, engineering adapts on the fly to whatever market responds to. And if it means scrapping original idea, do it yesterday (pivoting). The challenging parts that cannot be solved in this way are strategic directions (perhaps IP licensing or merchandising tie-ins). But these are typically hard requirements which are non-negotiable so they aren't subject to scrutiny - even if they have detrimental effect on product. [/quote] Great reply thank you, quite informative! I am curious, what is your position on keeping and referring to a well-defined core vision during the development cycle of a complex video-game project?
  10. [color="#171E29"][font="Arial"]It all started during one of my master courses - Software Product Management, where me and my colleagues were introduced to many best practices and techniques for managing a software product over its whole life-cycle, from its inception to customer delivery, to generate the biggest possible value to the business. Sounds ambitious I know, but there are some interesting solutions on every level. On the lowest level - requirements management – I got introduced to popular techniques for requirements prioritization.[/font] [font="Arial"][color="#171e29"] [/font][font="Arial"] [/font] [color="#171E29"][font="Arial"]I did a little research back then on what happens in the game development industry – spoke to a couple of developers and found out that when it came to choosing what to implement, cash was king – in other words it was all about what sells. Interestingly, everyone agreed that the creative vision should play a bigger role in the development process, as they agreed on the artistic nature of this entertainment software. I got some interesting suggestions on how this can work in terms of requirements prioritization. Ideas included prototyping, sketching, asking every possible stakeholder including testers and target groups to rate ideas/requirements according to their value to the core vision of the game, etc.[/font] [color="#171E29"][font="Arial"]Using these ideas and techniques from method engineering, I build an initial prototype requirements prioritization technique that would accommodate rating requirements by their creative/entertainment value. I ran it through my respondents from the industry for some feedback, and it culminated in an assignment research paper. However, doing this properly was too ambitious for a paper, so after reading a bit more on the topic and receiving support from my professor in Software Product Management, I decided to elevate it into a master thesis.[/font] [color="#171E29"][font="Arial"]I didn’t want to share all this here because I wanted to hear/read unbiased ideas – I wanted the discussion to develop naturally. Maybe not the best approach, but at the time of posting, it seemed to me like the right thing to do. [/font] [color="#171E29"][font="Arial"]My questions were very subjective, thus I needed subjective answers from industry experts (developers, designers, artists, managers etc.).[/font] [color="#171E29"][font="Arial"]One thing I came here for was to see how game developers feel about bringing the core/creative vision of the project into requirements prioritization. Until now, I have found out there are people that believe it is important and needs to be taken into account; and others that think it will just introduce overhead and/or is pointless. Regardless of the position taken, I need the reasoning behind it.[/font] [color="#171E29"][font="Arial"]Another thing I came here for was to see how developers – people with realistic view on the inner workings of the industry – would suggest to incorporate the core vision into requirements prioritization and (the whole development cycle). This is where my [/font][color="#1C2837"]survey[color="#171E29"][font="Arial"] steps in as well, with open-ended questions on the issue. If anyone thinks the questions are invalid, I am interested in the reasoning behind it, which can be explained in the answers.[/font] [color="#171E29"][font="Arial"]Moreover, I needed to find developers that are interested in the research, so I can give them my prototype solution for feedback and validation. My research is defined as a design research – my product isn’t just a summary of my findings. I try to use them in developing something – in this case, one of the things I am set on creating is a prioritization method that takes the creative vision into account (based on what I learn from interviews with developers, my survey and developer comments in forums) as well risk, cost, etc. (based on academic literature on requirements prioritization for software development).[/font] [color="#171E29"][font="Arial"]I find this research really interesting, because I am curious what developers think about all this. I’m really happy that there are academicians and [/font][color="#171E29"][font="Arial"]developers that are interested in this as well. Keeps my motivation high.[/font] [color="#171E29"][font="Arial"]First of all, requirements management has been defined as a problematic area in game development in numerous researches I have reviewed. But let’s go one by one, for the sake of clarity:[/font] [color="#171E29"][font="Arial"]Unreal or ambitious scope[/font][color="#171E29"][font="Arial"] – If there is a large pool of great ideas that will drown the project, one solution is to make sure it contains only the most important ones in there. A well-executed requirements prioritization can help.[/font] [color="#171E29"][font="Arial"]Feature creep[/font][color="#171E29"][font="Arial"] – Making sure all your requirements, including the new/”creep” requirements are vital to the project should lower the risk of the project going out of scope. I think (and am not alone) it is crucial to be able to tell when a feature, as expensive as another one, is important to the project. One way to do this, is by looking at the core/creative vision and see how important this feature is in relation. Available prioritization techniques can only estimate how risky or expensive a feature is and provide no adequate solutions to estimate how crucial it is to the game in development.[/font] [color="#171E29"][font="Arial"]Cutting features[/font][color="#171E29"][font="Arial"] – Focusing on the features that matter most should lower the chance of cutting features. A well executed requirements (feature) prioritization can be beneficial in this direction.[/font] [color="#171E29"][font="Arial"]Design problems[/font][color="#171E29"][font="Arial"] – this is quite a broad classification of problems, but it is easy to see how a good requirements prioritization can be beneficial. I hope.[/font] [color="#171E29"][font="Arial"]Delay or optimistic schedule[/font][color="#171E29"][font="Arial"] – mainly an organizational problem, but by making sure only the crucial features are focused on, delays should be reduced.[/font] [color="#171E29"][font="Arial"]I can talk about the rest of the problems as well, since there are some that could benefit from some good requirements prioritization, but I hope you see what I mean. I am in no way promising what I’m working on is the cure of all game development problems, or the “ultra-god-process-5000”, but I am at least focusing on relevant problems, as some [/font][color="#171E29"][font="Arial"]here [/font][color="#171E29"][font="Arial"]have agreed.[/font] [color="#171E29"][font="Arial"]Academic literature points at the need for brining solutions that have been helping traditional software into game development. I am not trying to validate that claim. I have seen solutions, and they are mostly aimed at dealing with user/customer related requirements – I spoke earlier about the outside-in (customers/user needs producing the requirements) vs. the inside-out (requirements based on the vision for the game) paradigm. I am looking into adapting relevant fragments from methods for traditional software development and combining that with the creative/entertainment value of requirements. (to repeat myself in the name of clarity, by creative/entertainment value of a requirement, I refer to the degree to which the creative/core vision relies on this particular requirement.)[/font] [color="#171E29"][font="Arial"]Maybe there are other ways to tackle these issues, but I have picked this path, and I didn’t pick it lightly. There are developers that agree the creative/core vision should be taken into account. There is my supervisor and professor from Software Product Management who supports my research as well. And last but not least, I think it's quite interesting Hope it's all good now.[/font]
  11. I agree. Moreover, I never said projects fail due to weak creative vision management. I am doing this research because as I said many times already, video games resemble film art (and other arts), where the creative/core vision needs to be shared by all stakeholders involved in the creation. It seemed logical this aspect needs to be reflected in the development of games as well. Many developers agree, academicians have encouraged my research, and some of the replies here agree as well. [color="#171E29"][font="Arial"]I am not trying to investigate why projects fail – there is academic literature on this and I have reviewed it (and I’m still reading more). The literature further motivates me to do this research, but since you repeatedly questioned my knowledge, I have nothing else left to do but to cite contemporary research on the topic: [/font] [color="#891917"][font="Arial"]Software[/font][color="#891917"][font="Arial"] Engineering Challenges inGame Development[/font] [color="#27500B"][font="Arial"]C M Kanode[/font][color="#535353"][font="Arial"], [/font][color="#27500B"][font="Arial"]H M Haddad [/font][color="#535353"][font="Arial"]in[/font] [color="#262626"][font="Arial"]Information Technology NewGenerations 2009 ITNG 09 Sixth International Conference on[/font] [color="#262626"][font="Arial"](2009)[/font] [color="#262626"][font="Arial"] [color="#171E29"][font="Arial"]Some highlights from Kanode and Haddad’s research:[/font] [color="#171E29"][font="Arial"]"A major issue leveled against the games industry is that most adopt a poor methodology for software creation. Petrillo et al. refers to data collected by the Standish Group. Only 16% of projects are actually completed on time and on budget. Clearly, there is a problem. Based on the statistics gathered by Petrillo et al. of completed games, the errors with the greatest occurrence (over the 50% mark) fall roughly under project management, requirements engineering, and risk management."[/font] [color="#171E29"][font="Arial"]First paragraph of the conclusion:[/font] [color="#171E29"][font="Arial"]"Game development has unique characteristics that represent challenges to this industry. Applying SE principles and sound practices can help overcome these challenges. Development companies must invest in adopting proven methods, found in traditional SE, to fit with the peculiarities of game development such as the management of multimedia assets and the need for game play exploration. Many issues in videogame development point to project management. Development companies need to invest in grooming skilled management through training (not only managing people, but teaching solid project management skills)."[/font] [color="#171E29"][font="Arial"]Note: As I said many times over, that’s exactly what I’m trying to do – study and adapt popular solutions. [/font] [/font] [font="Arial"][color="#262626"][color="#891917"][font="Arial"]Houston[/font][color="#891917"][font="Arial"], we have a problem...: A Survey of Actual Problems in Computer Games Development[/font] [color="#262626"][color="#27500B"][font="Arial"]Fabio Petrillo[/font][color="#535353"][font="Arial"], [/font][color="#27500B"][font="Arial"]Marcelo Pimenta[/font][color="#535353"][font="Arial"], [/font][color="#27500B"][font="Arial"]Francisco Trindade[/font][color="#535353"][font="Arial"], [/font][color="#27500B"][font="Arial"]Carlos Dietrich [/font][color="#535353"][font="Arial"]in[/font] [color="#262626"][font="Arial"]SAC2008 23rd Annual ACMSymposium on Applied Computing[/font] [color="#262626"][font="Arial"](2008)[/font][/font][font="Arial"][color="#262626"] [color="#262626"] [/font] [font="Arial"][color="#262626"][color="#171E29"][font="Arial"]Some highlights of Petrillo et al.’s research:[/font] [color="#262626"][color="#171E29"][font="Arial"]"When we analyze this results more closely, we see that the most cited problems were the unreal or ambitious scope and features creep with 75% (15 of 20) of projects reporting this problems. After that, demonstrating the coherence of the postmortems, 70% of projects citing the cutting features during development process. The other most found were problems in the design phase and delay or optimistic schedule, with 65%.Also the technological problems, with 60% can be highlighted. Figure 1 presents the histogram of occurrence of problems in sequence decreasing, in which we can make a graphical comparison ofthese results."[/font] Note: Find figure 1 at the bottom. [color="#262626"][color="#171E29"][font="Arial"]First paragraph of the conclusion:[/font] [color="#262626"][color="#171E29"][font="Arial"]"Our work shows that indeed all the main problems of traditional software industry are also found in the games industry, and it is possible to affirm that they are very related. In both contexts, for example, the unreal scope was pointed out as critical, as the problems with requirements definition. This contrasts with the one of so called universal problems of games industry, like crunch time, which had a relatively low occurrence rate, with 45% for crunch time. Theproblems with over budget and the loss of professionals have had the lowest incidence among all the problems analyzed, with an occurrence rate ofonly 25%. Budget problems have a considerable discrepancy, probably due to the greater emphasis in the technological and management aspects given by the stories authors, minimizing the financial aspects of the project. We can note similarities with respect to classification (same problems with same importance) and frequency of some problems, as schedule delays and requirement problems, having almost equal rates. Thus, one possible consequence of this similarity is obvious: solutions adopted successfully to traditional software industry to solve some problems can be also adopted by the games industry."[/font] [color="#262626"][color="#171E29"][font="Arial"]Note: the boldface highlights are done by the author.[/font][/font] [font="Arial"]A diagram from the research: [color="#171e29"] [color="#171E29"][font="Arial"]My research is relevant to the top 5 problems you see in the diagram. Make your own conclusions.[/font] [color="#171E29"][font="Arial"]If you still don’t believe in the necessity of my research, that’s fine, I’ll sleep just as well. However, don’t expect me to quit my research. There are people on both sides of this fence, and as an unbiased researcher, I hope to be able to reflect every aspect and view.[/font] [/font] P.S. If anyone needs the two publications, just e-mail/PM me, I'll gladly send them to you.
  12. You are saying everything is perfect now? [/quote] I can't help but feel like you're just being combative at this point, which is disappointing. I never said anything was "perfect." Just that we have good systems for producing creatively rich software. I also asked you a question, which you unfortunately did not answer. [/quote] At the moment of replying, emotion might have gotten the better of me, for which I apologize. I guess I was fighting with a one-man army here for too long. My rhetorical question was aimed at pointing out that there is always need for improvement. Pointing at successful projects and saying everything is OK is easy, however the truth is that more often than it should, projects fail. My research does not aim to replace the processes and practices already in use, but to complement them, without introducing significant overhead.
  13. So let's say you are the lead designer or producer of a game, whatever title but the point is that it's your job to decide prioritization. The game design you bought says "we need either feature A or feature B here". Feature A and feature B would cost about the same amount to implement. You don't have a personal preference between the two. How do you decide? You have to decide because otherwise it's a stumbling block for your own personal work efficiency and the whole project. I think you need to have some overall strategy or rule of thumb for making this kind of decision. [/quote] Indeed. I'm sure there are also other cases when you might need such a solution - it shouldn't be complex, on the contrary it needs to be straight forward and easy to apply, not burdening the whole process, but helping it.
  14. I'm not convinced you've read what has been said until now. And it was a lot. I never made such claims. Nor are any of my intentions even close to what you suggest.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!