Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Best Practices in Game Development

Lecture for Intro to Game Dev.
by

Ben Smith

on 26 February 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Best Practices in Game Development

But is it Fun? Testing Iterative Development Best Practices
in
Game Development Goal: reduce as much risk as early as possible. Hard Code Values Critical to good game dev in Unity. Managing Change Clairvoyance: not part of the job description. Requirements Management Own your requirements. Reuse Never write the same code 2x. Q: How do you know your game is fun to play? Is our game going to be successful? If not, we want to: change it, or bail. A: play it! Accept New Task Understand Requirements Design Architecture Implement Test & Integrate Iterate on: The Engine The Game The Design Doc Hyper-productive Development Q: What makes a company/team/developer "hyper-productive"? Notion of "Best Practices." i.e. making lots of cool s#!7 Evaluation of priorities. Design evolves along with the understanding of the problem space! ?? other?? • Have a working game at the end of every iteration. • Level of abstraction decreases over time. Start with blocks, bang out core rules! User-testing from day 2! Advantages Enables Evaluation at any moment! stable, functional • Development ends at optimal point, i.e. when the game is done! is it good enough? @ Evaluation identifying design/development priorities 90% of potential problems never appear. Don't waste resources on them! Address issues as they arise (the actual 10%) Speculate efficiently, or not at all! Build extensible, thorough code, on a one-day cycle.
Addressing imaginary issues is never an excuse for missing a deadline. Editing code is fun!! Hyper-productivity necessitates writing sufficient code the first time. Hyper-productive = (creation date == modification date); Enables IDE configuration of rules, mechanics. fast! collaborative! and expensive. Examples Motivating! You want to solve the right problems. Delivering a product that the consumer (player) doesn't like, doesn't play, doesn't buy, is an requirement identification is
completed in a separate pre-implementation phase. You make the game, you identify the requirements! Q: ever shop for someone else? successfully? Need agile identification. Q: When is it appropriate to hard-code a value? A: never.* * - don't hurt yourself in trivial cases. pow(x, 3) 1 / distance for (i = 0; i ... The Iterative Design Document:
Vision Vision Doc answers: • what feelings should the game
convey to the player? • what is the game about? • what does the player actually do most of the time? • why is the player doing these things? • what is the surrounding game universe? Vision Doc: Quality Req. Vision doc should include quality requirements at the outset (but may be revised). Technical, performance quality Fun quality, replayability, player's feelings... Audience, play-style requirements. Change: Lead Designer's fault? They didn't think it through? Producer's fault? Whims of the marketplace? Lead Developer's fault? Changing system requirements? It causes rewrites: it's bad. Right? Good Bad • Costly: time & money. esp. if implementation has a lot of inertia • Makes a better game. • Ideally leads to
more fun! • In "traditional"
paradigm is very hard. We are software designers/developers/engineers. Maxims Change is worth it if it leads to greater success! The greater the success outlook, the greater the amount of change that is acceptable. Code that has outlived it's usefulness needs to be archived (deleted??). Yes, we all love our babies :( Iterative Development is agile, affording maximal change! O-O at its best. Reusable code:
easier to manage,
more efficient code base,
extensible,
and it's cool! How do we design for reuse during iterative development? Games always want special cases! (recall O-O vs. C-B) (renderable, moveable, and chewable??) + s#!7 changes, yo. Reuse is Discovered not designed. When you find yourself writing the same code again,
then: extract, abstract, inherit, and create libraries. Don't speculate on requirements for reuse. don't waste time on the 90%! Be Pragmatic in Reuse Is the old-code being maintained? No: copy and refactor. Yes: abstract and inherit. • Iterative Development leverages advantages of Component-based architecture. Q: Why do we want to be hyper-productive? A? 1) Given the same deadlines, we have time for more design/development: more features, better game. 2) Have time for Life. Components with multiple behaviors! Reuse: Parametrization leads to: To address readability concerns: comment the line with the variable values. Dangers of Iterative Dev. Finding Local Optima Introducing a change may seem good now, but ultimately prevent discovery of the global optimum. Repeating Mistakes of the Past Rapid iterations = weak development memory? Important to maintain a change log/history. Enables quick ID of "mistakes" and minimizes repetition of past errors. Importance of continual Evaluation cannot be overemphasized!! Becomes a significant task as project grows. Take advantage of automated testing tools! In pro team is the responsibility of specialized Q.A. team. Only way to develop requirements and changes. –RELEASE– but "If it's pink, make it a variable/constant!" Traditional Usually by the Lead Designer. The "grocery list" of requirements. High potential to misunderstand,
ignore, or mis-prioritize requirements. i.e. Design Doc Bottom Line: Include: change, the: We don't know what tomorrow may hold. Include reasoning: why the change? + the result. F Design Doc
Full transcript