Finding Core Experiences
So let’s say you start building something without serious fore-thought, basically, without a core experience in mind. Unless you’re on a mission of pure discovery and experimentation, it will be highly advantageous to start identifying a focused set of experiences to deliver upon before you just blue sky aimlessly for too long.
It is important to note that this process outlined below is for cases where you have a prototype that you feel shows some promise. If your prototype is just a mess, and you don’t have any other things planned to add to it or fix, then you should probably just put that down to a failed experiment. Maybe consider actually Forming Core Experiences first – Don’t aimlessly waste time trying to polish a turd.
Be prepared to do more iterations of prototyping and assessment to get this right. To discover your core experiences, you may actually have to build or refine them on the way. This process below is really a phase of prototyping, where you’re taking some extra steps to help define a top-down view of your game.
Start – Existing Prototype
You have a prototype, and know what features you have built. You may also have done some tinkering to get a sense of a few things that are tuned to make it play ok. As flagged above, this prototype should be at least somewhat fun or show some clear promise.
1 – Playtest
Play your prototype. Get others to play it too. Take notes, during the following two phases…
2 – Note Activities
Determine which activities the player actually engages in when they play. Do not look beyond that at this stage – This is about identifying what the player does, and nothing more.
- What are you spending time doing when you play?
Is your game non-stop action? Do you spend loads of time messing with your inventory or loadout screens? You may even want a stopwatch for this test, as time perceived may not match the time involved.
- What features are actually being engaged with?
Are there features you have in place people don’t interact with? Why don’t they interact with them? Are they useless features? Is it unclear that they’re there to be used?
This phase of assessment should help identify things about your mechanics and systems, and often if you have feedback issues with them.
3 – Note Experiences
This is the more emotive aspect of the assessment of your playtest. It’s something you should be doing in any prototyping situation, but to help define core experiences, you’re going to be paying special attention to how the player feels, and instances where you react to things – positively or negatively.
- Can you identify clear experiences you are having playing?
The real obvious conscious stuff – Like getting a sense of exploration, or being in a huge world? Was the game challenging or easy? Did things surprise you? Were there things in the game you were actually afraid of? Also note cases where you were snapped out of a positive experience.
- Is your prototype as fun as it should be?
Simply be honest and ask yourself if your gameplay is fun? Aside from that broad take on the whole game, can you identify individual features or aspects of the game that are clearly enjoyable, bland or frustrating? This is basic prototyping evaluation.
- Reflect on how you felt in a retrospective manner
Were you under intense pressure? Did that pressure ramp up gradually? Did you get a sensation of power and control? Were you totally immersed in the game?
These are things that are less conscious at the time, and you will need to reflect often to notice these effectively. E.g. You won’t tend to realise you’ve lost yourself in the game at the time.
- Are experiences occurring that you did not plan for?
Note – This is specifically a question to ask yourself if you have already implemented new changes to the prototype, and are now testing the changes. While you note any new experiences emerging, take careful note of whether this impacted on the other experiences you were getting before. E.g. Has this new experience diluted the ones you were having before?
4 – Evaluation
The final aspect of your reflection is to evaluate your notes on activities and experiences in unison. This may be time consuming, but if you can connect the experiences to the features or mechanics in your game, you will be well positioned to act on things ahead. Those connections could be responsible for experiences being positive or negative – working or not working.
For example – Is the player feeling helpless and lost in your game, even though you made some features to help them be both safe, and find their position and goal at any time? Furthermore, was that a bad thing or a good thing? You may have planned for the player to be confident about all that stuff, but discovered that the uncertainty for the player actually made the experience more compelling.
As you can see, there’s a lot to consider, especially if you have numerous systems and experiences you’re looking at. If you also keep your changes to a minimum with each iteration, this will be easier to keep track of and not become a time pit.
At the end of your evaluation, you must be able to identify the following in a ‘yes/no’ manner:
- Can you now clearly define the core experiences your game delivers in discreet sentences?
- Are the experiences at present positive? Are you free of clearly negative experiences?
If the answer was ‘no’ to either of those, then you have more work to do before you can say you have identified your core experiences, and you should now consider which is the primary issue at hand – if it is poor execution of features (go to step 6), or that your experiences are not well defined (go to step 5).
If the answer was yes, skip down to ‘Success – Identified Experiences’.
5 – Adjust Experience Plans
There are only two things you do in this phase – Reword/rewrite your core experience descriptions, and actually add, cut or reprioritise them. If this is your first attempt at defining your core experiences, then take your time here, as you are both defining and prioritising from scratch.
- Adding – Cutting – Prioritising
During your evaluation, did you identify an experience you did not have defined before? Add it to a list. Or perhaps you identified that an experience you have been gunning for is now not important, to the point where it is a lower priority, or possibly even out of the picture entirely?
What matters here is that you leave with a prioritised list. As stated in the Forming Core Experiences guide, you can have a bunch of experiences in your game, but you should have no more than four core experiences. These are the experiences you plan to REALLY deliver on, so it’s fine to only have one or two that you deem as ‘core’.
- Revising existing experiences
You may find that your prototyping and tweaks to gameplay have resulted in you reconsidering what you are trying to deliver. If this is the case, then it is very worthwhile making that clear and ensuring the wording of your core experiences is clear. That might mean it’s a little more specific now, or maybe more general – It doesn’t matter, all that matters is the language is right for what you’ve taken away, so your team can use this as a goal to aim for that isn’t prone to exceptions.
Note! It is very possible that you may identify an experience you want to deliver that is really something you will be unlikely to realise in prototyping. Things like atmospherics due to sound and lighting are tough to nail outside of the production phase. It’s okay to define these as a part of your core experiences, but be mindful that if your list relies on too many things you can’t prototype, you may risk running off with a plan that you have little evidence will work.
6 – Identify Feature Work
This is really no different from what you would do in any given prototyping situation. You are looking for features you need to rework, build or cut in order to improve the game, based on what you discovered in playtesting. In this case though, your criteria will be shaped with core experiences in mind.
In the interests of rapid progress, don’t spend time tweaking little things that can obviously be improved that aren’t vital. Making the UI a bit slicker is unlikely to identify or change a core experience. This really forms your criteria for what work you will do at the moment:
“Will this feature change I’m considering directly address one of the experience issues or goals in front of us now?”
If the answer to that was ‘no’, put the change idea in a file to come back to with later prototyping exercises. Keep your prototyping as rapid as possible.
7 – Implement
Build, edit or retune your features. Add or subtract content as required.
Success – Identified Experiences
Huzzah! You have defined your core experiences. The only remaining step you may have at this point is to ensure they are prioritised, and that you have no more than four. If it’s more than four, then they ain’t core.
Now you can get on with either more ‘standard’ prototyping, knowing you have defined your experience goals nicely defined. You may even be at the end of your prototyping cycle, this is really something that you’ll need to make a call on yourself based on whether or not you’ve got a game that feels really fun or not. The point to exit prototyping is when the concept is validated.