Jump to content
  • Advertisement

Search the Community

Showing results for tags 'Theory'.

The search index is currently processing. Current results may not be complete.


More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Categories

  • Audio
    • Music and Sound FX
  • Business
    • Business and Law
    • Career Development
    • Production and Management
  • Game Design
    • Game Design and Theory
    • Writing for Games
    • UX for Games
  • Industry
    • Interviews
    • Event Coverage
  • Programming
    • Artificial Intelligence
    • General and Gameplay Programming
    • Graphics and GPU Programming
    • Engines and Middleware
    • Math and Physics
    • Networking and Multiplayer
  • Visual Arts
  • Archive

Categories

  • Audio
  • Visual Arts
  • Programming
  • Writing

Categories

  • Game Developers Conference
    • GDC 2017
    • GDC 2018
  • Power-Up Digital Games Conference
    • PDGC I: Words of Wisdom
    • PDGC II: The Devs Strike Back
    • PDGC III: Syntax Error

Forums

  • Audio
    • Music and Sound FX
  • Business
    • Games Career Development
    • Production and Management
    • Games Business and Law
  • Game Design
    • Game Design and Theory
    • Writing for Games
  • Programming
    • Artificial Intelligence
    • Engines and Middleware
    • General and Gameplay Programming
    • Graphics and GPU Programming
    • Math and Physics
    • Networking and Multiplayer
  • Visual Arts
    • 2D and 3D Art
    • Critique and Feedback
  • Community
    • GameDev Challenges
    • GDNet+ Member Forum
    • GDNet Lounge
    • GDNet Comments, Suggestions, and Ideas
    • Coding Horrors
    • Your Announcements
    • Hobby Project Classifieds
    • Indie Showcase
    • Article Writing
  • Affiliates
    • NeHe Productions
    • AngelCode
  • Topical
    • Virtual and Augmented Reality
    • News
  • Workshops
    • C# Workshop
    • CPP Workshop
    • Freehand Drawing Workshop
    • Hands-On Interactive Game Development
    • SICP Workshop
    • XNA 4.0 Workshop
  • Archive
    • Topical
    • Affiliates
    • Contests
    • Technical
  • GameDev Challenges's Topics
  • For Beginners's Forum

Calendars

  • Community Calendar
  • Games Industry Events
  • Game Jams
  • GameDev Challenges's Schedule

Blogs

There are no results to display.

There are no results to display.

Product Groups

  • GDNet+
  • Advertisements
  • GameDev Gear

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


About Me


Website


Role


Twitter


Github


Twitch


Steam

Found 67 results

  1. While going through a Game Design Document Template, I came across this heading - Core Game Loop & Core Mechanics Loop. What's the difference? Can you provide some examples of an existing game? Suppose if I am including these topics in a Game Design Document, how should I explain it so that my team can understand?
  2. Hey all! This time I'm going to write a little about my plans for generating planets. This entry won’t go into any specific details of the terrain generation but will be just a very high level overview of the basic framework. I don't think any of the ideas in here are new.. the procedural generation community are a very clever bunch indeed! I'm always amazed how when an idea pops into my head I'm able to find an existing article about it that goes into fine detail on the subject. Anyway let's crack on! Heightmaps & Voxels When it comes to generating terrain an easy first choice is to generate height maps and build the terrain mesh from that. You can get some good looking results quickly by overlaying some noise generation and tweaking things here and there. Though these can give some nice results they have limitations. For example tunnels and overhanging terrain can’t be represented in a simple height map. You also have to choose a projection scheme to map a 2D height map onto a sphere. There’s another approach to terrain generation using voxels and that’s what I’m aiming to use. With voxels you can define all sorts of complex terrain and you can define what’s hiding under the ground too - whether it's seams of coal, ore or underground rivers. Many games use voxel terrains to great effect such as the infamous Minecraft. Sign me up! In Minecraft the voxels are arranged in a grid, keeping everything nice and simple.. until you want to model a whole planet. Then you’d get something like this: Though that does look really cool, I don’t want my worlds to be great big cubes floating in space, so what do I do? There are all sorts of solutions to building a spherical world from a voxel grid, but they seem to be full of difficult space warping, caveats and rendering complications. I’d rather not deal with these kinds of complications, so I’m going to try a different approach. Instead of arranging the voxels in a grid I’m planning to arrange them as points on a geodesic sphere like this (imagine the vertices are voxel points): It’s like taking the space warping issues you’d need to do at the cubes edges and spreading it evenly across the entire surface of the sphere. Instead of it becoming a difficult edge case it becomes a constant low level annoyance and keeps things consistent at all times. It will make the mesh generation a little more fun later too Voxel Planet Generation The plan is to use an icosahedron as a starting point. Each vertex here is a voxel. This can be considered the lowest possible Level Of Detail (LOD) of a planet. The space is chopped up into tetrahedrons from the planet surface into its core. There is an extra vertex at the centre of the planet for this. These tetrahedrons can be subdivided through to the core of the planet as required. These illustrations are somewhat misleading though as this isn’t just generating a spherical mesh, but a bunch of voxels that could be empty space. The voxel points (vertices) hold information about what's actually in the space they occupy, whether it’s atmosphere, rock, magma etc. It is the job of the terrain generator to define what a voxel contains. I'm going to keep a clear divide between the planet voxel generation code and the terrain generation code this way. I have some uncertainties on how to best manage the subdivisions of the planets voxels as required, but I’ll bash it out in a prototype. Dynamic Changes The game also needs to be able to make permanent changes to the terrain during play. Large explosions should create craters and I want them to persist. To do this I will need to be address the voxels and save state changes about them. I'm not 100% sure on the approach for this yet either. One train of thought is to basically create an algorithm for the voxel generation that that is able to assign each possibly generated vertex a unique 64bit number. That would have no waste and allow the maximum number of voxels, and some napkin math makes me believe it would have good detail on earth sized planets. Another approach could be some kind of hash of their XYZ or polar coordinates, though that will be more wasteful so it’d bring the total addressable voxels way below what a 64bit unique id could theoretically hold. Ok that’s enough for now!
  3. I've put together some tutorials that explain the ideas behind Marching Cubes and Dual Contouring. Maybe it'll be useful to some of the forum-goers. Marching Cubes 2d Marching Cubes 3d Dual Contouring Each tutorial comes with sample code in Python. Let me know what you think. This is the first time I've written a tutorial, but may do more if people want them.
  4. I have an idea about a modern-day war game, where players build up their base and attack other players. What I was unsure of was if a game like that needs a back story, a reason why everyone is fighting each other. So what do you think? Should a game with base building and PVP need a backstory? If so, what are some appealing ideas? Why is the world at world? How do new players coming into the game change the story at hand? If at all? Will there ever be a single victor? If so, what happens then? Let us have a discussion...
  5. Hello, This is actually my first post after being a lurker for quite some time here. For the last couple of days I try to get my head around the concept of Overwatch's multiplayer architecture after watching the GDC 2017 talks by Timothy Ford ("Overwatch Gameplay Architecture and Netcode") and Dan Reed ("Networking Scripted Weapons and Abilities in Overwatch"). ( I hope someone here has Vault Access :D) As usual with such complex systems Overwatch seems to combine different approaches to hide latency. Among others, the ones I am mostly interested in are, Command Frames and State Synchronization. I think I understood both concepts but I have problems adding them up. 1) Ford talks about the client being in the future by ~ half the RTT plus one command frame. This ensures that all commands sent from the client to the server tend to arrive when the server is actually at the tick referenced in the command. If that's correct my assumption would be the following: Server is at tick 1000. RTT is ~ 10 ticks -> around 10*16.6 ms. Client simulates tick 1005 and sends command associated with tick 1005. <5 ticks later> Server is at tick 1005 and received a client command. (maybe its already queued in a buffer). Server applies command and sends state for tick 1006 (State_N + Input_N = State_N=1). RTT might still be 10 ticks. Client simulates tick 1010. <5 ticks later> Server is at tick 1010... Client received State for tick 1005 and checks internal buffers for prediction. Does that really apply? Does the client really simulate half-rtt in the future? 2) How do I handle ticks at the start of the game? My network layer requires a timestamp to work and I'd use ticks in the main game loop. Do I have something like a grace period until the client can calculate the required ticks to move to the future (by calling simulation.Tick(1/60f) for the number of ticks to be in the future)? 3) If I run the simulation at 60Hz and the network layer at say 20Hz. Do I have 60 Inputs that I send from Client to Server or 20? I know, this is somewhat similar to other questions in this forum, but I feel like this particular talk has never been discussed? Cheers, poettlr
  6. hi. I'm a programmer that I want to learn about game design fundamentals. as you may know there are lots of books that most of them teach the same thing. I want to know what are must to read and most important books that teach game design rules and fundamentals.
  7. I control the camera in my program by changing the transformation matrix (which alters the other underlying matrices). Not this is all in 2D. The transformation matrix is pretty standard. It is a 4x4 matrix with the diagonal acting as the scale factor (x, y, z) and the right side acting as the offset coordinates (this is ignoring shear and rotation which aren't that important to me though I would like the method to still work with rotation). So essentially I am currently zooming by altering the x and y scale in the transformation matrix. This seems to act from the top left corner (which is the origin in my coordinate space). I would like the zoom to act towards the mouse. So knowing the x and y position of the mouse when I apply my transformation (every frame) how should I alter the zoom so that it zooms towards whatever the mouse position was? I can share code if you would like but I am writing this in Rust. Also let me know if you need more information I am happy to provide I just didn't want to over share.
  8. I am about to start a PhD that will investigate ways of replicating creativity in the AI systems of simulated people in virtual environments. I will research which psychology theories and models to use in order to achieve this, with a focus on creative problem solving. The aim of this project is to create virtual characters and NPCs that can create new solutions to challenges, even if they have never encountered these before. This would mean that not every possible action or outcome would need to be coded for, so less development resources are required. Players would encounter virtual people that are not bound by rigid patterns of pre-scripted behaviour, increasing the replay value and lifespan of games, and the accuracy of simulations. I am looking for companies or organisations that would be interested in working with me on my PhD, and I think computer games companies might be the most likely. I am trying to think of ways in which this new AI system might benefit games companies, or improvements and new types of games that might be possible. I am on this forum to ask for your thoughts and suggestions please, so I can approach games companies with some examples. Thank you for your time and interest.
  9. Mark Simpson explains some fundamental principles anyone can use to improve their art, with examples and links for further reading.
  10. Corbbin Goldsmith

    Marketing I'm writing about games!

    Hi, everyone, For the last month, I've been building out my news site for developers of all sorts, and I cover games, apps, web apps, SaaS, you name it! If you want to have an article written about your game, contact me so I can get started! Requirements: A "playable" game A good idea behind it Um, that's about it. Just send me a message through my site. Articles I've written: https://www.theinspectorpress.com/news/dreamscape-168-z-run https://www.theinspectorpress.com/news/unlok-wayward
  11. Spool

    UI, for the love of God. UI..

    A couple months ago I decided to delve into the dark arts that are seemingly only attempted by the bravest of programmers. UI Framework development. While honestly I didn't fully understand what designing and creating a UI Framework from scratch truly entailed, I had some notion that it was no easy feat. As such should be approached with caution if not entirely avoided as the amount of UI Frameworks available are as numerous and the reasons not to make one yourself. But, I decided to embark on the journey anyway.. I guess the first big question you would ask is, Why? Why would you want to do that. To be honest, I asked myself that very question. The answer I came up with may seem rather shallow and the hallmark of an inexperienced developer.. They all suck. In *my* personal opinion anyway. Yes, they all suck. But that seems to be the norm in software development, we work with things that we don't really like because the idea of making the utility they provide ourselves is just as miserable if not more so than using the framework or tool in the first place. Anyway back to why all UI Frameworks suck. From hours and hours of scanning through endless lines of Desktop UI Framework source code repositories, I have come to two major conclusions about most if not all of them. 1: They all do WAY to much and try to handle every single feature, problem, platform, style, you name it. They end up bloated piles of code that seem to have no cohesive structure. 2: Everyone of them seem to have a ridiculous monolithic base Widget class that does EVERYTHING. So when you have a Screen full of Buttons you have all the infrastructure and memory requirements needed if you were to have a Screen full of Windows containing many other Widgets. Wasteful and unnecessary. To be honest, I can see why these traits are common. UI is complex. It needs to be reusable and flexible enough to fit into any application that wants to utilize it. Doing so in a clean concise manner is no easy task. Its very easy to indulge in the temptation of easiest implementation is the best implementation. After all, people need their UI's in a timely fashion. But what if we didn't do that? What if we really sat down and looked at how a UI operates, what it *needs* to do. What type of general structure would work best for those needs. This is what I decided to do. I decided that if I was going to make this, I was going to do it right. By my standards anyway. Next post I intend to go into my thoughts on how UI *should* be. If anyone read this. Thanks, feel free to yell at me in the comments.
  12. Hi, guys! I have a rather abstract question, because I don't know which side to approach to its solution. So, I would appreciate any information. I have a task to create a simple game that generates floor plans and I following by this perfect algorithm (https://www.hindawi.com/journals/ijcgt/2010/624817/). At the moment I use squarified treemaps (http://www.win.tue.nl/~vanwijk/stm.pdf) and here no problems. I create nested array in which elements are rooms with size. Problems starts when I trying to represent generated "rooms" as edges and vertexes (a, b, c, d steps in attached picture) That representation can give me access to this elements as special "entities" in future game versions. I don't have skills in graphs (and do I need graphs?) and at the moment totally stucked at this step. How can I represent room walls as trees (or graphs?) at this step? Calculate size of squares (rooms) and convert sides to a vectors? Then in loop find shared vectors (same position by "x" or "y") and determine them as shared walls? The instinct tells me that there exist more elegant and efficient ways. Anyway, thanks for any information about this.
  13. And so we meet once again to discuss what's new in the development of Lyfe. But as we promised on our Twitter this is something big. I don't have to tell you what we're discussing, you probably already read the title of this entry. I have to thank Jake Best who took the time draw the concept we developed for how the player will create the basic shapes for his cells. So let me explain what is going on here. You start off with just one central orb. This is your base node and your cell starts to 'grow' from it. There are arrows on four sides of this base node. If you pull on them new nodes will be created in that direction. This will create a kind of 'spine' for your cell. As shown in fig. 3 and 4 not only is the default setting when creating new nodes to the left or the right to make your cell symmetrical but you can also move your nodes/ bend the spines and the shape will be translated to the other side as well. You can also scale single nodes (fig. 5/6). This expands the cytoplasm around this node. The next thing is something we decided we needed but are not sure how to implement: a weight/thickness slider. This includes the overall amount of cytoplasm with a slight bias for filling up space between spines. Next step: placing organelles. Most organelles like Mitochondria or a Golgi Apparatus can only be placed on the inside of your cells but all organelles that are used for interaction with the outside world like Flagella or Pseudopodia have to be placed on the membrane. Organelles will have options to deform them, like elongating. Rotating them around the anchor point on the cell is also an option. Asymmetry is an option that not only affects the placement of the organelles but also the sculpting of your cell. In fig. 11 the right half of the cell is deleted resulting in this more potato shaped creation. Below are some possible results you might achieve with this toolset. For the two on the right, the dashed line represents their shape if the weight-slider was put to maximum and the one on the far left is a more experimental idea with actually two split nodes. If this will be possible in future is not sure yet, but we will see. That's it for this entry. Feel free to comment all your questions and suggestions. Keep on evolving! cellcreator.pdf
  14. Intention This article is intended to give a brief look into the logistics of machine learning. Do not expect to become an expert on the field just by reading this. However, I hope that the article goes into just enough detail so that it sparks your interest in learning more about AI and how it can be applied to various fields such as games. Once you finish reading the article, I recommend looking at the resources posted below. If you have any questions, feel free to message me on Twitter @adityaXharsh. How Neural Networks Work Neural networks work by using a system of receiving inputs, sending outputs, and performing self-corrections based on the difference between the output and expected output, also known as the cost. Neural networks are composed of neurons, which in turn compose layers, or collections of neurons. For example, there is an input layer and an output layer. In between the these two layers, there are layers known as hidden layers. These layers allow for more complex and nuanced behavior by the neural network. A neural network can be thought of as a multi-tier cake: the first tier of the cake represents the input, the tiers in between, or lack thereof, represent the hidden layers, and the last tier represents the output. The two mechanisms of learning are Forward Propagation and Backward Propagation. Forward Propagation uses linear algebra for calculating what the activation of each neuron of the next layer should be, and then pushing, or propagating, those values forward. Backward Propagation uses calculus to determine what values in the network need to be changed in order to bring the output closer to the expected output. Forward Propagation As can be seen from the gif above, each layer is composed of multiple neurons, and each neuron is connected to every other neuron of the following and previous layer, save for the input and output layers since they are not surrounding by layers from both sides. To put it simply, a neural network represents a collection of activations, weights, and biases. They can be defined as: Activation: A value representing how strongly a neuron is firing. Weight: How strong the connection is between two neurons. Affects how much of the activation is propagated onto the next layer. Bias: A minimum threshold for whether or not the current neuron's activation and weight should affect the next neuron's activation. Each neuron has an activation and a bias. Every connection to every neuron is represented as a weight. The activations, weights, biases, and connections can be represented using matrices. Activations are calculated using this formula: After the inner portion of the function has been computed, the resulting matrix gets pumped into a special function known as the Sigmoid Function. The sigmoid is defined as: The sigmoid function is handy since its output is locked between a range of zero and one. This process is repeated until the activations of the output neurons have been calculated. Backward Propagation The process of a neural network performing self-correction is referred to as Backward Propagation or backprop. This article will not go into detail about backprop since it can be a confusing topic. To summarize, the algorithm uses a technique in calculus known as Gradient Descent. Given a plane in an infinite number of dimensions, the direction of change that minimizes the error must be found. The goal of using gradient descent is to modify the weights and biases such that the error in the network approaches zero. Furthermore, you can find the cost, or error, of a network using this formula: Unlike forward propagation, which is done from input to output, backward propagation goes from output to input. For every activation, find the error in that neuron, how much of a role it played in the error of the output, and adjust accordingly. This technique uses concepts such as the chain rule, partial derivatives, and multi-variate calculus; therefore, it's a good idea to brush up on one's calculus skills. High Level Algorithm Initialize matrices for weights and biases for all layers to a random decimal number between -1 and 1. Propagate input through the network. Compare output with the expected output. Backwards propagate the correction back into the network. Repeat this for N number of training samples. Source Code If you're interested in looking into the guts of a neural network, check out AI Chan! It's a simple to integrate library for machine learning I wrote in C++. Feel free to learn from it and use it in your own projects. https://bitbucket.org/mrsaturnsan/aichan/ Resources http://neuralnetworksanddeeplearning.com/ https://www.youtube.com/channel/UCWN3xxRkmTPmbKwht9FuE5A
  15. Penkovskiy

    3 Game Design Mindsets

    (you can find the original article here along with future 2D monogame tutorials) It was a late Saturday afternoon as I began the walk across the crooked streets of the inner city. With a small tip-off from one of my trusted friends, I decided to go looking for this suspicious and mysterious looking man who usually hangs out behind Yarn’s cafe on cold nights like these. It was out of sheer desperation and utter determination that pushed me to get my hands on a rare type of night vision goggle that was off the market. As I located the shadowy figure behind the cafe, his face slowly illuminated as he moved into the light. It was easy to see from his worn and anxious face that it was urgent business that had brought him. Tracking this guy down was hard. After many wrong turns, a lot of false information, and a risky run-in with authority, I had finally located the dealer. But I noticed something strange. My friend from earlier had bought these goggles at a quarter of the price this guy was selling them for – I couldn’t believe it! His prices had actually raised significantly for night vision goggles… and only within a few hours… 3 mindsets you can use to design practically any system in a game – and KNOW it works When designing the nitty gritty numbers for your game, the process can be fun. It can also simultaneously feel like you would rather poke small, long needles into your eyeballs. How much damage does this flaming sword of skulls and bones deal? 5,000 hit points YEAH !!! It’s extremely easy to get carried away or end up with an unbalanced mess that ends up breaking your game at spots where you least expect it. There’s a specific reason I decided to fluctuate the price of popular items in my game’s black market, however, as you’ll learn below, the reasoning why is anything BUT random. I love balancing my games. Not just because I’m a complete nerd, but I also use a very refined and methodical system. I’ve always envied games that have a fairly large-ish (consistent) player base, mostly because of two reasons: They have access to a large amount of ‘statistical’ numbers we can test Getting a large and consistent player base to test your game from scratch is hard Is it weird that when I start getting a lot of players in one of my games, I track how many times each tile has been stepped on since the beginning of the game (and then continue to run it through a heat-map process that tells me how densely populated that area is)? (lighter areas are heavily populated) I know I know, I’m a complete weirdo. You don’t have to tell me. I design my games using 3 simple concepts and strategies that are extremely powerful. By following this strategic and methodical system, you’ll be able to rapidly test, move fast, and experiment further than if you were to just throw spaghetti at the wall and hope something sticks (like everyone else). I’ve read a lot of game design documents, and most are super boring, or too vague to really give me actionable advice. “Design with the player in mind!” What does that even mean? What does that look like when you’ve been awake for 40 hours straight staring at your computer screen, talking to yourself, questioning your sanity? Here are some unique things I did to my game’s market recently; Capped the amount of money players could hold. Inflated prices on popularly bought items with a slow decay time. Example equation: (price = 0.99*price + (1-0.99)*initial_value) called every second Fined players through money (something you don’t want players to do? Fine them heavily for it – you’ll quickly see that nobody is cursing anymore ) I made players have to repair their most used items with money. Why did I make these decisions? I’m not just waking up one day and saying “Let’s fine the players! They suck!” Each decision was based upon testing and previous data, ran through this framework. If I thought it would be beneficial to fine players when they curse, I would first spend 5 minutes making a code that tracks how many times players curse and store it in a log. I’d look at it a week later, and based on how often players curse I would decide if fining them would have an effect on the economy. Money inflation is a problem in most multiplayer games, but using a systematic approach that I’ll show you below, you will always know which lever you need to pull to get your game on the right track and finely tune it like a well-oiled machine (no matter what problems you’re facing). Step 1. A benchmark is something simple to track. Follow me through an overly simplified rpg “leveling up” process. A player starts at 50 health. Each level, they gain 10 health. The max level is 20, meaning the max health is 250. The most powerful weapon in the game deals 10 damage per second. The most powerful armor in the game protects 80% of damage. It would take (~2 minutes, or 125 ‘hits’) to kill the strongest player in the game who’s wearing the strongest armor in the game while you’re using the strongest weapon in the game (assuming every hit lands while both of you are running around). These are what I call benchmarks. With these benchmarks, it’s infinitely easier to see exactly how balanced your game is from an overhead angle. Step 2. Working Backwards By knowing your benchmarks, it’s infinitely easier to decide “I don’t want it to take 2 minutes to kill Bob, I want it to take 1 minute” — rather than continuously guessing why it takes the strongest weapon so long to kill bob but one hits everything else. Knowing this, you can adjust each variable accordingly to set an accurate (to what you feel is right) amount of time it takes to progress in the game. Just from our benchmarks alone, we can adjust the following variables: Bob’s max health Bob’s health gained per level Percentage of damage our armor deflects Bob’s speed slowed by his armor (changes combat dynamics) Speed of the top performing weapon (1 hit per second to 1 hit per 2 seconds) The damage of the top performing weapon With this mindset and formula alone, we are already 98% ahead of where you were before (and where most people are when designing games). Notice when most people react to an overpowered weapon, they usually just turn the damage down without knowing A.) Why they are doing it and B.) What their ultimate target is We could even get creative and introduce new designs to balance this. Weapon damage is (reduced or multiplied) by a percentage based on player’s overall level. Health gained per level can slowly decrease (from 10 down to 1) by every level closer to the maximum level allowed. Changing the percentage of damage our armor deflects based on player’s level How easy do items break? By striking the best armor in the game, does it destroy an item faster? If so, would your weapon be destroyed within the amount of time it would take to kill Bob? It can get complicated very quickly, but that’s why we test each change we make to the game one at a time, develop data, and make decisions accordingly. Step 3. Building a finely-tuned machine (perhaps the most important step of all) We can debate, and ponder, and guess all we want about how to balance a game. How to design your game. I know first-hand because I love doing it. It’s fun. It’s fun to dream about how great your game could be, and romanticize about some kind of super complex chemistry mixing system with its own periodic table of elements where player’s can mix to change their genetic codes to enhance stats or change appearances and give them special abilities, and what would happen if blah blah blah. This, my friends, is where I’ve seen more “indie game devs” fail than what I call a ‘dish graveyard’. When I used to work for Dish installing satellite cable, I would see stuff like this. When old people moved out and new people moved in, they would change service, or in most cases, a new dish was just put up because it was easier than adjusting/tracing cables back/swapping parts off an old dish. It was easier to just throw up a new dish. And I say Indies because I’m a fellow indie who’s been plagued by this. I say Indies because most don’t have a team pushing them to focus on their most important KPIs (key performance indicators). It’s fun to make up ideas, get halfway through a project, and come up with some other random idea that you just have to try because motivation strikes. Riding that high of motivation, you jump to the next project, eventually getting bored of that until the vicious cycle begins to repeat itself. We can conquer this by using small tests and tracking our KPIs. We have the ability to test literally anything within our games — and that gets my inner nerd all fluttery and excited. I track things like how many times an item is bought in a specific period of time. I track how often that same item is discarded. If you aren’t tracking stats like these, shame on you! However, we can get super carried away real fast trying to track everything. What do you think is more important to track? How many times a player gets killed (for no specific reason) or; How quickly a player is leveling up (in general) Setting KPIs in the initial phase This is where you need to get solid on specific KPI’s first, preferably straight from the initial design phase. These Key Performance Indicators are going to be the most important benchmarks that you need to hit in your game. They will guide you towards the things that are most important now, and steer you away from the wrong things that will cause you to lose focus. If I were just starting out making a game, my KPIs would be the most basic – Player movement engine (with collision) Basic player animation (walking) Bear bones interaction system If I was trying to balance a weapon, my KPIs would probably look like this; Strongest weapon in the game takes 5 minutes of combat to kill the strongest player in the game Strongest weapon in the game takes 1 minute of combat to kill the weakest player in the game Simple benchmark to hit. The goal is to get something up and playable ASAP so we can begin testing different things with the players. This is another fatal mistake I see so many people make. They spend months (sometimes years) creating this super complex combat-combo-style-point system, only to release it to few (if any) players — (because the developer didn’t want to let people play the game when it wasn’t ‘perfect’, they couldn’t develop a pre-alpha player base) And come to find out, the players hate it. Small test loops is where the real magic happens Using previous benchmarks and data from extensive testing and player feedback, we iterate through small loops. Take action and test based on a small change in our benchmark. Did we hit our KPI? (Did our KPI change?) Repeat. You can only plan something so far. When your work meets the real world, it’s the fine-tuning that will push it over that ‘excellent line’. Because in reality, your players are the market, and as much as it sucks to hear, no matter how much you liked putting in that lizard sword machine gun, if nobody uses it, buys it, or it can kill anything with 1 hit, you will have to adjust it to your player’s (market) demand. Unless you are tracking, planning, and hitting your KPIs (the only things that matter in the initial phase), you’ll easily get sidetracked, overwhelmed, start looking at the wrong things, make bad design decisions, and eventually, lose focus.
  16. Resources about how to implementing DIY DRM scheme on the web are limited. Requirements: Convenience and not annoying for the User User account for update and online features Watermarks Product key Code obfuscation Respect fair dealing Other such things: Easter egg, Trading Cards, Stats, Achievements, Modding, Leaderboards, and Unlockables. Any resources? ( some links, articles, posts, books, tips or best practices)
  17. Hello there everyone. I want to make a game inspired by Mass Effect, but there are a few general storytelling in video games problems that I'm trying to figure out, before I really get down to making the game. I've been thinking about it a lot, so it will be a bit of a longpost, but thinking in a bubble is never a good idea, so I ask for your help in solving these problems and criticism of my solutions. Any feedback is appreciated. I believe that these problems are interconnected, so I will present them here together and then present ideas that I have about addressing them. Problems Player character can't lose This is the biggest one. And it is not as simple as it may sound. In a lot of games, Mass Effect included, it is impossible for player character to lose an engagement with an opponent. The player can lose a gameplay section, but it doesn't result in player character losing, you just load a save and try again. Witch means that there are no stakes, not really. You can present a story in a way that creates an illusion of stakes, but after playing a couple of times, player realizes that they will defensively win eventually, so it becomes more frustrating then challenging. If you really need player character to lose for story reasons you only have two choices: create a gameplay section that is impossible to win and show a cutscene after one attempt or just show a cutscene where player character loses. Both feel cheap and betray trust between the game and the player. On the other hand, if you take away the ability to load a save at any time, you are presented with two other problems. 1. How do you handle player character's defeat? What exactly happens mechanically if you fail a mission? Does the character die and you have to start the game over? Do you need to write a story for every possible encounter going bad? 2. In a video game, you need to give player time to understand and practice game mechanics. You can't expect player to just be good at your game from the get go, so it feels a bit unfair to just throw them into important story missions that they can't replay and then present them with consequences. Choices that don't matter This is a very common problem in games. Often player is presented with a choice, that seems important, but doesn't really affect anything or affects things, but ultimately doesn't matter. Like: do you kill this person or let them go? witch of this two groups do you support? witch color do you like more red, blue or green? In my opinion, this is very closely tied to the first problem, that player can't lose. Imagine that you are an all-powerful godlike being that can time-rewind-magic their way through any presented problem, what can possibly matter to you? What consequence can you really feel? You could set up a system where your choices affect your relationships with other characters, but in this case you have no reason not to cater to those characters, because no other consequences matters. Linearity of the story This one is a result of the first two. If you can't ever lose and non of your choices matter then the story can only really unfold one way with minor deviations. So if you want to make the story not linear you basically have to make two or more different stories and let player choose witch one do they want to see, choose you own adventure style. Witch is not necessarily bad, but is very cost inefficient and difficult to produce. Solutions Conflict instead of a story All stories are based in conflict. But each story is only one example of how a conflict could unfold. When we tell a story in a video game we basically choose a way this conflict will go and take player through it one step at a time without ever showing them the whole picture. Why not instead present player the conflict itself in its entirety and let player try to solve it themselves? An example that I can think of is Total War games. In Total War you have a campaign map and individual battles. Telling a story is like defining everything that will happen on the campaign map in advance and only letting player win the battles. Presenting a conflict is like giving the player full control of their armies both on the campaign map and the battlefields. Separation of practice and performance Just giving the player full control over the conflict is not enough. We still need to address the whole time-rewind-magic thing. My idea is to create some sort of practice mechanic for the player to learn the game. It can range from letting player play the mission itself in practice mode, to only letting player practice individual mechanics (like a fight with a set of enemies), to anything in between. I personally would introduce some randomness into the missions and let player just play through them as many times as they want. Then, when player had enough practice, it's time to play the mission for real. Player gets one attempt and that's it. What those two ideas would achieve (in theory) When it comes to "Player character can't lose", together these two ideas address all underlying problems. It allows player to practice, it allows player character to lose and it sets up an overarching system of the conflict that defines what happens if player wins or loses and where the narrative goes from there. These ideas together help to create a more complex and believable system for choices. Since player can lose, they must consider not only what they want or what other characters want, but also what can they achieve in gameplay and what gameplay consequences each choice may bring. Finally, since you have full control over the conflict it creates more diversity in how the narrative can unfold, including player's complete defeat. What are problems that these ideas bring Nothing is perfect, so here are the problems that I see in these ideas. Less control over the narrative This is pretty obvious. If you give player full control over the conflict you can't reliably set up scenes, events or set pieces, because they may not take place in some playthroughs. You can guide the player in a particular direction, but you can't force them. Having to design campaign level gameplay and mechanics This is also pretty obvious. If you present player with the whole conflict you need to figure out what does the whole conflict look like, its rules and limitation. And create gameplay mechanics, that will govern it. Difficulty in presenting the narrative When the narrative is so diverse, it gets more difficult to figure out, how to present it to the player. I would tie missions to characters and present most of the story through character interactions before, during and after missions. Player can lose The opposite of the problem that I'm trying to solve is the problem of player losing. If player can lose each individual mission, it means that they can lose the conflict, the whole thing. Imaging putting 20 hours into a game only to lose it in the end. Imagine in Mass Effect 1 you lose to Sovereign in the end, reapers come through the citadel mass relay and destroy the galaxy, how would you feel? I'm not really sure how to address this problem and weather or not this problem should be addressed. So what do you think? Are these problems relevant? How would you solve them? Do you think my ideas can work? Do you see any flaws in my ideas? Do you have any other comments or feedback?
  18. The search for intelligent individuals has begun. Are you ready for the first step, PLAYER ONE? Sometimes, it's easier to find what you're looking for if it comes looking for you. The first clue is hidden within this GIF . Can you find the pattern? Can you crack it? Find it, and it will lead you on the road to finding us. We look forward to meeting the few that will make it all the way through. Good luck. #decipher #cryptography #steganography #geek #puzzle #crypto #readyplayerone #outguess #cicada 3301
  19. We're back with another update. First a little recap of what happened this week: We got our own banner and logo. Thanks go out logomakr.com where we made it. Our website is now in develpoment. I got no idea when it will be online but we're working on it. We started using Taiga.io to manage the development. It was frustraing to just have a good a idea or realised something that needed fixing/reworking in the concept and just forget about it or have it in an unorganised text file. We got a new team member: Helices, who will function as a Biology Advisor to this project. On that note: We are reworking the cell stage to be more realistic (as far as it doesn't sabotage fun gameplay in any way). We will do another entry on that once we deem it presentable. On the actual development front: The procedural meshes now work mostly as intended. They are being generated randomly from a basic cube shape with 26 vertices. For now that should work and adding more is basically just busywork if we really need more than that. When the player collides with this mesh all vertices with a distance to the player that's within a certain threshold will move away from the player based on a vector from the player center to the vertex. This functionality is planned out so far but not implemented. Slicing the mesh will be the next, more complicated step. Next thing I will be working on besides the website: The procedural environment. Since it would be pretty silly to just but up barriers around the map it should be infinite. To make this feasible all content has to be procedurally generated around the player. Logically it will be deleted again as soon as the player has a certain distance to it. This is true for all passive, floating objects, compound clouds and other cells. The distance should be high enough to feel natural for there to be change but also not so high that it affects the framerate. The rework on the cell stage results in there being five new compounds replacing the previous ones: CO2, Oxygen, Amino Acids, Glucose and Lipids. The will definitely be differentiated by their color and maybe by the shape of the clouds if it is deemed useful for the player and doable for a programmer. Interaction with other cells will be an interesting part. I don't want to unveil anything that will be part of the cell stage rework but I'll tell you everything we have for certain: To absorb other cells you simply have to move over them. If you have 30% more mass than they do - which is calculated via your organelles and your cytoplasm - you will absorb them and vice versa. One thing we want to get sort of experimental with is sound. Despite the background music there will be no ingame sound effects. And even the background music will mostly consist of some atmospheric sounds. So far there was no time to prototype this but we will try to get to it soon but for now planning and coding has a higher priority. That's it for this week's update. I'll leave you with a little insight into our code with which we generate the compound cloud mesh. void ACompoundCloud_Cell::CreateCloudMesh() { //vertex buffer //TArray<FVector> vertices; //Front vertices.Add(FVector(50.f, -50.f, -50.f));//0 vertices.Add(FVector(50.f, 0.f, -50.f)); vertices.Add(FVector(50.f, 50.f, -50.f)); vertices.Add(FVector(StaticMaths::RR(50.f, 150.f), StaticMaths::RR(-150.f,-50.f), 0.f)); vertices.Add(FVector(StaticMaths::RR(100.f, 200.f), 0.f, 0.f)); vertices.Add(FVector(StaticMaths::RR(50.f, 150.f), StaticMaths::RR(50.f, 150.f), 0.f));//5 vertices.Add(FVector(50.f, -50.f, 50.f)); vertices.Add(FVector(50.f, 0.f, 50.f)); vertices.Add(FVector(50.f, 50.f, 50.f)); //Left //2 vertices.Add(FVector(0.f, 50.f, -50.f)); vertices.Add(FVector(-50.f, 50.f, -50.f)); //10 //5 vertices.Add(FVector(0.f, StaticMaths::RR(100.f, 200.f), 0.f)); vertices.Add(FVector(StaticMaths::RR(-150.f, -50.f), StaticMaths::RR(50.f, 150.f), 0.f)); //8 vertices.Add(FVector(0.f, 50.f, 50.f)); vertices.Add(FVector(-50.f, 50.f, 50.f)); //Back //10 vertices.Add(FVector(-50.f, 0.f, -50.f)); //15 vertices.Add(FVector(-50.f, -50.f, -50.f)); //12 vertices.Add(FVector(StaticMaths::RR(-200.f, -100.f), 0.f, 0.f)); vertices.Add(FVector(StaticMaths::RR(-150.f, -50.f), StaticMaths::RR(-150.f, -50.f), 0.f)); //14 vertices.Add(FVector(-50.f, 0.f, 50.f)); vertices.Add(FVector(-50.f, -50.f, 50.f));//20 //Left //16 vertices.Add(FVector(0.f, -50.f, -50.f)); //0 //18 vertices.Add(FVector(0.f, StaticMaths::RR(-200.f, -100.f), 0.f)); //3 //20 vertices.Add(FVector(0.f, -50.f, 50.f)); //6 //Bottom //16 //15 //10 //21 vertices.Add(FVector(0.f, 0.f, -50.f)); //9 //0 //1 //2 //Top //6 //7 //8 //23 vertices.Add(FVector(0.f, 0.f, 50.f)); //25 //13 //20 //19 //14 //index buffer //+++++ Front //Lower Left indices.Add(3); indices.Add(1); indices.Add(0); indices.Add(1); indices.Add(3); indices.Add(4); //Lower Right indices.Add(4); indices.Add(2); indices.Add(1); indices.Add(2); indices.Add(4); indices.Add(5); //Upper Left indices.Add(6); indices.Add(4); indices.Add(3); indices.Add(4); indices.Add(6); indices.Add(7); //Upper Right indices.Add(7); indices.Add(5); indices.Add(4); indices.Add(5); indices.Add(7); indices.Add(8); //+++++ Right //Lower Left indices.Add(5); indices.Add(9); indices.Add(2); indices.Add(9); indices.Add(5); indices.Add(11); //Lower Right indices.Add(11); indices.Add(10); indices.Add(9); indices.Add(10); indices.Add(11); indices.Add(12); //Upper Left indices.Add(8); indices.Add(11); indices.Add(5); indices.Add(11); indices.Add(8); indices.Add(13); //Upper Right indices.Add(13); indices.Add(12); indices.Add(11); indices.Add(12); indices.Add(13); indices.Add(14); //+++++ Back //Lower Left indices.Add(12); indices.Add(15); indices.Add(10); indices.Add(15); indices.Add(12); indices.Add(17); //LowerRight indices.Add(17); indices.Add(16); indices.Add(15); indices.Add(16); indices.Add(17); indices.Add(18); //Upper Left indices.Add(14); indices.Add(17); indices.Add(12); indices.Add(17); indices.Add(14); indices.Add(19); //Upper Right indices.Add(19); indices.Add(18); indices.Add(17); indices.Add(18); indices.Add(19); indices.Add(20); //+++++ Left //Lower Left indices.Add(18); indices.Add(21); indices.Add(16); indices.Add(21); indices.Add(18); indices.Add(22); //Lower Right indices.Add(22); indices.Add(0); indices.Add(21); indices.Add(0); indices.Add(22); indices.Add(3); //Upper Left indices.Add(20); indices.Add(22); indices.Add(18); indices.Add(22); indices.Add(20); indices.Add(23); //Upper Right indices.Add(23); indices.Add(3); indices.Add(22); indices.Add(3); indices.Add(23); indices.Add(6); //+++++ Bottom //Lower Left indices.Add(21); indices.Add(15); indices.Add(16); indices.Add(15); indices.Add(21); indices.Add(24); //Lower Right indices.Add(24); indices.Add(10); indices.Add(15); indices.Add(10); indices.Add(24); indices.Add(9); //Upper Left indices.Add(0); indices.Add(24); indices.Add(21); indices.Add(24); indices.Add(0); indices.Add(1); //Upper Right indices.Add(1); indices.Add(9); indices.Add(24); indices.Add(9); indices.Add(1); indices.Add(2); //+++++ Top //Lower Left indices.Add(23); indices.Add(7); indices.Add(6); indices.Add(7); indices.Add(23); indices.Add(25); //Lower Right indices.Add(25); indices.Add(8); indices.Add(7); indices.Add(8); indices.Add(25); indices.Add(13); //Upper Left indices.Add(20); indices.Add(25); indices.Add(23); indices.Add(25); indices.Add(20); indices.Add(19); //Upper Right indices.Add(19); indices.Add(13); indices.Add(25); indices.Add(13); indices.Add(19); indices.Add(14); TArray<FVector> normals; for (int i = 0; i < vertices.Num(); i++) { normals.Add(vertices[i] / vertices[i].Size()); } TArray<FVector2D> uv0; TArray<FProcMeshTangent> tangents; ////The colors applied to every vertex and blended on the surfaces TArray<FLinearColor> vertexColors; mesh->CreateMeshSection_LinearColor(0, vertices, indices, normals, uv0, vertexColors, tangents, true); //Enable collision data mesh->ContainsPhysicsTriMeshData(true); mesh->bUseComplexAsSimpleCollision = false; mesh->SetSimulatePhysics(true); } If you made it to this part you probably read the code and in that case: We are still looking for anyone who wants to contribute to this journy into the unknown. And please don't look at me like that, the code is functional if not beautiful. Thanks, bye.
  20. "You can't call any one game design bad, really. Like all art, it either speaks to you or it doesn't. If it only speaks to a few, it's just niche." Some friends and I were arguing about esoteric game designs and whether or not you can ever really classify bad design objectively when one made the above assertion. I'm curious if you agree or disagree and why. Is a game design good simply because it is popular and therefore enjoyed, or as with narrative art are there underlying elements that a game can hit or miss, rendering it good or bad? If you don't like it, are you simply not the target audience? I'm of the mind that games make something of an aesthetic contract with players: Not simply 'this game is about shooting' or 'this game is about racing' but rather a series of promises that can be said to be embedded in all of the elements presented-- from the sound design to the UI to the mood and tone of the world presented and most importantly the interactions and responses given by the simulation itself. "I promise you the gritty, harsh reality of a Special Operator behind enemy lines" or "I promise you the zany, action-packed experience of rocket powered cars that launch balls into goals." To illustrate this idea, consider a perfect, hyper-realistic modern military stealth game. It's balanced, the levels are interesting and the choices offered are consistently engaging. Now make the UI bright & cartoony. A bit jarring? Swap the enemies with big, red nosed, ridiculous clowns. Gameplay is still the same, it might be funny, but did you originally buy it for funny? I would argue that the implied contract with your player is stretched to breaking or outright broken, and that THAT more than anything else, without some kind of upfront warning or easing of sensibilities, makes for bad design. This breaking of the aesthetic contract with the player can extend right through the inclusion or exclusion and construction of gameplay elements itself. "Crafting is fun! Let's introduce wear and tear to weapons in our gritty Special Operator game and have the player hunt around the level for parts!" But you're a member of the best equipped, best prepared fighting force in the world. Doesn't this turn you into some kind of camouflaged, scavenging murder-hobo? I think it would break the contract, break the implicit expectations of everything that comes to mind when you think about "special forces" and thus blunder right into bad game design. What do you think?
  21. aymen

    centroid from vertices

    please any know how can i' calculate the centroid from any number vertices
  22. Mercury Gate

    NPC in the rankings

    How do you feel about having computer controlled players holding a place in the top 100 list? In a competitive game I am thinking about, players can combat each other to grow their character as well as fight computer controlled characters. But when the players look at the rankings, should they NPC accounts be included. Without the NPC in the rankings, you could see that you are ranked #19, the player in #18 place is stronger than you by 5 levels, but when you go to fight the other characters that are your level, you cannot see #18 because he is too strong, so all you fight are the NPC and players weaker than you but with in your attack range. This could be misleading to the player as they feel they are stronger than they really are. And with NPC accounts in the rankings, player can really see how they rank up to other accounts that are as strong as them. They can see how many accounts stand between them and the next rank. On a side note, some NPC accounts are marked as NPC while others are not.
  23. antoniorv6

    Starting in Videogame Music

    Hi there! Well, as the subject describes itself. I would like to start in videogame music and composition. I do know some Music Theory and have some notions on how to play the piano, and also in my Degree we have some subjects refered to Sound and Music, but I would like to go a little bit deeper. Anyway, I'd like to know if it there is any site, course, or bibliography refered to all of this, even if it starts from the basic of the basics. Also would be interesting if it is there any good reference to study all the software related to the theme. It would be great if anyone could give me some advice, because now I am a little bit lost. Thank you!
  24. Dear game developers – I'm currently working on my graduation work. As part of my bachelor thesis at Bremerhaven University of Applied Sciences, I examine to what extent the F2P business model can influence the long-term competitiveness of games. The Work focuses mainly on MMO games because of their long lifespan. Part of the work relates to developers and the impact of the F2P business model on them and their decisions when developing games. I have created six short questions that will help me to better understand this influence. The questions mainly relate to business and publishing sides of game development. I would like to ask you, if some of the developers here could answer these questions. Those of you who are interested, please send me a private message until March 16th and I will get to you with further details as soon as possible. Your contribution is greatly appreciated and it will help me to improve my thesis. Thank you
  25. This article was first published on https://medium.com/@ricardo.valerio/make-it-difficult-not-punishing-7198334573b8 Difficulty plays a big role in keeping players motivated, engaged and, unintuitively, in marketing. Some games have it better designed than others. Some design it even to make it satisfyingly hard, like Dark Souls. But others have it poorly designed, with a very high difficult bar set from the very start, or none to little difficulty altogether, combined with too steep or too shallow difficulty increase. So how do we go about designing good difficulty? The first thing that we need to do is to define difficulty. What is difficulty? Difficulty is the amount of skill required by the player to accomplish a goal or progress through the game experience. It can be as simple as jumping from one platform to another, killing a character, defeat a boss fight — which could be designed respectively to be easy, medium or hard to accomplish. Difficulty goes hand in hand with the challenge presented and the skill of the player related to that challenge and the game. Present a too high challenge for a less skilled player, and it becomes a hard barrier from which players can turn away from; present too little challenge for high skilled players, and it won't be interesting for them. The optimal difficulty is one in which the challenge presented is always slightly greater than the skill of the player when he first encounters it, so defeating the challenge provides a climax, small or big, and satisfaction. This provides for an optimal flow state, where the player knows accomplishing the goal is possible, and investing energy will provide for a satisfying resolution. Mihaly Csikszentmihalyi, a Hungarian psychologist, proposed the following graph that defines flow as the channel where there is an optimal level of skill vs. challenge. Difficulty is the amount of skill required by the player to accomplish a goal or progress through the game. Later on, he proposes a more detailed mental map, matching certain areas of skill and challenge to specific mental states. Image from https://en.wikipedia.org/wiki/Flow_(psychology) As we can see here, a difficult challenge for an average skilled player will at first provoke arousal — the player knows it’s hard right now, but it is within his grasp, and he only needs to become a little more skilled, or perhaps acquire an ability that is key for the challenge, and become skilled at it. But eventually, a player will be in full control of the challenge, as riding a bike. And over time, it will become a somewhat relaxing, or boring, activity. So it’s important that to keep players engaged, more difficult challenges must be presented, or alternatively, different ways of accomplishing goals and avoiding having a single solution for resolving them. So if the player does defeat a challenge, it is always possible to increase their mastery by going back and trying to make it better. And this leads us to motivation. Motivation So what drives someone to perform an activity? We can separate motivations into two categories: intrinsic and extrinsic. When someone is intrinsically motivated, he performs the activity because he likes it, it is satisfying, regardless. An extrinsically motivated person, however, will perform for an external reward — praise, fame, an item, an achievement. Because of this, an extrinsically motivated player needs external factors, but on the other hand, an intrinsically motivated player has his own flame of desire to perform a task. This is important to understand because whenever possible, the primary motivations that should be focused on are the intrinsic ones. This leads us to Self-Determination Theory. The theory states that humans have three fundamental needs, as described in its Wikipedia page: Autonomy, or “to be causal agents of one’s own life and act in harmony with one’s integrated self” Competence, or “seek to control the outcome and experience mastery” Relatedness, or “ the universal want to interact, be connected to, and experience caring for others” Directly connected to skill is competence. It is important for the player to feel he can use his mastery and feel he can control the outcome. Designing good difficulty We know that difficulty will derive from the challenge presented and the player’s skill. Skill is a combination of mental and physical effort and capabilities, which culminate in mastery. And players can vary heavily in skill, depending on their previous experiences, motor skills, cognitive capabilities in the game context, etc. But on the other hand, challenge is easier to define and can be designed to require an increasing amount of mastery. What is a good challenge? The problem mostly lays in defining good challenges. Consider these two boss fights: The boss will randomly kill a player every 5 to 10 seconds without any kind of warning The boss will every 10 seconds place a deadly void zone on the player’s feet, that will explode after 3 seconds and kill anyone on top of it The first one is very punishing, and there is nothing the player can do about it, no matter how much skill he has and earns. But if we look at the second boss, we have many elements that provide a great challenge and promote learning: There are cues The player can react to it There is feedback The player can, therefore, increase his skill in dealing with it Consider riding a bicycle. First times, we are clumsy, lose balance, go slowly. Over time, we focus rather more on the environment than the process of riding the bike itself, because we already are familiar with it, we learned the required techniques for each activity, such as pedalling, balancing, braking, turning, and our skill is high. Same with video games. A good activity should be learnable, to such an extent that it can become mostly automatic, so we can focus on reacting to the environment. A good challenge should present cues, allow a reaction and provide feedback, so when the player fails, he will feel that he could have done better. This will foster learning and increase of skill. If we look at any boss fight in World of Warcraft, we can see they are carefully designed to always provide cues, feedback and allow the player to react. All the mechanics are carefully set in the fight to make it possible to accomplish without it being overly frustrating. The goal is always within reach, and practice takes the player closer to defeating it. Difficult raid bosses have a set of abilities, and sometimes phases in the fight, that as they are defeated get the raiding team steps closer to defeating the challenge. This has a potent effect because as players get closer to their goal, tension rises and builds towards a climax. And after hitting the climax, it provides a great deal of satisfaction — even euphoria and shouting, I have witnessed it first hand with my own guild. A challenge doesn’t need to be solved in the first attempts. But there should be a sense of progress. Even in games as difficult as Super Meat Boy, where a player dies multiple times before clearing a level, players remain engaged. There are clear visual cues of the threats, there is a great deal of feedback, and after death, the player character respawns quickly. With each attempt, the player learns what works better. Perhaps timing, or jumping closer or farther from an edge, etc. When Flappy Bird went viral in 2014, players were raging with the difficulty of the game. A quick search reveals a plethora of videos with raging players. And yet, it went viral, and people were relentlessly trying to get better at it. The fact that cues were presented and the player could react means that there is a chance to become skilled. And it is in fact so hard, that just passing a few pipes can be a reason for bragging and a great sense of one’s growing mastery. Artificial vs Designed difficulty We can add difficulty in two ways: artificial or designed. Designed difficulty is when you design a boss with a certain set of abilities, perhaps adding or removing depending if you are doing a raid with 10 or 25 players, or a hard mode. It is difficulty which requires learning new skills or using them in a certain way, as opposed to just performing better with existing ones. Generally speaking, artificial difficulty is about changing stats. Designed difficulty is about introducing or combining different mechanics, which force the player to learn and master specific skills. Examples of artificial difficulty are increasing health, defences, attacks, number of enemy characters or reduce the time limit if it exists. Examples of designed difficulty are the boss getting a new ability, different kinds of enemies joining the fight or requiring coordination with other players. Artificial difficulty is cheap. It’s easier to tweak than designed difficulty. But at the same time, it might feel cheap for the player. If by going hard mode only changes stats, then the player won't get anything new out of it — unless it challenges his assumptions and forces him to be creative or rethink his strategy. For example, a boss that beats much harder and for longer periods might force the players to rotate their survival abilities carefully; and in team efforts, it might even lead them to coordinate survival abilities. To make a point, imagine a game where you have only one single enemy character that appears with increasing amounts of health and attack. Now imagine one where the enemy characters vary in abilities. The first would become boring faster, and the second one has more chances for using skills differently. As with everything, moderation is key. Use both and combine them to present the best challenge for the player. But it’s not just boss fights While boss fights are in many games a point of climax, and therefore usually are taken more seriously when it comes to difficulty, it doesn’t stop there — in fact, it doesn’t even start there. Setting the difficulty starts right from the beginning of the game. As simple as learning movements, learning to jump, use a skill. The initial game experience of the player is crucial to sparking the desire to play and keep playing. In Super Mario Bros, the player starts with an empty scenario and is left with the only option which is to move. Then he is presented with a cube with an interrogation mark, which will likely trigger curiosity and try to interact with it. Soon after, the first NPC appears, he looks angry and moves towards the player — there are signs he is a threat, and the player needs to react to it. If he touches it, Mario will die — feedback — and the player learned he can’t touch them by walking to them — he has to try something else. The most likely step afterwards will be to try to avoid or jump on top of it, as to smash it, and there will be feedback that the player successfully defeated the challenge presented — his skill level now allows him to deal with these type of NPCs successfully. From the start, the player feels he is learning. Wrapping it up When designing good challenges, it is important that the player is able to learn from it and increase his mastery. In order to do that, we should present cues, visual, audio, vibration, etc, that signal the player something is about to happen. This creates an opportunity to react, and eventually prove one’s mastery. And finally, there should be feedback. With each attempt, the player will become more skilled, defeat the challenge and become satisfied. If the player fails, you want to have him feel there was something better he could have done, and not leave him frustrated and helpless. Avoid having single solutions to defeating a challenge and let play sessions vary — this allows the player to get better, as opposed to a static solution. Make it a difficult challenge but within reach. And avoid making it punishing. Conclusion We went through a definition of difficulty, what drives players, and what is an optimal difficulty level that promotes flow. Allowing the player to learn is fundamental, which ultimately drives progress, and gives a sense of competence and autonomy. And in the end, players will want to seek more challenges. So when it comes to difficulty, make it hard, but not punishing. Stay tuned Stay tuned for follow-ups on this series on game design, where I will explore other aspects that help to deliver a great experience to players and create great games. Follow me on Medium If you liked this article, please upvote or leave review or comment to let me and others know you found this useful, I would be very happy and greatly appreciate it. Thanks!
  • Advertisement
×

Important Information

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

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!