Jump to content
  • Advertisement

Design Style Gauge Game - Developer Diary #1

Harlan A Nagel


A little about me before I start this. I’m Harlan. I’m a game designer. The game industry is relatively small where I’m from, so I’m developing games as a side-thing for the time being. One of my biggest goals as a game developer, in short, is, “To get the broad human population to appreciate artistically significant experiences in video games, even gamers who consider pieces like The Walking Dead: Season One or Life is Strange to be ‘not real games.’”

I’m about to start a new game project! Below are my first reflections on what the game could be. I’ll go over my main focus, limitations, then, finally, aspects of replayability that I may incorporate.

As the main focus, I want to implement a style gauge, like in the Devil May Cry series. Why? Because the mechanic is underused, despite probably being a REALLY effective way to encourage player experimentation, encouraging them to branch out from the critical path and, for example, “attack with the move that leaves me open to attack – but it’ll be stylish!”

However, before I consider more gameplay, I’ll outline other limitations. First, timeframe: as an indie game focused on illustrating the versatility of a certain game mechanic – and developed by a relatively-junior developer – the project will be small with a goal for a playthrough time of a half-hour.

The second limitation is graphics, 3D or 2D? Given artist availability and player expectations, 3D is best. It is true that, in my experience, 2D games are easier; they, at least, seem quicker and the aesthetic is easier to control. Game-based 3D animation, however, is becoming a larger field with more post-secondary programs and competition, so if I go 3D, I can “do more good” by creating an opportunity for a 3D artist or two. Lastly, there is a player base that I hope to reach; they seek AAA experiences and usually avoid “indie-looking” games.

With these limitations clarified. I’m guessing this new project will take 6 - 12 months.

With a style gauge and short playthroughs in my plans, I should also consider replayability.

Various mechanics are used in games – like the Devil May Cry series or The Binding of Isaac – to extent total playtime beyond a single playthrough. Many of these games have short playthrough times and deep systems, so the players hunger for more. Below, I remind myself of some mechanics that make a game feel different in subsequent playthroughs:

- costumes

- new weapons

- new dialogue choices

- new combo trees

- social interactions

- level branching

- plot branching

- companions (with whom do you foster the strongest friendships?”

- different playable characters

- different music

- different environmental effects

- limited time events

- social media or real life integration

- procedural generation

- leaderboards

- deep systems

- cultural or aesthetic characteristics that do not exist in the current game market

After brainstorming some features, replayability seems to come down to aesthetic changes, non-linear gameplay, and deep systems. I’m not satisfied with that, so I found a YouTube video by Mark Brown: https://www.youtube.com/watch?v=5N4U46QOyeA

It brings up the point that repetition in the Hitman games shortens the gap between player and player-character. The parallel between these two parties is one of my favorite topics in game design; it’s a relationship that fosters massive emotions in dramatic moments, so I might write a blog post about this in the future. But in this case, repetition is used in Hitman to strength that parallel, according to Mark Brown.

Hitman does this by allowing players to succeed in missions, but subsequent plays can create more satisfying completions; these bring players closer to feeling like Agent 47, the calculating assassin. The game incorporates unlockables, like weapons, and challenges, like “sniper-only” as the player learns more about how missions branch. Missions branch heavily too; for example, NPCs react to player actions differently from other NPCs, including targets, or certain locations are only accessible when conditions are met. Eventually, the player participates in a sort of “end game” where 48-hour events occur as new targets in old levels, so the players use their old knowledge to take out the new target who has new habits.

This 48-hour target idea is pretty cool. I wonder if the same mixture of novelty and knowledge can be done without limited time events with procedural targets?

Anyway, that’s enough for now. I’m visiting Montreal right now hoping to establish a life and get involved with the development community. Wish me luck!


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
  • Advertisement
  • Blog Entries

  • Similar Content

    • By Mutantgun
      Hi Everyone,
      Hopefully all of this makes sense at the end, but if you need anymore clarification please let me know.
      Background: My MMORPG is a sword playstyle based game, where players need to complete a dungeon at the end of each floor to be able to progress to the next. (Players can go back to lower floors / Specific floors will have specific resources needed for crafting as to give players a reason to go back / Player skill progression will also require them to do specific quests/tasks on specific floors, again giving them reason to go back)
      Inspiration: Sword Art Online (Anime) - Aincrad game that the players were stuck in
      My map progression issue is this: I'm split between having all players locked to a specific floor until they/or the party they are in, completes the dungeon, then those players unlock the next floor OR if as soon as a party clears the floors dungeon and unlocks the next floor, that floor is unlocked for everyone on the server.
      I'm going to split these into options 1 (Individual Progression) and 2 (Server Progression).
      Option 1:
      Allows the more dedicated/end-game player base to progress at a faster pace. Allows for end-game guilds to form and recruit from a more end-game player pool, I.e. Players from that specific floor Allows end-game players to sell their services to help newer players to progress through the lower floors Drawbacks:
      Possibility of new players being stuck in lower floors as there might not be good enough players left on those floors to help them make a party and progress through the dungeon ? Option 2:
      Allows new players to skip floor progression to be with their friends that have progressed further in the game ? Drawbacks:
      Players will be on floors where they might not be able to survive or complete solo content because of their lack of skill, items, game knowledge Complains from new players saying the content is too difficult, as they are skipping floors New/lower player base will essentially just be waiting on the end-game players to finish the new floor unlocking it for the rest of the server, basically letting them sponge off of the top players progress After typing all of this out it's starting to become more clear cut as to which option I should take, but I'd like to check with the community here as I'm sure there are other benefits/drawbacks that I'm missing that might change my view of things.
    • By Tomato Head
      Hello everybody,
      I'm very interested in learning what is your process for discarding core game concepts that you've have come up with. Knowing that it is very hard to work on more that one development at once and plenty of people have more than one idea for games in their head, how do you discard or prioritize your concepts? Have many of you created prototypes and only then found the concept is not good? Have you found that there are core concepts that are bad and can never be iterated to get a playable/good game?
      Any advice is very much welcomed.
    • By bzt
      I'm not sure if this is the right forum for this, or it should go to General Programming. Please feel free to move it.
      I'd like to read skeleton from a model, using Assimp. As it turned out, interpreting Assimp structures is just as complicated as parsing many different formats at once. Judging by huge number of assimp-bone related questions on forums (some of them here too) I'm not alone with this problem. I've searched a lot, and I could find many answers to my questions, however the pieces are still not fitting together entirely. To explain what my problem is, I'll try to summarize what I've gathered so far, and please correct me if I'm wrong somewhere.
      The main problem is, both bone structure and mesh structure is stored in the same node structure, however it would be false to assume they are correlated. Meaning you have to traverse the same node-tree two times, completely independently, to get the correct results: one time for the meshes, and one time for the bones. Is this true? The best instructions I could find so far is here under section "Bones", but it is just a pseudo-description of a rather ridiculous algorithm (I'm sorry, but I really think that). Some important answers I've found here.
      Most assimp tutorials (like here and here) I've found seems to miss key parts of the whole procedure. They usually simply iterate through aiScene->mMeshes or walking the node tree collecting mMeshes in a vector, but from what I've learned so far, this is wrong (or more precisely only works in an exceptional case when only the root node has meshes). To explain what I mean:
      - model space: this is what we use to display our model
      - mesh node space: all mMeshes in a node contains vertices in this space (is this correct? or are they stored in model space in the first place?)
      - bone node space: similar to mesh node space, however totally unrelated to the node space that contains the mesh
      So, to correctly load all vertices into model space, we have walk through the node tree, concatenating the node's transformation matrix along the path and apply it to the vertices. Otherwise if there's only one node with meshes, and it's the root node, then, and only then model space == mesh node space. Is this correct?
      Bone nodes' transformation matrices are not model space related, rather skeleton hierarchy related, and they also have an offset matrix which transforms from mesh node space into this bone's node space. This is clear (at least something is :-))
      Traversing the node tree for bones and concatenating their transformation matrices along the path will result in a matrix that converts from bone node space into model space. If there's only one node with meshes and that's the root node, then, and only then this concatenated matrix is the inverse of the offset matrix. This seems reasonable if I understood everything correctly.
      If we later want to use an animation, then we have to
      1. get the list of bones which changed on that particular frame
      2. collect all vertices that are affected by that bone (mMeshes[]->aiBone)
      3. collect all of the bones that control those vertices and all of those bone's children (in a unique list, as we have to recalculate all vertices belonging to those bones)
      4. using the corresponding offset matrices, convert those vertices from their "bind-pose" skeleton mesh node space into one or more bone node spaces ( V -> V'[1..numWeights])
      5. use the transformation required by the animation frame on all vertices that belong to the modified bone using their corresponding bone node space versions (V'[x]),
        or do we multiply the frame transformation matrix temporarily with the bone's transformation matrix? (In other words, should we transform the vertices in the bone space or their coordinate system in model space?)
      6. get a weighted average of each vertex in their corresponding bone node space (w[1..numWeights] * V'[1..numWeights] -> Vm), then transform the result into model space (or should we / would it be better to convert the points into model space first and calculate the weighted average there?
      (Let's assume we have a frame for the sake of simplicity, I know how to iterate skeletons.)
      A little note on 5th question: although it seems to be irrelevant whether we transform the points or their coordinate system, because we'll get the same result (in model space), however this affects the points of the children bone spaces differently. I guess we must not convert the bone node spaces into model spaces, rather keep them parent bone node space relative, and only convert the final points back to model space. Am I correct?
    • By JeremyAlessi
      In PixelCast 7, Jeremy hangs out at Pixels = Pints + Bytes for the latest PixelFest Devs meetup and chats with two local indies about their studios. Joshua Jané demos 'Bouncy Bear' and explains what makes 'Just Bare Games' tick, including the fact that all their games contain bears! Meanwhile, Joseph Musso of Sunset Studios let's us in on the game he's been pondering for 10 years ('Santa's Sleigh Ride Sacrilegious Arcade Action'... say it three times fast), which is now playable after coming out to a PixelFest Devs meetup back in August.

      View full story
    • By JeremyAlessi
      In PixelCast 7, Jeremy hangs out at Pixels = Pints + Bytes for the latest PixelFest Devs meetup and chats with two local indies about their studios. Joshua Jané demos 'Bouncy Bear' and explains what makes 'Just Bare Games' tick, including the fact that all their games contain bears! Meanwhile, Joseph Musso of Sunset Studios let's us in on the game he's been pondering for 10 years ('Santa's Sleigh Ride Sacrilegious Arcade Action'... say it three times fast), which is now playable after coming out to a PixelFest Devs meetup back in August.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!