See part 1...
As mentioned earlier, the replayability of a game depends on how the game can make a deep connection to a player. Last part, we talked about how the story telling affects its replayability. Today, let's see how a game mechanics affects it.
- Side quests
- Game mode
- Story paths
Introducing replayable elements in game mechanics is somewhat a lot less expensive than other methods, in my opinion. Mainly, you re-use the already made assets. However, you trade this off with making good design, and understanding your market, because some designs are suitable for one group, but not for another.
Let's think about separating players into two groups: hardcore and softcore. Hardcore players are generally equipped with these qualities -- competitive, and perfectionist. Softcore, aka. casual, players are somewhat on the opposite extremities. Hardcore players like to have the first play through, and after-the first replay. The first play through is generally for learning the main story line, expertizing the game-play mechanics, and thinking about what are left to be played in the next replay. The players normally don't have a problem with repetition, nor uniformity as long as they can find the mean of competitiveness and perfection. Putting it simple -- if they love your games, they will play the hell out of it; the more you have for them, the more they play.
On the opposite side, softcore players, they are easily bored by repetition, and uniformity. They are more likely to have only less-than-first play through -- yes, they don't even get to the ending. So, by the nature of this group itself, it is hard to make them feel they would come back to the game once they leave. A game which suits for hardcore players is less likely to suit for softcore ones. However, this is a way bigger group of consumers than the other one. So, leaving them behind or not, is a tough decision to make.
3. Community Involvement
4. Business Model
As a game developer, most of the time, we want our games to be heard of, to be talked about, to be played as long as possible. Think about, e.g., Skyrim, which was released in 2013, until today we still see the name popping up frequently in the medias. One of the quality to sustain its existence is its replayability.
What makes a game replayable? Ok. This is not a trick question for an answer like "having a replay button." A replayable game in this sense supposes to be a game which can somehow establish deep connection with a player whom is convinced and would love to replay it from time to time. Think about some kind of food which you occassionally miss it and hunger for it. Yeah, that is your deep connection with the food; the same thing we need in the game.
This question has been asked often in any game development forum. It is a big question which you can find research articles, discussion, or blogs easily by googling it. Different people have different ideas. Different time has different techniques. Here, I will not go in lengthy detail, but I would make a quick list and throw in some references.
1. Story telling
- Good narrative
- Many story paths, Many endings
- Faction specific storyline
Story telling, or narrative, is one of the choice can be exploited to make a game replayable. A good exmple, I would tell you to look into novels, movies, or tv shows. Like myself, I watch Harry Potter once every year, from the first episode till the last; it has been my tradition for almost 7 years now. Besides the reason that it is a good show, and I myself grew up with it, having many episodes released sequentially somewhat encourages audiences to re-watch. In game industry, this is similar as having expansion.
Another example a long the same line as having expansion, but can be somewhat easier to be developed, is "spin-off." By definition, spin-off is "a byproduct or incidental result of a larger project" (from Google). Even though spin-off is be a different product, if you design the spin-off to have references from the main series, this would enhance replayability of the main series; because the audience might not exactly understand the reference that he would need to re-visit the main series.
Besides those, the regular idea of having good narrative that can build deep connection with the audiences is funtamental that we should never forget. Also, providing many story paths, or ending like in visual novel games, or any game which a player choose a faction of which specific story is exposed to the player, can be considered in either this story-telling category, or game mechanics one.
2. Game mechanics
3. Community Involvement
4. Business Model
I didn't know if I can, I just believed that I can. Anyway, let's play safe -- joining the team which already has a lead programmer. That's pretty much what was running in my head with a lot of frustration. Things didn't turn out as expecting, but it was a happy ending.
Spring 2017, January, it was my first time joining Ohio University Game Developer Association (OUGDA). I hadn't even known people in the club besides officers; I hadn't even trained properly how to make a game; but a big day was coming in the next week -- it is the Global Game Jam (GGJ) 2017.
GGJ is an annual event in which game developers would spend only 48 hours to make a game -- starting since ideation until release. GGJ would provide short keynote and theme; the rest is up to you. It is not a competition, no judgement, we will just appreciate our friends' products, share comments, and thoughts. It sounds like there would be no stress. Haha. That depends. T.T
OUGDA started gathering since 4:30pm of the first day. Everyone was so energetic; actually, everyone is always energetic - -". The keynote and theme released around 5:30pm. "Waves," that's the theme.
With a lot of energy flow, and frustration, everyone was wandering around and talked, and shared, and listened to ideas on the theme. For me, I was more toward listening. Though I had an idea in my mind. It was about echolocation -- yeah you heard right, that's the EchoEcho -- listening to others' ideas can really expand my imagination; and I love it.
During the time I learnt that there were couple of people also thinking about echolocation. In the end, our producer, JJ, was the one who pitched on the idea.
Even though my idea was standing there waiting for me to join the team, I was hesitant for only one condition -- I didn't want to be the lead programmer. Why? Because it was my first time making a real game; I didn't have experience; I didn't have confidence; I didn't want to screw it; etc. Luckily, JJ's team already had all the important positions filled, which means I could stay as the support programmer. YAY!
We took off and had dinner together. We supposed to talk about the project, but nobody started. I think that was one of our team main problem -- we didn't have project manager. However, we managed to get into the topic, and the fun began.
We came back to the computer room around 8pm to start working. By that time, only myself was available to do the programming since JJ would do the level design first, and others worked on graphics, and sounds. I was sitting there for about two hours getting nothing done because I was so tired for the long day. So, I decided to leave and got some rests. That was the right decision. Rest makes your brain runs.
Because JJ was still busy with his level design, and only him can do programming besides me, I was shocked when I went back in the morning, and learnt that my team moved me to the lead programmer. I tried to keep things in control professionally, even though I was like screaming inside so loud! Being chill. Taking it easy. Communication. And, planning. Those were things kept me moving forward with the tasks at hand.
The project seemed to maintain a good flow until the end, at least for my part. Though we discarded a bunch of ideas, arts, sounds, etc. because of either time constraint, or lack of capabilities, our first release, EchoEcho, v1.0.0a, was very satisfying.
I had learnt a lot from this project. It improved both my skills, and my attitudes. I learnt to believe in myself, and my team. Though many people might say that programming is the main role for making a game, I would still insist that every role is important on the equal foot. And, we are all awesome!
Thanks to my team: JJ, Liam, Brian, Ryan, Erin, Maddie, Kayleigh.
Thanks to OUGDA, Ohio University, and GRID Lab.
Thanks to GGJ.