Friday, December 24, 2010
I started reading a new book by the folks @ The Big Nerd Ranch and I have to say I'm enjoying it.
You need to be comfortable with C in order to get much out of it. But, if that's the case, you're up and coding in the first chapter! I had a simple quiz app built and on my iPhone after reading 20 pages.
Tuesday, December 14, 2010
Wednesday, November 10, 2010
I generate shards of a source image by recursively branching over-top it, after which, I create a mask out of the voided space and then copy the source bitmapData to those voids.
Very convincing effect!
Go here to see the prototype. Click the sprite to see the effect.
You'll need to click on the sprite to shatter it :)
Friday, November 5, 2010
Tuesday, November 2, 2010
So, I'm working on this game and they were using a super cheesy decal system to depict bullet impacts on NPCs. I came up with this app as a test to see what a pixel blood particle sys could look like:
[Instructions: Produce a projectile by clicking anywhere on the left half of the screen. If the projectile comes in contact with the sprite, a particle emitter will be placed at the point of impact.]
Try It Out Here!
I did a couple more passes of optimization for what went into production but, regardless, I'm still happy with this test. You'll see roughly 150 particles moving about at 50 FPS, not bad.
Saturday, October 30, 2010
I'm not sure what you'll use this for but, in case you needed one, here's a Sierpinski Carpet class!
Impress your friends with stylish images such as this!
default app file (SierpinskiCarpet.as)
Tuesday, September 21, 2010
This post will be no exception... However, here are two links that, when used together, will make for some interesting reading and experimentation:
Friday, August 27, 2010
Tuesday, July 20, 2010
Monday, July 12, 2010
Click anywhere to start them animating and click again to reset:
Wednesday, July 7, 2010
I'm definitely going to try a test project. The games on kesiev's site run very well. My initial criticism of building games in HTML5 was that all of the prototypes that I had seen prior were slow and jittery. These games, however, are far from that.
Monday, June 28, 2010
It's a neat addition to the adobe text toolset. You'll have to require the 10 player but in return you get the following:
- Additional character styles, including leading, ligatures, highlight color, underline, strikethrough, case, digit case, and more.
- Additional paragraph styles, including multi-column support with gutter width, last line justification options, margins, indents, paragraph spacing, and container padding values.
- Control of additional Asian text attributes, including Tate Chu Yoko, Mojikumi, Kinsoku Shori Type, and Leading model.
- You can apply attributes such as 3D Rotation, Color Effects, and Blend Modes to TLF text without placing it in a movie clip symbol.
- Text can flow across multiple text containers. These containers are called threaded or linked text containers.
- The ability to create right-to-left text for Arabic and Hebrew scripts.
- Support for bi-directional text, where right-to-left text can contain elements of left-to-right text. This is important for embedding English words or Arabic numerals within Arabic/Hebrew text, for example.
Wednesday, June 23, 2010
Sunday, June 13, 2010
Saturday, June 5, 2010
Thursday, May 27, 2010
Thought I'd share a cool passage from Dr. Brooks regarding creativity and the joy of development:
"First is the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design. I think this delight must be an image of God's delight in making things, a delight shown in the distinctness and newness of each leaf and each snowflake.
Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and to find it helpful." [Brooks 1986]
This really resonates with me. I suppose it's what gets me out of bed each morning. There is something incredibly exciting about producing new and useful applications.
I've always said that creativity and godliness go hand in hand. Does that make me a megalomaniac? At times I do like to burn the midnight oil a bit too much. But damn it all if it isn't rewarding!
For instance: Take www.gogolingo.com. I allowed this project to wreck havoc on my life. During its production, I hardly slept, I barely socialized, I squeezed every last ounce of energy out my body and I loved it. For all my troubles, I have a shiny sparkling experience to share with the world and that's somehow worth what seemed like pain at the time.
I've gotten side tracked but the point should ring true. Dr. Brooks is spot on with his observation that creation is very rewarding.
Wednesday, May 26, 2010
Tuesday, May 25, 2010
I think I will always enjoy books put out by O'Reilly. The Art of Agile Development is no exception. This book was thought provoking and fun. The authors, of which there were two, tried many different ways of transferring their knowledge. I really respect their use of narrative style; it keeps you guessing (there is role playing be forewarned!). The book is a nice overview of agile philosophies (most heavily in favor of XP) and makes no claim that it is the de facto. They even go so far as to stress that you are invited to break the rules that the book lays out -- Explaining that an agile developer is one that asks the question why and that they will forever pursue mastery. I had a couple of "ah ha!" moments thanks to these guys (James Shore & Shane Warden). Thanks gents!
I have no intention of writing a full review but I will say that this is a great book for whetting your appetite for agile techniques. It's also filled with a wealth of references to further study.
They open up a section on Simple Design with:
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. -- Antoine de Saint-Exupéry
Truly brilliant and a fantastic parallel to the topic! Love it!
I like the way they described TDD:
"Imagine TDD as a small, fast-spinning motor. It operates in a very short cycle that repeats over and over again. Every few minutes, this cycle ratchets your code forward a notch, providing code that -- although it may not be finished -- has been tested, designed, coded and is ready to check in."
If this sort of explanation is up your alley, then give the book a try, as it's what you can expect.
Lastly, I really appreciate that they pour in personal "in the trenches" examples. These help solidify the relevance of the various concepts.
Saturday, May 22, 2010
Friday, May 21, 2010
- It talks to a database
- It communicates across a network
- It touches the file system
- You have to do special things to your environment (such as editing config files) to run it
Tests that do these things are integration tests, not unit tests. [Shore & Warden 2007]
Thursday, May 20, 2010
I was about to save this link on delicious but then realized that it's useful to more than just myself and, therefore, please enjoy! It'll be interesting to see if Google actually nourishes the selection, as currently it's sparse at best. These fonts are widely supported by most browsers (so says Goog) but, remember, widely does not mean ubiquitously supported ;)
Typically, I use http://www.dafont.com/ for all my fancy typographical needs.
Wednesday, May 19, 2010
Tuesday, May 18, 2010
"Test-driven design (TDD) is a development technique where you must first write a test that fails before you write new functional code.[...]TDD does not replace traditional testing, instead it defines a proven way to ensure effective unit testing. A side effect of TDD is that the resulting tests are working examples for invoking the code, thereby providing a working specification for the code. - Ambler"
Scott Ambler has a thorough article on Test-Driven Development that explains the methodology. If you're curious on the subject, I recommend reading it:
Friday, May 14, 2010
Because the brain cannot fully focus when multitasking, people take longer to complete tasks and are predisposed to error. When people attempt to complete many tasks at one time, “or [alternate] rapidly between them, errors go way up and it takes far longer—often double the time or more—to get the jobs done than if they were done sequentially,” states Meyer . This is largely because “the brain is compelled to restart and refocus” . A study by Meyer and David Kieras found that in the interim between each exchange, the brain makes no progress whatsoever. Therefore, multitasking people not only perform each task less suitably, but lose time in the process. [wikipedia]
For me, I multitask when I'm bored. Typically, I find myself losing interest in the task at hand so I jump to another task on my list. Then I feel guilty for orphaning what I had been working on so I'll jump back.
More Wikipedia you say? You got it!
When presented with much information, the brain is forced to pause and refocus continuously as one switches between tasks . Realistically, this is “a rapid toggling among tasks rather than simultaneous processing.” According to a study done by Jordan Grafman, chief of the cognitive neuroscience section at the National Institute of Neurological Disorders and Stroke, “the most anterior part [of the brain] allows [a person] to leave something when it’s incomplete and return to the same place and continue from there,” while Broadman’s Area 10, a part of the brain’s frontal lobes, is important for establishing and attaining long term goals . Focusing on multiple dissimilar tasks at once forces the brain to process all activity in its anterior. Though the brain is complex and can perform a myriad of tasks, it cannot multitask well. [wikipedia]
Last year there was an article in the Standford paper dealing with the topic of multitasking. As you could expect, the outlook was grim for those that boast about being able to - well you know.
"By doing less, you might accomplish more."
That's the final quote of the article. It's certainly true of agile development. We break production into manageable chunks and then we execute on them. If you find that you're jumping around too often, stop. It's not worth it. Perhaps it's time to engage in some Root-Cause Analysis to figure out what your motivation is for this disruptive habit.
I'll leave it at this. Here's an interview with the guy responsible for the Standford study.
Are you in need of a flowchart? You've come to the right place. As you may know, I strongly oppose downloadable executables! Web 2.0 all the way baby! Sadly, I've yet to incorporate a 2.0 solution in my work flow.
That said, if you need to download and install something... The industry standard is Visio. Another valid solution is SmartDraw.
Here's a list of 2.0 solutions that I've yet to sample:
I got that this from this guy.
I've also used www.bubbl.us to mind map. -- It was fun but buggy.
We are all responsible for high quality code. There is a metric for imposed risk by concentrating knowledge in just a few people's heads -- it's called the truck number. How many people can get hit by a truck before the project suffers irreparable harm? [Shore & Warden 2007]
Some developers consider this job security and, if you're in a company or state of mind where this is your sentiment, I sympathize with you. But it shouldn't be the case!
I often tell my clients that I only hire people that love what they do. My belief is that if you love what you do then your exuberance will be infectious and thus pollute the groundwater. You simply spend too many hours of your life "working" so why be unhappy while doing it? Honestly, if you can't stand your job, then you need to take action. That said...
As a team, we can't operate at 100% efficiency when we do not have redundancy. Things come up... Folks get sick, have emergencies, retire, go on vacations, you get the picture. Your project should not suffer when a team member can't make the game.
The concept of Collective Code Ownership (CCO) extends to all areas of development. When only one developer knows how to tweak the installer, it's time to refactor or educate.
CCO also applies to bug fixes... I know that I personally don't enjoy rooting around through broken code, especially when it's not my own! However, it's different when you weave it into your company culture. I subscribe to the old boyscout motto: Try and leave this world better than you found it.
Ideally, we don't have bugs because we're using TDD. But, let's be honest, we don't live in an ideal world and mistakes happen. I know that some of you would accuse me of rose color glasses syndrome but I assure you that this is not just Utopian dribble. It really works. That said, if you spend more than 15 minutes digging around and can't find the problem, it's probably time to rollback to the last working build.
[With CCO] No one person can be the bottleneck for change. [extremeprogramming.org]
Collective code ownership requires letting go of a little bit of ego. Rather than taking pride in your code, take pride in your team's code. [Shore & Warden 2007]
CCO is a tool. If it doesn't work for you, don't use it. My vote, always evolve. Don't scoff at a good idea because you'll never know if you don't at least try.
Thursday, May 13, 2010
Wednesday, May 12, 2010
- Tested (all unit, integration, & customer tests finished)
- Coded (all code written)
- Designed (code refactored to the team's satisfaction)
- Integrated (the story works from end to end - typically, UI to database - and fits into the rest of the software)
- Builds (the build scripts include any new modules)
- Installs (the build script includes the story in the automated installer)
- Migrates (the build script updated database schema if necessary; the installer migrates data when appropriate)
- Reviewed (customers have reviewed the story and confirmed that it meets their expectations)
- Fixed (all known bugs have been fixed or scheduled as their own stories)
- Accepted (customers agree that the story is finished)
Can you run down this checklist at the close of an iteration and be certain that you've satisfied each bullet? If not, it's time to knock off a couple of the stories that you've committed to and focus on doing it right the first time.
Thursday, May 6, 2010
Never underestimate that a small group of thoughtful, committed people can change the world, indeed it's the only thing that ever has.
- Margaret Mead
Margaret didn't know it at the time but she was a huge advocate for Scrum!
Wednesday, May 5, 2010
"We do not always know what we want deep down." - Gladwell
Why is it the best quote? Because it's true! I can tell you that from conducting many formal and informal market research groups that consumers aren't a wealth of great ideas. However, this is not to say that such research is not useful. It's important to try new things. Experimentation breeds new products.
In his talk, Gladwell presses that diversity is important in product creation.
"...in embracing the diversity of human beings, we will find a sure way to true happiness." - Gladwell
Have a look for yourself. It's a fun watch :)
Tuesday, May 4, 2010
I got the chance to sit down with Dr. Jeff Sutherland last week. What an honor! It was at an event put on by Digital LA.
At the event, Jeff went over the basics of Scrum and some general insights.
Among his many pearls of wisdom - I enjoyed that he reminded us of the MIT slogan "Demo or Die". It's so important to show progress. Although apparently MIT changed that mantra to imagine and realise in the 90s.
It was perfect timing, as I gave my first lecture on Scrum that very weekend.
My lecture btw, went off without a hitch. I entitled it Scrum 101. Here's a look at the syllabus:
- A brief history of Scrum and its significance
- A functional understanding of the framework
- Basic instruction on implementing Scrum in your next small team project
I was able to cover my material in an hour and 15 minutes. However, I think I'll plan on a two hour timebox in the future. After the material was covered, we had a Q&A session that lasted for an additional hour.
Thursday, April 29, 2010
I think a lot of what Jobs said was true. However, I still believe that it's in their best interest exclude Flash for monetary/control reasons.
His conclusion is strong though - If flash wants to play on their devices, they should build tools for HTML5, it's only logical.
Steve Job's on Apple's lack of support for Flash
Wednesday, April 28, 2010
Here's a link to a PDF that shares some of the slides in the presentation:
One interesting tidbit, Jeff asked...
Are you properly doing Scrum? He then referenced the Nokia Test as the benchmark.
Here's the Nokia Test by Bas Vodde
• Are you doing iterative development?
– Sprints must be time boxed to four weeks or less
– Software features must be tested and working at
the end of an iteration
– Sprints must start with an Agile specification
• Only 50% of Scrum teams worldwide meet these
• Do you know who the product owner is?
• Is there a product backlog prioritized by business value that has
estimates created by the team?
• Does the team generate burndown charts and know their
• Is the team’s work free from disruption by project managers (or
Tuesday, April 27, 2010
Here one of the cool slides that he goes over.
It explains really well how companies function. I know that I've worked for more than one autocratic organization!
Monday, April 26, 2010
Friday, April 23, 2010
"Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite." - Ward Cunningham
It was met with some controversy. A friend of mine responded with:
"In my experience rewrites almost never happen, and are often constrained by architecture decisions when they do. So I try to do it right the first time."
I had to jump on it... Here's my reply:
"I agree that it's hard to incorporate them if the company culture opposes it. Everyone should strives to do it right the first time but with iteration comes new information. That information can, and most likely will, lead to a better product. Typically, the reason rewrites don't happen is that they're not supported by institution/stakeholders for fear of wasted time. What they fail to see in not supporting refactoring is actually inevitably wasted by trudging on. In my opinion, that's where the problem lies. If refactoring is built into the development cycle, then it will happen. I'm not a fan of rework for the sake of rework but I do think that it's worth reinvesting in code when it's going to be augmented often.
If you're 100% happy with the work that you've done after it's been committed then, by all means, move on. However, when you know that it can be done better based on any new information accumulated through user tests, general experience, or a peer review, why not fix it then rather than allowing bulk or unwieldy code to accumulate?"
Here's a good Cunningham quote from 1992 at OOPSLA:
"Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite." - Ward Cunningham
Thursday, April 22, 2010
Here's a class that he taught about teaching that certainly backs that up:
This is a really sensitive issue for him. He actually gets choked up at the close 5 of 7.
part 1 of 7
part 2 of 7
part 3 of 7
part 4a of 7
part 4b of 7
part 5 of 7
part 6 of 7
part 7 of 7
Wednesday, April 21, 2010
Ken Schwaber is a software developer, product manager and industry consultant. Ken worked with Jeff Sutherland to formulate the initial versions of Scrum development process.
Monday, April 19, 2010
A definition of User Stories
A user story is a software system requirement formulated as one or more sentences in the everyday or business language of the user. User stories are used with Agile software development methodologies for the specification of requirements (together with acceptance tests). Each user story is limited, so it fits on a small paper note card—usually a 3×5 inches card—to ensure that it does not grow too large. The user stories should be written by the customers for a software project and are their main instrument to influence the development of the software. - Wikipedia
In Succeeding with Agile, Cohn defines User Stories as such:
A user story is a short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. (p238)
How to write a User Story
Here's a great blog from Cohn on his primary User Story template and here's the template that I use care of Cohn's suggestion:
As a <type of user>, I want <some goal> so that <some reason>.
In this template, we select and cater to three important pieces which are user role (type of user), the feature (some goal), and the value statement (some reason).
The user role helps ground the User Story by giving it relevance. The feature is obviously important because it is what we're building and, finally, the value statement justifies why we're bothering with the development in the first place.
Are there alternatives to using the As/a template or User Stories in general?
There's never one single way to solve a problem. Personally, I enjoy the As/a template because of its simplicity. Regardless, here are some other techniques that I've run across. Research as you like...
Feature-Driven Development (FDD) - Features
A feature is a small, client-valued function expressed in the form <action><result><object>. As the name implies, features are an important aspect of Feature-Driven Development (FDD) (Palmer and Felsing 2002).
Unified Modeling Language (UML) - Use Case Modeling
A use case in software engineering and systems engineering is a description of a system’s behavior as it responds to a request that originates from outside of that system. In other words, a use case describes "who" can do "what" with the system in question. The use case technique is used to capture a system's behavioral requirements by detailing scenario-driven threads through the functional requirements. - Wikipedia
Friday, April 16, 2010
As some of you know, I've been reading Succeeding with Agile by Mike Cohn. After going cover to cover, I'd recommend it to anyone that has a decent familiarity with Agile. This is not a book for those fresh to iterative development. It's certainly inspired more than a few of my recent posts!
Next on my reading list:
First of all, here's a quick video primer on scrum...
Now then, a lot of folks advocate for desks on wheels. This allows for dynamic configurations. Scrum is all about communication and team problem solving. Each Sprint will require that different team members work together.
Open Space - There are no tall cubical walls. The traditional cubic-caves defeat the purpose of the open space concept. Scrum floor plans can be described as war rooms. Important, avoid separating disciplines. We are cross functional teams and need to be able to communicate on the fly. The Scrum framework suggests that team members of all disciplines sit together.
Active wall utilization - As developers, we spend so much time in front of illuminated screens. Here's a shot of what Mike Cohn recommends as a typical Scrum board layout:
The layout of your board is up to you. Add what you need, as there are no rules. The image above is one configuration. You can experiment around to find what information is more useful to you. Post up the product backlog, issue backlog, your burndown chart, you get the picture. The goal is to own the space. Of interest, the scrum board concept comes from Kanban so read up on that for more background.
We're all equal in Scrum... You should avoid having coveted locations. You succeed in office configuration if there isn't a bad seat in the house.
Sanctuary - when at all possible, have someplace to retreat for quite time. This could be a space to clear your head, take a private call or meeting.
Saturday, April 10, 2010
When coordinating work among several SCRUM teams, it is beneficial to hold SCRUM of SCRUMs meetings. These meetings differ from standard daily SCRUMs in that they are not timeblocked to 15 minutes. They allow groups of teams to discuss issues that pertain and focus on areas of overlap and integration. Such issues can, if not regularly settled, compound and critically hamper production.
When selecting who should attend from each team, it's best to choose a technical contributor (programmer, tester, designer) rather than the Product Owner or ScrumMaster. Your attendee can vary from meeting to meeting. Select the attending member based on who is best suited and knowledgeable about the state of the current sprint. The goal of the meeting is, as was previously mentioned, to remove barriers and efficiently sooth issues that arise from cross-team-dependencies.
Mike Cohn describes the differences of SCRUM of SCRUMs and daily SCRUMs as:
- They do not need to be held daily
- The do not need to be timeboxed to 15 minutes
- The are problem-solving meetings
Hosting a SCRUM of SCRUMs meeting
First off, you should only host 2 to 3 meetings a week. If you find that you need more, then you should analyze your sprint planning process.
Meetings should allow for each attending member to have 15 minutes to go over the following three questions:
1) What has my team done since we last met that could affect other teams?
2) What will my team do before we meet again that could affect other teams?
3) What problems is my team having with which it could use help from other teams?
After each member has had the floor, the focus should switch to any pending issues on the issues backlog.
Friday, April 9, 2010
Thursday, April 8, 2010
Blender is a 3D graphics application released as free software under the GNU General Public License.
It can be used for modeling, UV unwrapping, texturing, rigging, water simulations, skinning, animating, rendering, particle and other simulations, non-linear editing, compositing, and creating interactive 3D applications, including games.
Applying a texture to a cube in Blender tutorial
1) Assuming that you've installed it, open the program.
2) In the top menu select ADD -> Mesh -> Cube.
3) We need to open the UV/Image Editor. Let's do this in the bottom panel.
4) We'll need to find an image to use as our texture. Select "Open" and find the image that you would like to use. This image should, of course, be located on your harddrive.
Here's the image that I selected...
5) Be sure that you're in Edit Mode
6) Click on the Mesh button and select UV Unwrap
7) Select Unwrap
8) Marvel at your brilliance
Here's a great overview of the Blender UI... Happy Blending!
Friday, April 2, 2010
I'll start off by saying that I'm all about the Fibonacci Sequence and that we'll touch on this in my conclusion. That said, your task as a designer is to pick the optimum distance between levels to maintain interest while balancing difficulty. To do this, you'll also require something to track progress. Let's call this Experience Points (EXP)! Let's mark a definition then shall we...
What is Character Leveling?
Character leveling refers to a goal & reward model that tracks player achievement through a scaffold of goals. These goals are achieved by a player via accumulating some metric representation of their experience, such as Experience Points.
The concept of leveling has been around since tabletop games (see: Dungeons and Dragons). Whether we're aware of it or not, video game designers borrow heavily from the oak & paper artisans. Admittedly, I'm no master of tabletop gaming but I can definitely see the parallels.
Here's an example, that I found randomly on the net, from Dungeons and Dragons (D&D) that demonstrates a leveling system for Wizards.
Let's analyze the distance used to describe levels...
Level 1 -> Level 2 is a difference of 2,500 EXP
Level 2 -> Level 3 is also a difference of 2,500 EXP
Level 3 -> Level 4 is 2x that of the former or a difference of 5,000 EXP
A pattern has emerged! We're doubling the prior level to create the distance to the sequent. However, something funky happens when we get to the sixth level...
Level 5 -> Level 6 is a difference of 15,000 EXP... this is only 25% more than the former and, thus, breaks the pattern that was set out before. Why?
First, let's ask the question...
Why bother with levels?
"The answer is that levels provide goals. They give players something to shoot for, so that their actions have more purpose. They give players a sense that their achievements do have effects. Levels use a step function because players like to feel they have taken a step." (Richard A. Bartle, 2003)
Bartle shows us that the primary goal of leveling is to get the player to vest psychologically in our game. If D&D maintained a 2x build for their leveling curve, a player would need 640,000 EXP to reach level 10 verses the 200,000 EXP that D&D settled upon. This was no accident. Dungeons and Dragons was/is a multimillion dollar franchise because of its addicting play mechanics. These mechanics were no doubt uncovered via playtesting.
Playtesting is the key to balancing your game. There is absolutely no way that you'll come up with the perfect balance out the gate. You must bring your game to the lab and attempt to break it. This is why Agile development is superior to the waterfall model but that's a story for another day.
Goals & Rewards Concept - Designers don't need to step through levels. We could just base our fame hierarchy or content restrictions on the number of EXP accumulated. Designers could also design boring games... "Step Function" as Bartle describes it, aids in building anticipation.
Risk & Reward
This applies more to the obstacles that the player encounters throughout their pursuit to reach their particular goals in your game and is, therefore, outside the scope of this entry. Suffice it to say that offering multiple avenues for players to speed up their avatar's achievement-growth makes for more interesting play patterns and will, in the end, make your game more appealing.
As promised! I've just always been a fan of this pattern.
1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, ...
This is an example of a recursive sequence, obeying the simple rule that to calculate the next term one simply sums the preceding two:
F(1) = 1
F(2) = 1
F(n) = F(n – 1) + F(n – 2)
Thus 1 and 1 are 2, 1 and 2 are 3, 2 and 3 are 5, and so on.
This simple, seemingly unremarkable recursive sequence has fascinated mathematicians for centuries. Its properties illuminate an array of surprising topics, from the aesthetic doctrines of the ancient Greeks to the growth patterns of plants (not to mention populations of rabbits!).
I love it for scarcity algorithms especially. But, you could also apply it to an avatar level model. A lot of games, like say Ashron's Call, will use a slowing curve to fit more levels into the upper range of a leveling system (see: Designing Virtual Worlds, p354). You'll want this if you base your model on this sequence.
All this talk of levels without much discussion over the means to the end... Let's ponder Experience Points. EXP are the currency that buy players levels. There are tons of ways to award them.
Time on Site/App - Here's a prize just for being here. This is a good idea, as you always want your players coming back. Its best, obviously, to limit this to a slow trickle of EXP. Also, I recommend making sure that the player is active rather than just logged in.
Purse - win a race, battle, or battle of wits... these are all opportunities to reward a player with EXP. How many? Base it on multiple variables:
a) the level of the opponent (if applicable)
b) include a random scaler (such as one based on a dice roll sys utilizing our buddy Fibonacci).
c) style of win
d) duration of altercation
e) tactical prowess
Of course, you can come up with your own factors... Level crafting is something of an organic process. You start off with a lump of clay (pattern of 2x) and slowly carve away until you have a beautiful vase or alien sculpture (Fibonacci sequence with slowing tail curve).
Cold hard cash - Maybe your in this business to make money... You could always allow players to buy their way to the top. You'll need to be mindful of alienating your not so affluent players however.
Social Reward - You can honor large groups of players for organizing and achieving a goal.
Hopefully you get the point. There is no one right way to do it. There are plenty of wrong ways and you'll figure out which they are once you've tested them.
Finally, and just as a side note, refer back to the chart in Tabletop Leveling. Note the varying Class Level Names. I love this... It's much more interesting than grunt lvl 1, grunt lvl 2, etc. Have fun with classifying things. It gives players something to talk about.
Thursday, April 1, 2010
I saw the founder of 3 Melons present at Unite 2009. He showed off a bunch of the tools that they created for use in producing their Unity Lego title, really a lot of impressive stuff. Hope that it was a good move and that they did alright by the deal.
Anyway, here's the article:
Wednesday, March 31, 2010
If any representative from Unity is listening, pretty pretty please patch this bug!
Here's the update that I received from our CTO:
"I interviewed someone yesterday who said he ran into exactly the same problem that we did. Even more telling, I had a phone conversation with someone at a game development studio called ******* (they did *******, among other games; there are approximately 60 employees there) and they have not only run into this same problem (although in their case it was using Unity with Perforce) but also, in conversations with Unity about the issue, were told that Unity is working on fixing the problem."
I can't find any public comment from Unity on the Bug... Anyone?
Tuesday, March 30, 2010
"two-pizza team": If you can't feed a team with two pizzas, it's too large. That limits a task force to five to seven people, depending on their appetites.
My new agile mentor Mike Cohn explains why this works:
- There is less social loafing
Psychologist Max Ringelmann coined the concept of Social Loafing, aka the Ringelmann Effect, in 1913.
[wikipedia on Ringelmann Effect] "...the lack of simultaneity of effort in groups, which interferes with efficiently combining individual inputs."
In other words - this concept explains the tendency that individuals have in larger groups to exert less effort because they believe that the mass will overcompensate for their minimal exertion.
- Constructive interaction is more likely to occur on a small team
Mike cites Stephen Robbins here:
[Stephen] has concluded that teams of more than 10 to 13 people have a difficult time establishing feelings of trust, mutual accountability, and cohesiveness. Without these, constructive interaction is difficult (2005, Essentials of Organizational Behavior)
- Less time is spent coordinating effort
This is a no-brainer... More bodies = More logistics. Trying to herd 10 people is exponentially more challenging than half that.
- No one can fade into the background
Yes, yes, and Yes. I don't know if you believe that humans are innately evil or good... but I believe that they're innately lazy. Let me ask you a question. What would you do with $1,000,000.00 lotto winning? Most folks that have taken my informal poll answer something to the effect of... "move to an island." God love them but most humans are lazy or at least exhibit laziness when given the chance.
- Small teams are more satisfying to their members
I concur. You get to feel like you're moving the needle. When you're just one of many, the joy and accolades of your accomplishments can get lost in the clutter.
- Harmful over-specialization is less likely to occur
I'm a fan of the generalist. Why not know as much as you can about numerous subjects?
Tuesday, March 23, 2010
Here's a quick tutorial, created by Will Goldstone, that teaches you how to create an island terrain:
Video tutorial on creating a terrain in Unity 3D
It goes over adding/customizing a particle effect, adding a lightbox, adding a First Person Controller, & Etc. The presenter has goes over each aspect at a great pace. Kudos to you Will!
Here's the exact syllabus:
PART 1 covers creating a new project and exploring the interface.
PART 2 covers terrain extrusion and texturing.
PART 3 covers Trees and further environment topography.
PART 4 covers Lighting & First Person Control. In this part we introduce the First Person Controller, a ready made prefab allowing you to walk around using the keys and mouse, and lighting the scene.
PART 5 covers Water Elements and Light Flares.
PART 6 covers using a particle system to add smoke to our volcano.
PART 7, the final part covers improving our volcano's particle system by creating a material for the smoke.
This tutorial series is a great way to learn how to create an entire terrain from start to finish including effects and lighting in Unity 3D and is a grea lesson to learn how to use the Unity 3D game engine software.
You can see how mine turned out here:
(use the W,A,S,D keys to navigate)
Here's a picture if you're too lazy to click on the link:
Ain't she a beauty?
Following this tutorial is a great way to get familiar with the tools that Unity provides!
Story Points are units of relative size used in estimating software requirements. This is an alternative measurement to time based analysis. Points are estimated by assessing complexity rather than duration. Story points work in conjunction with User Stories.
What are they good for?
Story points are a fantastic way to estimate how long it will take to finish a product. They replace the standard time-based estimate with a more detached concept. Story Point is not the only vernacular around to describe this measurement. Some XP teams also call them cheezits or acorns.
We use story points when estimating for the long term, for instance against the entire product backlog. It's not a good idea to use them in planning for a particular sprint, as sprint velocity will vary.
Good quote from Mike Cohn on Velocity,
"This is why I say velocity is a useful long-term predictor but is not a useful short-term predictor.
Velocity will bounce around from sprint to sprint. That’s why I want teams to plan their sprints by looking at the product backlog, selecting the one most important thing they could do, breaking that product backlog item / user story into tasks and estimating the tasks, asking themselves if they can commit to delivering the product backlog item, and then repeating until they are full. No discussion of story points. No discussion of velocity. It’s just about commitment and we decide how much we can commit to by breaking product backlog items into tasks and estimating each. This is called commitment-driven sprint planning."
Monday, March 22, 2010
(If you're new to scrum, here's a quick video primer on the topic of the history of scrum and its components...)
User Stories - Short to epic statements told from the perspective of the user.
The Iceberg - A pyramid of backlog items which appear in groups of small Items at the top and larger scope items in the middle and bottom.
Kano Analysis - The process of using exciters/delighters, linear, and mandatory features to adjust the priority of features in the product backlog.
Kano Analysis Process - Here's a glimpse of what the process looks like in action...
Theme Screening - Identify the selection criteria for what is important and evaluate against the baseline (mandatory) features.
Baseline Theme - The baseline theme is one that is likely but not guaranteed to be included in the upcoming release.
Theme Scoring - Similar to Theme Screening but avoids category compression by adding a weighting system. Doesn't have a single baseline theme but instead offers reference themes per attribute.
Relative Weighing - a prioritization approach that considers both the positive benefit of the presence of a feature and the negative impact of its absence.
Other Neat Recommendations that popped out:
- spend 10% of each iteration (sprint) working on the next iteration
- avoid including backlog features in the sprint that can not be encapsulated
- groom the product backlog often
- survey of 20-30 users is large enough to qualify as a quick representative sample
Friday, March 19, 2010
Courtesy of TortoiseSVN help files:
Consider this scenario: suppose we have two co-workers, Harry and Sally. They each decide to edit the same repository file at the same time. If Harry saves his changes to the repository first, then it's possible that (a few moments later) Sally could accidentally overwrite them with her own new version of the file. While Harry's version of the file won't be lost forever (because the system remembers every change), any changes Harry made won't be present in Sally's newer version of the file, because she never saw Harry's changes to begin with. Harry's work is still effectively lost - or at least missing from the latest version of the file - and probably by accident. This is definitely a situation we want to avoid!
The Lock-Modify-Unlock Solution
Many version control systems use a lock-modify-unlock model to address this problem, which is a very simple solution. In such a system, the repository allows only one person to change a file at a time. First Harry must lock the file before he can begin making changes to it. Locking a file is a lot like borrowing a book from the library; if Harry has locked a file, then Sally cannot make any changes to it. If she tries to lock the file, the repository will deny the request. All she can do is read the file, and wait for Harry to finish his changes and release his lock. After Harry unlocks the file, his turn is over, and now Sally can take her turn by locking and editing.
Figure 2.3. The Lock-Modify-Unlock Solution
The problem with the lock-modify-unlock model is that it's a bit restrictive, and often becomes a roadblock for users:
Locking may cause administrative problems. Sometimes Harry will lock a file and then forget about it. Meanwhile, because Sally is still waiting to edit the file, her hands are tied. And then Harry goes on vacation. Now Sally has to get an administrator to release Harry's lock. The situation ends up causing a lot of unnecessary delay and wasted time.
Locking may cause unnecessary serialization. What if Harry is editing the beginning of a text file, and Sally simply wants to edit the end of the same file? These changes don't overlap at all. They could easily edit the file simultaneously, and no great harm would come, assuming the changes were properly merged together. There's no need for them to take turns in this situation.
Locking may create a false sense of security. Pretend that Harry locks and edits file A, while Sally simultaneously locks and edits file B. But suppose that A and B depend on one another, and the changes made to each are semantically incompatible. Suddenly A and B don't work together anymore. The locking system was powerless to prevent the problem - yet it somehow provided a sense of false security. It's easy for Harry and Sally to imagine that by locking files, each is beginning a safe, insulated task, and thus inhibits them from discussing their incompatible changes early on.
It's common sense but a nice reminder as to why a merge solution is superior. You can read about their explanation of the Copy-Modify-Merge Solution here.
Wednesday, March 17, 2010
The winner paradox
Keep winning percentage abnormally high. In real life, not everyone wins. Only one of the 25 teams in the NBA can win the championship, but not so in games. The player is looking for a satisfactory conclusion. Developers should make sure players win big and win often. Skew the “winning percentage."
Reward vs Punishment.
Players like to find gold coins. Players are very inclined to accept anything you give them and think that’s the result of their own merit. If you punish bad behavior, the game is wrong, it’s cheating, players think. When there’s a negative consequence, it’s important that the player understand why that’s happening and how to avoid it next time. If you can emphasize that “next time” aspect, you increase replayability. Antime you can plant the seed of replayability, do it.
Also, the first 50 minutes have to be really cool. Let them know they’re on the right track. Cool stuff is happening and even cooler stuff will happen later on. In the first 50 minutes, you almost cannot reward them enough.
I used to think we needed four difficulty levels. Apparently, I was wrong; we need nine. The reason we have these levels is to create a sense of progress. There always need to be more challenges. Desiring to make it to the next level enhances replayability.
You always want your player to feel they are above average. They are doing well, and they will probably do better.
The Unholy Alliance
This defines the relationship between the player and the designer. I’m going to pretend certain things; you’re going to pretend certain things, and together we’ll have fun. The terms of the alliance are as follows:
1. I’m good! (the player). Designers went off track with more and more realistic plane simulations: realistic crashes created the impression “I’m not good, my plane is on fire and I’m falling out of the sky.” Keeping them feeling good about themselves is an important part of the designer's role.
2. Suspension of Disbelief. The player needs to inhabit that character. That’s his part of the bargain. When my wife comes out of a movie and I ask what she thought of it, she says things like “I came out of that movie twice” or "I never got into it," or “never came out of it.” Players need to stay “in it” and designers need to help them.
3. Moral clarity. Imagine you are conquering cities. You have one town left to occupy, you outnumber them and can squash them in a second… but they’re defiant! It would be more realistic if they wanted to surrender and asked for pity. But that would put the player in a moral dilemma—you always want the player to feel he is making the right decision by continuing to play.
4. MAD: mutually assured destruction. The Cold War balance of powers is paralleled in the player-designer relationship. Players can play in all kinds of ways that destroys the experience. Designers can do the same. You need to keep the balance to maintain the suspension of disbelief.
5. Humor/ Style/ Music/ Atmosphere. If you start with lighthearted music and cartoony graphics, then all of a sudden heads start exploding, you’re not living up to the alliance. You don’t want to fool the player. To help the player maintain his suspension of disbelief, you need to consistently keep the player in your world.
Often games give odds for the player’s chances of defeating a foe. For example, the Attacker Player has a 1.5 score and the opposing Barbarians have a 0.5. There’s a 3-to-1 chance that the Attacker will win. When polled, however, players thought they should always win when they have a 3-to-1 advantage, but weren’t surprised when they would lose if they were at a 1-to-3 disadvantage. Around 3-to-1 or 4-to-1 advantage, players expected to win every time. So we adjusted the computer to appease the player.
Players felt they could lose a 2-to-1 battle every now and then. But they had a problem if they lost a 20-to-10 battle. So we adjusted, and asked, “Now are you happy?” “Well kind of, but there's one more thing: I had a 2-to-1 battle and lost, which was fine (we went over that). But right after that, I had another 2-to-1 battle and lost again—how can that be!? The computer’s out to get me, obviously!” So we made sure that occurrence wouldn’t happen, and the player was happy.
When something happens that feels wrong (even if it isn’t), we start to lose the player’s suspension of disbelief.
My Bad (errors Meier made)
* Real-time Civilization. When we introduced real-time play with others, the player became an observer of other players. The game’s mantra was “It’s good to be king.” We needed to put the player at the center, so we took away real-time action.
* Rise and Fall. We thought, “Wouldn’t it be great if you are crumbling and just at the last minute before all is lost, you come in and save the situation and then rise again to an even greater status than before?” No. Players would reload at the cusp as things start to go badly. They would never experience the comeback, so Civilzation is a game of progress only.
* Don’t Randomize. Players want to be in control. Whenever anything random happens to the player, paranoia sets in. They feel the computer rolls that random number to make their life more difficult. Random events at a large level have to be treated very carefully. Low level randomization can help things seem more realistic, but if they are large events, players come up with worst possible explanation for it.
* Civilization Network. This network is built on the Facebook platform, and is social. We played with idea of being able to give gold to other players. They could trade or beg or give out of pity if they wanted. What we found was that nobody ever gave gold to anybody else.
The CEO of SOE gave the keynote for GDC Austin and, in it, he went over a lot of very useful info about their trials and tribulations.
One thing that was interesting, a larger % of kids <13 do not know what year they were born!
I've created a side by side comparison of the changes that SOE made to their sign up screen which took them from 60% success rate to 90%.
You can hear the keynote, if you're interested, by visiting www.gdcvault.com.
Tuesday, March 16, 2010
A unit of measurement must be defined before you begin construction on a 3D game. So what do you design this metric around? The potential chicken and egg of game design is to design around the avatar or the geography. Consider this from Richard Bartle's Designing Virtual Worlds:
"The religious view of the real world is that one or more deities created it. Normally, the deities put the world together before introducing humans into it (rather than creating both at once or the humans first). However, from the beginning, the deities intend to populate the world, and therefore design it with the humans who will live there in mind.
For the real world, you should decide for yourself which of these views is the more correct. For virtual worlds, discount the first one. Deities create virtual worlds; designers are those deities."
Linear Working Units
As far as my research has stretched, it's best practice to measure via the metric system and, for god sake, use meters not centimeters or decimeters.
That said, here's what I ended up with for MyMiniPeeps at the end of the day:
With this in tow, the sky is the limit! Now you can describe the geometry of interiors, stairwells, doorways, and etc! I definitely do not recommend starting any asset creation until you have decided on and COMMITTED to the bounds of your avatar.
[Note: As you see in my graph, I've left room for bulky accessories. My game requires loads of customization. Yours may as well so remember to plan for them.]
Other things to consider...
Does Size Matter?
How large should a virtual world be? My vote, it should be as large as it needs to be in order to be entertaining. If you build a giant map with nothing to do then you'll bore your audience. If you build a small map and don't shard, then you'll frustrate your audience (not to mention you'll overload your servers).
Speed's effect on Size
We must consider how fast our avatar's move in order to really comprehend how large our world will feel. Feel is different than the actuality of the geometry. Consider this passage also from Bartle:
"Speed of travel affects size: If it takes you half an hour to traverse one virtual world and two hours to traverse another, the former may appear to be smaller than the latter even if it isn't; if you can teleport anywhere, the world will feel smaller still."
This has been an exercise to investigate various ways of capturing a spacial definition. I hope you've enjoyed our journey. Seriously, if you take anything away from this blog make sure that it's this... Plan ahead when it comes to your unit of measurement and your avatar's bounds. You'll be happy that you did.
Thursday, March 4, 2010
While individuals can cope with the symptoms of burnout, the only way to truly prevent burnout is through a combination of organizational change and education for the individual. Organizations address these issues through their own management development, but often they engage external consultants to assist them in establishing new policies and practices supporting a healthier worklife. Maslach and Leiter postulated that burnout occurs when there is a disconnect between the organization and the individual with regard to what they called the six areas of work life: Workload, Control, Reward, Community, Fairness, and Values. Resolving these discrepancies requires integrated action on the part of both the individual and the organization. A better connection on workload means assuring adequate resources to meet demands as well as work/life balances that encourage employees to revitalize their energy. A better connection on values means clear organizational values to which employees can feel committed. A better connection on community means supportive leadership and relationships with colleagues rather than discord.
One approach for addressing these discrepancies focuses specifically on the fairness area. In one study employees met weekly to discuss and attempt to resolve perceived inequities in their job. This study revealed decreases in the exhaustion component over time but did not affect cynicism or inefficacy indicating that a broader approach is required.