Category:Design Theory
From Jumpgate Evolution Wiki
NetDevil practices a Scrum Methodology. Essentially, it is the practice of breaking things into 15-30 day chunks and not moving until each chunk sparkles. The rest of the detail in this document stems from that basic theory. If you peruse NetDevil's profile on LinkedIn you will find Scrum Masters listed.
Contents |
[edit] Introduction
In several interviews, Scott "Scorch" Brown (NetDevil CEO) and Hermann Peterscheck (Lead Producer, Jumpgate Evolution) have discussed their design theory. NetDevil is the only company in the world working on their second space sim and, as such, they have a wizened perspective on how to develop a fun game. At the core of this philosophy are a few main ideas:
- Create, play test, and repeat until it's right (see Iterative Design)
- Above all else, the game should be fun to play.
- "There is no excuse for the game to be hard to understand or difficult to pick up. We think by being smart about when we introduce features to the player we can give a compelling first user experience that will keep players hooked for a long time."[1]
-- Scott "Scorch" Brown
- "There is no excuse for the game to be hard to understand or difficult to pick up. We think by being smart about when we introduce features to the player we can give a compelling first user experience that will keep players hooked for a long time."[1]
- Get the basics right from day one. The essentials have to be as close to perfect as possible. Everything else flows from them.
- "What stood out to us about a game like WoW is how even in the early beta the game ran great on any computer we could find ... You should be running at a high frame rate, and your servers should be up 99.999% of the time from as close to day one of development as possible. Everything feature you add is not done until the servers are back stable again and the frame rate is high."[1]
-- Scott "Scorch" Brown
- "What stood out to us about a game like WoW is how even in the early beta the game ran great on any computer we could find ... You should be running at a high frame rate, and your servers should be up 99.999% of the time from as close to day one of development as possible. Everything feature you add is not done until the servers are back stable again and the frame rate is high."[1]
"The [four] "coolest" features: capital ships, battlestations (bases), asteroid interiors, and space "terrain" (for lack of a better word) were not in design docs or seriously planned (though cap ships and battlestations were fantasized about."[2]
-- Hermann "Draker" Peterscheck
[edit] Characteristics of Scrum
During each sprint, a 15-30 day period (length decided by the team), the team creates an increment of potentially shippable (usable) software. The set of features that go into each sprint come from the product backlog, which is a prioritized set of high level requirements of work to be done. Which backlog items go into the sprint is determined during the sprint planning meeting. During this meeting the Product Owner informs the team of the items in the product backlog that he wants completed. The team then determines how much of this they can commit to complete during the next sprint.[1] During the sprint, no one is able to change the sprint backlog, which means that the requirements are frozen for a sprint.
Scrum enables the creation of self-organizing teams by encouraging co-location of all team members, and verbal communication across all team members and disciplines that are involved in the project.
A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach – accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team's ability to deliver quickly and respond to emerging requirements.
There are several implementations of systems for managing the Scrum process which range from yellow stickers and white-boards to software packages. One of Scrum's biggest advantages is that it is very easy to learn and requires little effort to start using.
--From the Wikipedia entry on Scrum[3]
[edit] Iterative Design
Iterative design refers to the cycle of re-designing a feature or mechanic as many times as is required – from the ground up if necessary – for players to have fun with the game.
-
it·er·a·tion[4] - noun:
- 1. the act of repeating; a repetition.
- 2. (Mathematics). a. Also called 'successive approximation'. A problem-solving or computational method in which a succession of approximations, each building on the one preceding, is used to achieve a desired degree of accuracy.
- Based on developer comments, it took fifty or sixty iterations to simply achieve basic flight to where people could control the ship and fire at enemies in the first mission.
- The programmer in charge of camera motion reconfigured the control scheme "four or five times from scratch" to get the movement correct.
- "Yes... that's right... 2 months+ of pure hell testing basic flight and combat."[5]
-- Hermann "Draker" Peterscheck
[edit] Skills vs Stats
Above all else, JGE is a game of skill. This means it is heavily reliant on "twitch-based" gameplay (but not inaccessible).
- JGE will not have an action bar.
- JGE will not have cooldowns.
- JGE will have constant and predictable damage, provided you hit your target (or in the case of larger ships, hit the right parts of your target).
- Ordnance have a set amount of damage. Shields and armor have a set durability. Provided the ordnance strikes the target, the outcome is not the least bit random.
"I LOVE skills and skill trees but not in my action games. I'm not sure people want the experience of flying through space in an asteroid field during a complex dogfight and then having to look at the bottom of the screen to see in how many seconds their shield booster will run out... then take their hands off their joystick (or mouse and keyboard) to press "1" only to find out that CRAP! their energy weapon boost is about to expire so now they have to hit "2" and BOOM they are flying into the wall of the asteroid..." [5]
-- Hermann "Draker" Peterscheck
There are no attributes that would add/change damage and level is simply something that unlocks more equipment to you. If a gun does 6 damage it always does 6 damage no matter who is pulling the trigger.[6]
-- Scott "Scorch" Brown
[edit] What Makes a Successful MMO?
There have been some rather telling quotes from Scorch and Hermann regarding what makes or breaks the success of an MMO. Here are a few:
"A lot of what makes companies like Valve, Bungie and Blizzard succeed (in my opinion) is not the bottomless checkbook (although that helps) it's that they dedicate themselves to quality from the beginning. They focus on core stuff and get that done before they move on."[7]
-- Hermann "Draker" Peterscheck
"Let's say you have $20 million and you decide to put $12 million up to create a game. It reaches the end of it's budget and it doesn't seem like it's quite ready. You now have the choice of spending the rest of your money and going for broke (literally), or... you can push out what you have hoping you can recoup some or all and live to try again. THIS is exactly what happens to most games." [7]
-- Hermann "Draker" Peterscheck
"If you want to know if your game is good you have to test it on people who will at the end of the day be your customers. Period. There are no short cuts. There are no easy alternates. From what I can see there is actually no other way at all. It's implement->test->fix->modify. Do that about 10,000 times and you release" [2]
-- Hermann "Draker" Peterscheck
[edit] Visual Design
"In terms of visual style, we decided early on that we were going to go away from the traditional "space is dark and empty" kind of look. While space is, in fact, dark and empty, that makes for a fairly limited visual experience, and one of the nice things about making games is that you can define reality however you like. We wanted a look people would respond to emotionally, where they get a sense that this is a world they want to live in and explore.
What we want is to have meaningful size. We are doing a lot of work on making sure that different areas look very different so players will want to explore all the various sectors.
Specifically, this means we went for a deep, saturated, high-contrast kind of look. Another reason to do this is that it is easier to make a game look good on lower end machines when you have this kind of a look than if you go hyper-realistic. I'm not sure if there is anything necessarily distinctive about the style, but the game certainly looks really good which is the main goal we wanted to achieve." [8]
-- Hermann "Draker" Peterscheck
[edit] Sources
- ↑ 1.0 1.1 Scott "Scorch" Brown, President - NetDevil, Corpnews.com Interview - August 24, 2007
- ↑ 2.0 2.1 Hermann "Draker" Peterscheck, Producer, Codemasters Forums - September 5, 2008
- ↑ Wikipedia - Scrum Development
- ↑ Dictionary.com - Definition of iteration
- ↑ 5.0 5.1 Hermann "Draker" Peterscheck, Producer, Codemasters Forums - September 5, 2008
- ↑ Scott "Scorch" Brown (President, NetDevil), NetDevil Forums - December 24, 2007
- ↑ 7.0 7.1 Hermann "Draker" Peterscheck, Producer, Codemasters Forums - September 7, 2008
- ↑ Hermann "Draker" Peterscheck, Producer, RPG Vault JGE Interview (Part One), Page 3 - January 07, 2008
This category currently contains no pages or media.
