• Advertisement

Search the Community

Showing results for tags 'Theory'.



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

  • News

Categories

  • Audio
  • Visual Arts
  • Programming
  • Writing

Categories

  • GameDev Unboxed

Categories

  • Game Dev Loadout

Categories

  • Game Developers Conference
    • GDC 2017

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
  • Topical
    • Virtual and Augmented Reality
    • News
  • Community
    • GameDev Challenges
    • For Beginners
    • 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
  • Workshops
    • C# Workshop
    • CPP Workshop
    • Freehand Drawing Workshop
    • Hands-On Interactive Game Development
    • SICP Workshop
    • XNA 4.0 Workshop
  • Archive
    • Topical
    • Affiliates
    • Contests
    • Technical

Calendars

  • Community Calendar
  • Games Industry Events
  • Game Jams

Blogs

There are no results to display.

There are no results to display.

Marker Groups

  • Members

Developers

Developers


Group


About Me


Website


Industry Role


Twitter


Github


Twitch


Steam

Found 46 results

  1. MMO Design Theory

    When designing a game I've found that whatever the genre it can be boiled down to one thing: designing meaningful progress for the player. It sometimes seems that the MMO genre is too complex to break down in such a way but in general terms, the design seems to be about progression in key areas like Character, Exploration, Crafting, Combat, Travel, and Community. What do you think is a necessary part of an MMO's design? How would you design features for one if you were focused on increasing the player base and retaining them? What factors are especially important to consider in the design process?
  2. Hi, I'm currently studying physically based shading in UE4 described in Real Shading in Unreal Engine 4. In the notes, the Material has 4 basic properties: BaseColor, Metallic, Roughness and Cavity. Here is their BRDF model in use: The use of roughness is clearly clarified, and I guess BaseColor is referred as \(c_{diff}\)c_diff in the diffuse component. Then anyone knows how Metallic and Cavity is implemented in UE4? Exact fragments in the source code of the engine would be the best. Thanks a lot!!
  3. Comic book inspiration I want to make it clear that the game is highly inspired by my comic book experience. I am a big fan of Garfield, Gaston LaGaffe and Charlie Brown. I find the 9th art to be a very subtle, intelligent way to make people think and smile. Doing cartoon was always something I was proud of. I first started doing them when I discovered about Nabuchodonosaure cartoon and "Le concombre masqué". They triggered something inside me to start producing my own. My graphic style was Charlie Brown and Garfield as it was very simple and efficient. I want the game to feel like you are part of that background. I like how things look graphically, how anything can happen. More specifically I produce the Recontre du 3e type cartoon book which was self publish and sold locally in my home town. 500 copies were sold, which is not bad considering the market. Despite the book didn't make it to the big league, it was show case in the International comic book fare of Quebec and at the Salon du livre jeunesse. I was very proud of it and had a lot of very good feedback on the work from the readers. The book wasn't necessarily really strong artistically. The core story was great, but It wasn't fully exploited and my skill at the time wasn't strong enough. I'll gladly share part of the original book in the upcoming weeks. What is important about that book is that it serve as a starting point of this project. I have 2 tome of prewritten scenario to start with. I don't know about other indie developer, but I think having a scenario draft is really important. I want to develop things around a story and not squeeze a history inside of a confine set of feature. Those two book gave me the opportunity to know my character. This is a lot of character background to work with ! It's cool. It's like if I had started that game a couple of years ago without even knowing I will ever produce that. That said, things have change for the best and I am not sticking to a simplistic adaptation of an old unsuccessful cartoon. This is a complete rewrite, remaster, recreated, new, unique and super wow bing bang history inspired by the original work ! I think it is very important to have a good story a good plot, we want to tell a story, we want a start, a reason to play and the goal to be clear. We want a strong story to support game feature and we have one. So graphically you can expect things in 3D but with a cartoon style approach. I want this game to be more like how Pixar does thing. Cartoon but with a realistic look... ok hold it here. I am not Pixar, but if I have to aim at something, i'de rather aim as high as possible. I don't want the inspiration to stop there. I want the game to feel like a comic book, not by having super great 3D simulation of a page being turn, I don't want it to feel like a gimmick. What I am saying is that I want it to be funny, colorful, action packed and for all age. Everything will be, from a design stand point, inspired by that. Designing a character is also very complex to me. Designing a character is not only how it look it is how it live, how it walk, how it talk, how it react to certain situation etc. You have to create, in your mind, a full feature humanoid. I remember working up at night to write down idea and redraw stuff that wasn't working well. All this data is part of me now. They were born and lived in my head and they still do. I'll make various blog entry regarding each character Game inspiration I can't really pin point what game would be the closest similar game to the our. I am not necessarily inspired by 1 game or a set of game, but i'm inspired by some game feature of the old days. At the time of classic arcade, colleco and nintendo NES there were some stuff about these game that make them good even 30 years later. They were very addictive, they required complex pattern learning, skill and you had to be really crazy devoted to finish a game. I remember the adrenaline rush and excitement of finishing a game meant at that time. I find today's game to be more on the easy side, very forgiving, very beautiful and cinematic but also very short and almost no replay-ability. Replay-ability is a big word that a lot of developer said to aim at but very few actually achieve it. We will try to achieve that in various way by implementing a lot of game mechanic we will talk in future blog post. What game had They were hard and frustrating To a certain degree this is not so good as we want stuff to be fun, but if you want to have this adrenaline rush we all like, you have to go through painful moment. A mix of nice easy moment and hard impossible level that draw the line between care-bear and hardcore gamer ! I know that I treat the "hard level" of todays game as the "normal level". How difficulty work in our game will be shared in a futur blog entry. They had a LOT of replayability Yes, people still play Mario 1. It will always be fun. Q*Bert, still very fun, even though every level look the same. PacMan ! 256 level of frustration. We will not have only 1 level repeating itself at higher speed indefinitely until the game crash, but we will give you reason to restart the game even if you ever finish it. We will give you reason to restart the game if you are stuck at a certain level that is too hard. We will give you reason to start many game in parallel just to do thing differently. I can't wait to share more about it later ! They were unforgiving Ever played Rick Dangerous ? This is one of the most sadistic experience (still a very gun and good game) as everything in this game kill you instantaneously and this Indiana Jones inspired game had all of impossible to detect death trap every where. Each path was design to kill you each and every single time. Ever played the NES version Dragon's Lair ? (ok this one is a bad exemple, as the game was really bad, and the control were terrible) There is a funny episode from the angry game nerd about it.( go to 2:46 https://youtu.be/00xIvTOLrYA ). We don't intend to have a game that frustrating, That is not fun at all. But even in mario everything kill you in 1 shot. It's hard, some level require a Epic level of eye finger coordination. Today's game give you plenty of health, and health typically regen etc. We have our own thinking on how to draw the line between those two extend. More info soon They were fun and had their own signature As easy as it sound, this is the hardest part. Make it fun ! You will be be the judge of that and you'll be able to judge the more you discover about the game. Stay tune as the next blog post will be about the game story and what will be the humorous approach of this crazy universe. Follow us ! What do you guys think about today's game difficulty level ? Are they just right or are they too easy ?
  4. In part 1, I wrote about a difficulty endemic to just about any porting project, the importing and trans-coding of data to different formats. Here in part 2 I'll cover a few of the trickier engine architectural differences that exist between the original engine for Static:IT (Selenite) and the new engine that will support it (base-code from 96Mill and Revel Immortal) Different Origins Originally designed to support editor-only development of Adventure and RPG games, Selenite was a successor of the S3Engine (The Lost City of Malathedra); and shared many simularities with the primary exception being that S3 was designed such that scripts and associated resources were to be written in external tools, and the S3Engine was a pre-compiled exe run-time, that read and executed the scripts and resources. Selenite on the other hand, was an IDE, where game objects were added via a tree-view interface, along with resources; and the IDE was responsible for processing and packaging these resources for optimal end-use. The resulting resources were likewise run next to a pre-compiled SeleniteWin32.exe There is a relatively large expanse of time between the creation of Selenite in 2009, and the creation of Engine4 (or EngineIV ...it's not really important) in 2013; E4 represents several massive shifts in the way I build engines at least as of the time of this writing. It's in HTML5/JS, runs in the browser, and is 'wrapped' for platforms/services that only except exe, etc. It's heavily designed around The Trinity Pattern which is a design pattern I developed to aid in making a game expandable, without breaking save-games, or amassing technical-debt with each release. Dependency Injection and Law of Demeter are used heavily to reduce coupling It's a series of engines, where for each new game we clone the engine code of a game most like it; and features are selectively merged backwards if they're desired. Each game's run-time is optimized to that game, without regard for other games. This is to avoid having to square new features or feature modifications/removals against existing games. The Problems It became clear early in the port, that I was going to have an issue with the difference each engine handles a concept which I refer to as residency. In Selenite, there is the the Game class, which has a list of Room classes, and each of these rooms had a list of Actor classes; and when the game was loaded, that tree structure would be created and resident in memory; addressable at all times. ...not a terrible design, but one I had departed from a while ago; the primary issue is that Selenite mixes the issue of State and Runtime ...that is, objects are in charge of their runtime representation, mechanics and non-persistent state and they also hold their persistent (save game) state as well. In Engine4, the there is a separate class for a game object's persistent state, as well as its runtime. This allows an object's state to be retrieved, and passed into the construction of a newly minted runtime object. runtime objects can be created and destroyed at will, with its separate persistent state living on. This explicit separation of persistent state, as well as the tear-down and reconstruction of game objects is really helpful in allowing for game changes, additions/updates; without breaking previously saved game-state. ...however! That is really not important in the context of porting Static:IT So, the residency scheme in Engine4 (well new Static:IT's copy of it at least) needed to go, it simply wasn't worth trying to massage the wealth of code to deal with alternate mechanisms for modifying non-resident runtime state when I could bring the engine into alignment with the original needs. ...and thankfully, due to dependency injection and law of Demeter; the change was easy. Instead of creating and destroying each room, and its actors as the player traversed them, I was able to shift the code, changing mostly top-level factory functions, to create and maintain the total list of rooms and actors at start. ...in Part:3 I'll cover issues pertaining with porting the scripting from Lua to JS
  5. After viewing What We Can Learn From Doom, I wondered how I could transpose those ideas to my shooter game. The action in D.O.T takes place with the succesion of enemy waves. The different waves are designed to either provide challenge or make the player learn something about the enemies behaviours. If you don't clean the wave fast enough, another one appears and you could easily get overflooded. Each Doom unit has very distinct characteristics that differenciate it from the others. That's part of what makes the experience so rich and joyful. The zombie man has a hitscan weapon and is quite hard to transpose to D.O.T. The player has only one health point which nearly prohibit the use of hitscan weaponery. I replaced it by a wanderer hexagon that just moves on the screen without caring about the player. He is as ennoying as the zombie man which is its main purpose. The imp fire bullets and moves quite slowly toward the player. It exists to force the player to move to avoid bullets. It's perfect for my game where it takes the form of a green gunner triangle that tracks the player and force him to keep moving. The demon hunts the player and do melee damage. In D.O.T., the chaser donut moves fast to the player and kills him instantly. The yellow speeders appear in packs of at least 5 and move very quickly in straight line. Just like Doom's lost souls does. The hollow sniper cube incarnates the cocademon. It stays back and fires a nearly constant flow of bullets. You'd better kill it quickly or prepare to die. To add more precision, it targets the direction you're heading. Deadly! The little red bugs are enemies coming in flock chasing the player. It doesn't move directly to the player. It kinda orbitate around the player to kill it. Just like the speeders, they appear in their own waves; without any other enemy. It provides a short time of relief just before adding more tension when you see all those bugs charging at you. The combination of all those mechanics offers a wide palette of possible encounters. It encourages the player to think fast and act fast.
  6. Why I hate fun

    http://www.tinker-entertainment.com/sitavriend/psychology-and-games/why-i-hate-fun/ Ever since I decided to specialize in game design I struggled with the word “fun”. It might sound silly to struggle with a term that is so central to the art of making games but it makes sense once you start to research ‘fun’. First of all very limited research has been done and secondly the term ‘fun’ is ambiguous. Fun means something different for everyone. Many other industries envy the games industry for making fun products. They mistakenly think that games are this magical medium that are automatically fun and engaging. As a result, they applied typical game elements such as XP and competition to apps as an attempt to make ‘boring’ tasks more fun. But game designers also struggle to make their games engaging and fun. Not every player enjoys playing every game or genre. I typically don’t enjoy most first person shooters because I suck at them. On the other hand it is not just games that can be fun. Many people think knitting is fun, others think watching a football match is fun or playing a musical instrument. What is considered fun often depends on someone’s expectations and their current context. A player has to be in the right state of mind before considering to play a game, they need to ‘want’ to play the game or do any other activity. This can be fun too. A researcher who attempts to understand fun more thoroughly is Lazzaro (2009). She formed the Four Fun Key model to distinguish between four different types of fun: Hard fun, easy fun, serious fun and people fun. Hard fun is very typical for many hardcore games and is fun that arises from overcoming challenges and obstacles. A key emotion in hard fun is frustration followed by victory. Easy fun can be achieved by engagement through novelty and can be found in many exploration and puzzle games. Emotions that are key to easy fun are curiosity, wonder and surprise. Serious fun is fun people have when they feel better about themselves or being better at something that matters. People fun is concerned with the enjoyment that arises from the interaction between people. You can think about competitive or cooperative games people play because they enjoy playing together rather than the game itself. The Cambridge dictionary defines fun as pleasure, enjoyment, entertainment, or as an activity or behaviour that isn’t serious (http://dictionary.cambridge.org/dictionary/english/fun). While we can measure pleasure and enjoyment objectively by measuring physiological changes in the body, we cannot always say we are having fun when we are enjoying ourselves. Besides that, within casual games mainly, pleasure and enjoyment are supposed to be “easy”. This means that you should be careful with challenging the player. If a player wins (often) they will have fun which is the complete opposite of many hardcore games. Within game design we often use flow theory interchangeably with fun. According to Csikszentmihalyi (1996), flow is a mental state in which a person in fully immersed in an activity. The state of flow can be achieved by matching the most optimal skill with the most optimal difficulty for a person. In the case of games, a player becomes so immersed that they forget about their surroundings and lose track of time. A learning curve is used in most games, both casual and hardcore, to account for player’s changing skill and difficulty level. However flow theory isn’t a definition for fun but can result in a player having fun. This mainly works for hard fun as easy fun doesn’t require the player to be fully immersed. References Lazzaro, N. (2009). Why we play: affect and the fun of games. Human-computer interaction: Designing for diverse users and domains, 155. Csikszentmihalyi, M. (1996). Flow and the psychology of discovery and invention. New York: Harper Collins.
  7. So here's the deal : many many years ago, I saw screenshots of Miegakure, that very famous 4D puzzle-platforming game you probably all know about by now. The thing is, it never came out, not even a playable demo, except at big gaming events that I have no way to get to. As such, I decided a while ago that I had waited long enough and I decided to start working on my own mathematically accurate 4D rendering engine. Without going too deep, the point of it is that 4D objects live in 4D space, and the so-called 4D camera just cuts a 3D slice of the 4D space and of every 4D object in it, which is then passed to your regular run-of-the-mill 3D engine to display. Doesn't sound like anything too hard then. The big problem however comes from optimisation. In 3D engines, you expect your geometry to never change ever, allowing for a lot of cool stuff like GPU caching and the like, and is usually pretty vital for performance. However in a 4D engine, the thing that never changes is your 4D geometry, not the 3D geometry that results from the cutting (that in fact changes every frame). The more mathematically inclined will also think about spatial complexity, since in 4 dimensions you have "a lot more space" to put objects in (purposefully keeping it vague). Moreover, I don't want to go through the trouble of building an actual 3D engine, because a lot of existing engines do that a lot better, and I would probably waste all of my time and motivation working on 3D instead of 4D. As a demonstration, my very first demo uses Three.js and is basically a 4D enigma : http://mattias.refeyton.fr/PAF/slicing . The goal is to get to the other side of the wall where the green cube is, knowing that the wall is too high to jump over and that you can't go around it. You can use ZQSD to move (French keyboard, sorry), and A and E to look "ana" and "kata", which are the 4D equivalent of left and right. You'll excuse the roughness of the whole thing, as it was done in 5 days for a school project (it was the perfect opportunity). This has only been tested on Firefox and Chrome. Hence my question : what do I use as a foundation to work on this ? I'd like to use either C, C++ (for performance) or Haxe (for the multiple targets), if that gives any leads. Of course, doing it from scratch is a totally valid answer, as I would be able to include many 4D-only things (such as 4D lighting and other cool shit) that I'm having trouble seeing how I could implement them in an existing engine. Another thing to take in consideration is that there's probably going to be a 4D physics engine to come with it, and that I'm not sure how hard or easy making that work with an existing 3D engine would be. Also I'm killing two birds with one stone by asking if anybody would be interested by a stream of this. I'm planning to eventually stream my work on this, which would include math on blank paper, and heavily mathematically-inclined discussion, not just coding (relatively little coding in fact).
  8. Hello everyone, I was following this article: https://mattdesl.svbtle.com/drawing-lines-is-hard#screenspace-projected-lines_2 And I'm trying to understand how the algorithm works. I'm currently testing it in Unity3D to first get a grasp of it and later port it to webgl. What I'm having problems with is the space in which the calculations take place. First the author calculates the position in NDC and takes into account the aspect ratio of the screen. Later, he calculates a displacement vector which he calls offset, and adds that to the position that is still in projective space, with the offset having a W value of 1. What's going on here? why can you add a vector in NDC to the resulting position of the projection? what's the relation there?. Also, what is that value of 1 in W doing? shouldn't it be 0 ? Supposedly this algorithm makes the thickness of the line independent of the depth, but I'm failing to see why. Any help is appreciated. Thanks
  9. Hi there everyone! I'm trying to implement SPH using CPU single core. I'm having troubles in making it stable. I'd like some help in order to understand what is wrong and how could I fix it. Please, take a look at the following videos: Water inside sphere using Kelager's parameters Water inside big box Water inside thinner box I've already tried using XSPH, the hash method to find the neighbors (now I'm using the regular grid, because the hash method didn't work for me) and two different ways of calculating the pressure force. I'm using mostly the following articles: Particle-Based Fluid Simulation for Interactive Applications, Matthias Müller, David Charypar and Markus Gross Lagrangian Fluid Dynamics Using Smoothed Particle Hydrodynamics, Micky Kelager Smoothed Particle Hydrodynamics Real-Time Fluid Simulation Approach, David Staubach Fluid Simulation using Smoothed Particle Hydrodynamics, Burak Ertekin 3D Langrangian Fluid Solver using SPH approximations, Chris Priscott Any ideas? Thanks!
  10. LF> Contributions

    Hello, I'm Lollipop. I have hobby project it is in very beginning phases. I'm looking for people to come in see my ideas and add input, nicely and respectfully poke holes in everything and even contribute if they desire. It's all concept, ideas, some story line, concept features, some characters. It is original creative fantasy with hopes of being open world, mmo-rpg. Thank you and be kind
  11. I am in my 3rd year of Game Art Design at NUA(norwich) and have become very interested in mechanics design, e.g. how to moderate game flow, gameplay loops and how individual mechanics work in tandem with each other. However I feel like this a very niche job and I was wondering what would be the best way of breaking into the industry with this kind of work in mind.
  12. Hi Guys, I've been working on a new Vulcan based engine, and doing skinned animation support for the first time. I've got everything setup and seemingly working so that I can do a basic import of an FBX model I downloaded from SketchFab, and play its idle animation seemingly correctly, which was very exciting to see. However, I'm guessing I'm missing some rule of model import processing, whereas my 'default pose' for the model comes in oriented so that the character is standing with Y-Axis up, but as soon as I launch him into his idle animation he switches to Z-Axis up. I've seen some mention of applying the inverse bind pose matrix to the joint itself on import, and thought that might be part of my issue, but otherwise can't think of what would be causing this? Thanks!
  13. Hey everyone! I'm doing some research for school on the game development process for RPG developers, and I was hoping some of you would be able to share your experiences in response to these questions: If you’re developing a system for factions, how integrated/vital are factions to the main game play mechanic and/or narrative of your game? What are the biggest challenges you face when developing dialogue and factions for your game? What is your current development workflow like, and what would change in your ideal situation?
  14. Introduction The architecture of software design is a much-debated subject. Every developer has his own opinion about what is good software design and what is not. Most developers agree on what is bad design, on what is good design there are a wide variety of opinions. Unfortunately, due to the nature of software development, there is no silver bullet; there is no one design strategy that always works. There are a couple of strategies that have proofed to be successful. These strategies have known strengths and weaknesses. The advantage of using such a strategy is allowing you to focus on building your game, instead of worrying if your codebase will implode after someone decided the game should function a bit different than how the code was originally written. Architecture In game development, the entity-component-system is an architectural pattern that is used successfully in small, medium and large games. The main strength of this strategy is the usage of the composition over inheritance pattern. This pattern prevents the build-up of complex object inheritance tree’s, that will make your code impossible to refactor without a lot of side-effects. So how does this pattern work, at its core, there are three elements; entity, components, and systems guess you didn’t see that coming. Let’s describe these one by one, I’m starting with the smallest and most simple one the “component”: Component The component represents a single attribute of an entity. Some examples of entities can be: Position Rotation Scale Physics body Texture Health Entity Entities are the “game-object” some examples: Ball Camera Player Enemy Bullet An entity can have multiple components, for example, a ball entity can have the following components: position, rotation, scale, texture and physics body. A camera entity might only have a position. Usually, all entities have a unique-id for fast access, but there can also be other ways of accessing entities. System The system is responsible for one aspect of the game, a simple game has can, for example, have the following systems: Rendering Physics GUI Sound AI What a system does is iterating over all entities that have components of the types defined by the system. For example, the physics system will act only on entities with a physics-component and a position-component. The rendering system will only act on entities that have a position and texture component. For example, if a ball entity has a position and physics and texture component. The physics system will pick up the ball entity, as it has a physics and position component. The physics-system control a physics-engine, that will do its magic and calculate a new position for the ball. The physics system will set this new position on the position component. The rendering-system will also pick up the ball entity, as it acts on all entities that have a position and a texture component. The rendering system can render the ball using the texture and the position found with the ball entity (yes, the same component that was just updated by the physics-system). Now imagine you spend some time implementing the architecture described above, and you after, running it, realize the ball is not really moving very realistic. That might be because you forgot to take rotation into account. To fix it you now only have to create a rotation-component and add it to the ball entity. Now add in the physics system a check if the entity has a rotation component and if so just set the rotation on this component. In the rendering-system also add some code to check if there is a rotation component and if so render with this rotation. This is where the power of this architecture emerges, imagine you have not one ball entity but have a lot of entities like the ball, wall, player, ground, etc. and you forgot about the rotation. You only have to modify the rendering system and the physics system. Then by simple adding a rotation component to the entities you want to have rotation on, magically all those objects have a rotation. Now adding rotation seems like a trivial thing to do, but what does this architecture enforces is the separation of concerns (e.g. rendering and physics) while still allows adding new functionality. And important; It does this without the usage of inheritance but rather by composition. Possible features The architecture described above is in itself quite powerful. But there are some more interesting possibilities with this architecture. I will describe some of them below. Game-mechanic tweaking Creating a generic mechanic-tuning-utilities; as there are a limit number of component types, you can create a (developer) GUI-overlay that allows you to modify the values of a component. This will allow you to in real-time modify the values, e.g. the position, size, texture, acceleration, the weight of a certain entity his components. This will help you tremendously in fine-tuning game mechanics without the need to keep recompiling and reloading your game. Level-editor Taking this even a step further you could use the above system to load all entities and relevant components from a file, e.g. XML. This will also help you decrease compile and loading time, letting you focus more one tuning game mechanics. This could then be a very good start for creating a level-editor, letting a none technical team member (game-designers) tweak game mechanics. Dynamic loading Something else that can be managed using this system, is implementing an entity loading/unloading mechanism. You can define an interface with functions like initializing, loading, starting, stopping, unloading, destructing. Now you can implement a loading mechanism that guarantees the loading and initializing always happen asynchronously. This will allow you to load and unload entities in a uniform and controlled manner. You could also choose to run all the systems in a different thread you need to take some more care about modifying components, but this could allow you to do a lot of performance enhancements, as for example, the AI needs less frequent updates then a renderer. Real-world example Note this implementation is done in Java, as I’m using libGDX as the platform, but the architecture is certainly not limited to Java and can also be implemented in other languages like C++. Enough of the theory, now for a real implementation. As a hobby project, I have been creating a small iOS/Android game, my first implementation of this game was naïve, with one source file containing all logic. No need to explain this is a bad implementation, but this did allow me to check if my idea was fun and create a quick prototype and do some fast iterations from there. For reference, the “bad” implementation can still be found here: https://github.com/tgobbens/fluffybalance/blob/master/core/src/com/balanceball/Balanceball.java After I created this implementation I decided I wanted to implement the same game using a better manageable implementation. The “main” entry file can be found here: https://github.com/tgobbens/fluffybalance/blob/master/core/src/com/balanceball/BalanceBallSec.java. So, I’ve created my own entity-component-system. If you want to create your own game using an entity-component-system, and want the game to be ready as soon as possible then I wouldn’t recommend writing one yourself. However, if you want to learn about programming or just create something for fun, implementing such a system is easy, and you will learn a lot from doing this. Another reason to implement this yourself is you get a lot of freedom allowing you to add specific tricks and features that can help you improve your codebase. The entity component system can be found under https://github.com/tgobbens/fluffybalance/tree/master/core/src/com/sec and yes there are some optimisation and improvements opportunities in this code base. But it does show an easy to understand implementation. When trying to understand make sure you know what Java generic types are. It’s quite common you need to find a certain entity to update or get some info from. As there are a lot of components you know there will be only one instance from. I’ve added a method to get the first entity of a certain type. For example, give me the camera entity, or give me the first “game-world” entity. But there are also helper functions to get all entities of a certain type. The same trick is used for getting components of an entity. You will also find a basic type called “engine”, used for binding everything together. This will trigger the updates and holding references to all systems and entities. If you look for a “starting” point for the architecture this is where to start looking.
  15. Time management I thought of a simple Plan: after 1:30am I have all the time in the world for tons of stupid shit to do until 11pm... so five days in a week I start working at 5:00pm until bedtime. That is 6 hours every day, making it 30 in five. Adding 20 hours on weekend (Ten every day) makes it 50 hours a week. That is roughly 200 hours a month I got for this project. So I made a nice overview of my busy ass week and the monster I decided to work on. I have not decided yet if and how I will make money with this. I simply have the Privilege and Interest to make a game and this seems like the best way. The problem This idea is not done yet, no results. all I did for now is clarify that I have a will to do this. I need a story, maybe game mechanics laid out. The solution Creating Forum entries and Writing about them would be a nice way of keeping a publicly available log of completed work. I would be glad to get any support possible from you. The Plan: Checklist log of things I need to learn, has to be easily accessible. Paper seems like good idea. Ideas of how the game should work in organized manner Sources for media have to be found. Hoping for people to hop on the "lets fucking make something because we can" train. Interrested? If yes, lets talk right now right here online. you can also join me on Discord, the link is in my profile description. Don't think, act. Its not about what if it fails its about what if it works here.
  16. Hi, I came across this udk article: https://docs.unrealengine.com/udk/Three/VolumetricLightbeamTutorial.html that somewhat teaches you how to make the volumetric light beam using a cone. I'm not using unreal engine so I just wanted to understand how the technique works. What I'm having problems is with how they calculate the X position of the uv coordinate, they mention the use of a "reflection vector" that according to the documentation (https://docs.unrealengine.com/latest/INT/Engine/Rendering/Materials/ExpressionReference/Vector/#reflectionvectorws ) it just reflects the camera direction across the surface normal in world space (I assume from the WS initials) . So in my pixel shader I tried doing something like this: float3 reflected_view = reflect(view_dir, vertex_normal); tex2D(falloff_texture, float2(reflected_view.x * 0.5 + 0.5, uv.y)) view_dir is the direction that points from the camera to the point in world space. vertex normal is also in world space. But unfortunately it's not working as expected probably because the calculations are being made in world space. I moved them to view space but there is a problem when you move the camera horizontally that makes the coordinates "move" as well. The problem can be seen below: Notice the white part in the second image, coming from the left side. Surprisingly I couldn't find as much information about this technique on the internet as I would have liked to, so I decided to come here for help!
  17. 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.
  18. Hey I want to try shade particles by compute a "small" number of samples, e.g. 10, in VS. I only need to compute the intensity of the light, so essentially it's a single piece of data in 2 dimensions. Now I want to compress this data, pass it on to PS and decompress it there (the particle is a single quad and the data is passed through interpolators). I will accept a certain amount of error as long as there are no hard edges, i.e. blurred. The compressed data has to be small and compression/decompression fast. Does anyone know of a good way to do this? Maybe I could do something fourier based but I'm not sure of what basis functions to use. Thanks
  19. I'm writing a short article on game balance, specifically dealing with typical combat attributes, combat resolution systems, and how those values tie in to game balance, character progression, etc. What I want are some examples of the "to hit" rolls, or skill checks, or other similar contests or evaluations (there must be a word for this!), so I can compare and classify them, along with their balance implications. It's important that the mechanic is documented or otherwise known, rather than just being an opaque "68% To Hit" or whatever. They don't have to be from computer games; alongside some simple classic ones from Civilization and Age of Wonders, I'm also looking at the d20 attack roll from Dungeons and Dragons, a couple from Warhammer, etc.
  20. I was reworking on my LightProbe filter, and I wrote some code to generate the Reference Cubemap, but then I noticed some discontinuous on the border of each face.(Top:CPU implementaion, Bottom: GPU implementation, the contrast has been adjusted on the right side) At first I think it maybe caused by the interpolation, but then I tried the same algorithm in 2D (like a slice in the normal light probe prefiltering) for better visualization, and the result really confused me. See the attachments, the top half is the Prefiltered Color value, displayed per channel, it's upside down because I used the ColorValue directly as the y coordinate. The bottom half is the differential of the color, it's very clearly there is a discontinuous, and the position is where the border should be. And as the roughness goes higher, the plot gets stranger . So, I am kinda of stuck in here, what's happening and what to do to remove this artifact? Anybody have any idea? and here is my code inline FVector2D Map(int32 FaceIndex, int32 i, int32 FaceSize, float& SolidAngle) { float u = 2 * (i + 0.5) / (float)FaceSize - 1; FVector2D Return; switch (FaceIndex) { case 0: Return = FVector2D(-u, -1); break; case 1: Return = FVector2D(-1, u); break; case 2: Return = FVector2D(u, 1); break; case 3: Return = FVector2D(1, -u); break; } SolidAngle = 1.0f / FMath::Pow(Return.SizeSquared(), 3.0f / 2.0f); return Return.SafeNormal(); } void Test2D() { const int32 Res = 256; const int32 MipLevel = 8; TArray<FLinearColor> Source; TArray<FLinearColor> Prefiltered; Source.AddZeroed(Res * 4); Prefiltered.AddZeroed(Res * 4); for (int32 i = 0; i < Res; ++i) { Source[i] = FLinearColor(1, 0, 0); Source[Res + i] = FLinearColor(0, 1, 0); Source[Res * 2 + i] = FLinearColor(0, 0, 1); Source[Res * 3 + i] = FLinearColor(0, 0, 0); } const float Roughness = MipLevel / 8.0f; const float a = Roughness * Roughness; const float a2 = a * a; // Brute force sampling with GGX kernel for (int32 FaceIndex = 0; FaceIndex < 4; ++FaceIndex) { for (int32 i = 0; i < Res; ++i) { float SolidAngle = 0; FVector2D N = Map(FaceIndex, i, Res, SolidAngle); double TotalColor[3] = {}; double TotalWeight = 0; for (int32 SampleFace = 0; SampleFace < 4; ++SampleFace) { for (int32 j = 0; j < Res; ++j) { float SampleJacobian = 0; FVector2D L = Map(SampleFace, j, Res, SampleJacobian); const float NoL = (L | N); if (NoL <= 0) continue; const FVector2D H = (N + L).SafeNormal(); const float NoH = (N | H); float D = a2 * NoL * SampleJacobian / FMath::Pow(NoH*NoH * (a2 - 1) + 1, 2.0f) ; TotalWeight += D; FLinearColor Sample = Source[SampleFace * Res + j] * D; TotalColor[0] += Sample.R; TotalColor[1] += Sample.G; TotalColor[2] += Sample.B; } } if (TotalWeight > 0) { Prefiltered[FaceIndex * Res + i] = FLinearColor( TotalColor[0] / TotalWeight, TotalColor[1] / TotalWeight, TotalColor[2] / TotalWeight); } } } // Save to bmp const int32 Width = 4 * Res; const int32 Height = 768; TArray<FColor> Bitmap; Bitmap.SetNum(Width * Height); // Prefiltered Color curve per channel float MaxDelta = 0; for (int32 x = 0; x < Width; ++x) { FColor SourceColor = Source[x].ToFColor(false); Bitmap[x] = SourceColor; FColor Sample = Prefiltered[x].ToFColor(false); check(Sample.R < 256); check(Sample.G < 256); check(Sample.B < 256); Bitmap[Sample.R * Width + x] = FColor(255, 0, 0); Bitmap[Sample.G * Width + x] = FColor(0, 255, 0); Bitmap[Sample.B * Width + x] = FColor(0, 0, 255); if (x > 0) { const FLinearColor Delta = Prefiltered[x] - Prefiltered[x - 1]; MaxDelta = FMath::Max(MaxDelta, FMath::Max3(FMath::Abs(Delta.R), FMath::Abs(Delta.G), FMath::Abs(Delta.B))); } } // Differential per channel const float Scale = 128 / MaxDelta; for (int32 x = 1; x < Width; ++x) { const FLinearColor Delta = Prefiltered[x] - Prefiltered[x - 1]; Bitmap[int32(512 + Delta.R * Scale) * Width + x] = FColor(255, 0, 0); Bitmap[int32(512 + Delta.G * Scale) * Width + x] = FColor(0, 255, 0); Bitmap[int32(512 + Delta.B * Scale) * Width + x] = FColor(0, 0, 255); } FFileHelper::CreateBitmap(TEXT("Test"), Width, Height, Bitmap.GetData()); } Roughness 0.5.bmp Roughness 1.bmp
  21. UDP Server Authoritative What I'm doing right now is syncing the players position periodically and using some interpolation while any ability the player uses gets sent and played as soon as possible. Everything seems to work ok in parallel if the abilities don't involve the player moving. If I were to use the same system for movement based skills I would have some trouble syncing VFX with the movement part of the skill because movement would only be managed by state sync. So my question is what would be the best approach to deal with this issue? Should the players position get "locked" at the start of the ability so the ability code could take care of the movement instead, should the state sync take care of both: positions and abilities or is there a better solution? I understand I can't just have state sync take care of the movement and ability code take care of the VFX because of abilities such as teleport for example.
  22. Composition 101: Balance

    In physics, Balance is that point where a specific distribution comes to a standstill. In a balanced composition, all elements are determined in such a way that no change seems possible. The piece must give the feel of steadiness, otherwise, it will just seem off. Rudolf Arnheim, in his Art and Visual Perception book, stands that there are 3 elements to balance: shape, direction, and location. He also says that in the case of imbalance “the artistic piece becomes incomprehensible […] the stillness of the work becomes a handicap”. And that’s what gives that frustrating sensation of frozen time. In this simple example, you can see all this. Having the sphere off center gives the sensation of unrest. The sphere seems to be being pulled to the corner almost. It’s if like an invisible force is pulling it from the center. These pulls are what Arnheim calls Perceptual Forces. And with the sphere in the center of the walls, you have the sense of balance, where all the forces pulling from the sides and corners of the square are equal. Returning to physics, we can say that when talking about Balance the first thing that pops into our heads is Weight. And that’s what it is all about, what we think. Because, as I said before, perception is just the brain processing images. So, if when we talk about balancing something we think of weight it definitely has to have something to do with it in art, right? Exactly. Arnheim talks about knowledge and weight in balance referring to the fact that anyone who sees a picture of a scale with a hammer on one side and a feather in the other knows that the first one is heavier. If the scales are perfectly balanced it will just seem off. But balance does not always require symmetry, as we might tend to think. Isn’t equilibrium that brings balance. If the scales tilt to the “correct” side (the hammer) perceptual balance would have been achieved. In Art, as in physics, the weight of an element increases in relation to its distance from the center. So an object in the center can be balanced by objects to the sides, and objects on one side of the frame must be balanced with objects in the opposite location. But this doesn’t mean that the objects must be the same (symmetry and equilibrium), for there are properties that give objects weight besides their actual apparent weight. SIZE. The larger the object, the heavier. COLOR. Red is heavier than blue. Also, bright colors are heavier than dark ones. ISOLATION. An isolated object seems heavier than the same object accompanied by smaller ones all around it. Arnheim puts the moon and stars as an example here. SHAPE. Experimentation has shown that different shapes affect the way we perceive weight. Elongated, taller, figures seem heavier than short ones (even though they both have the same area size). To expand on this matter I recommend you to go back to the books I will reference in the sources down bellow. Even though these are really simple examples, I plan to move on with this theory applied to environment art. The whole take on Balance gives all the world building process a solid base stone. Embracing these principles will help you understand and better plan object placement in your scene to avoid the feared feel of steadiness Arnheim warned us about. There is still a bit more to explain about Balance so I will be expanding a bit more on this matter in future posts. Thumbnail art: Madame Cezanne in a Yellow Chair, c.1891 - Paul Cezanne Sources: Arnheim, Rudolf (ed.) Art and Visual Perception. A psycology of the creative eye. University of California. 1954. Bang, Molly. (ed) Picture This. (1991) Baker, David B. (ed.). The Oxford Handbook of the Psychology. Oxford University Press (Oxford Library of Psychology), 2012.
  23. The Quest for the Custom Quest System

    Intro - "The challenges of dynamic system design" Custom Quest evolved during development, from a minor quest system used for our own needs in our own game production Quest Accepted, to something entirely more dynamic and customizable, now finally released, these are our thoughts on quest design and developing standalone subsystems. Splitting what is a major production for a small indie team, into smaller installments such as a quest system was a good idea we thought, this way we can get some releases out there and fuel the development of our game. But building a system that works for yourself is one thing, building a unity plugin that will let other developers create quests, missions, and objectives, you would never have thought of is something else entirely. The first thing we had to realize was that when building a quest system, the task is not to design great quests, the task is to enable the users to create great quests. That still meant we had to find out what good quest design is and what a quest really is. Our task was to create a system where the user is free to create creative engaging and rewarding mission experiences for their players. What is a quest? - "Cut to the core" First off, we need to know what a quest really is. A quest is the pursuit, search, expedition, task or assignment a person(s) does in order to find, gain or obtain something. In games, quests and missions function in many different ways depending on the genre. A single game can contain a multitude of different types of quests put together in just as many ways. In an MMO, for instance, quests are vehicles for the story and the player's progression. In many cases they are formulaic and simple, some can even be repeated, there are hundreds of them and everyone can do them. In other games quests are for single player campaigns only, here they shape each level giving the player a sense of purpose. Quests can span the whole game or just be a minor optional task on the way, there are so many design philosophies and creative quest designs that we had to narrow it down and really cut to the core of what is needed for good quest design. What all quests have in common is the task, the criteria for successful completion of the quest, and the reward, the goal of the quest, what the player gets out of doing what we ask of him. Quests cover an incredible variety of tasks so it was important for us to base our decisions on thorough research. In our research, we found that there are three layers to quest design. The type, the pattern and the superstructure. Quest types exist within quest patterns and quest patterns exist within the quest superstructure. We found that there are 8 basic types of quests these are the various tasks/criteria the player must do in order to complete the specific quest. There are 12 quest patterns. These are ways designers can use their quests, connect multiple quests set them up in engaging ways or teach players how to interact with and get the most out of the game world creating variety and engaging the player. Enveloping the patterns is the quest superstructure, the overall structure of quests in the game, we found that there are two main ways of structuring your quests. Historically quest have a quest giver, an NPC or object that informs the player about the quest, what they need to do, the story behind it and perhaps even what their reward will be should they complete the quest. Quest types - "Do this, do that" The core task each quest consists of, the criteria for completing part of or all of a single quest. These are the actions we want Custom Quest to be able to handle. Kill Probably the most basic quest type, the task is to kill something in the game, for example; kill 10 goblins. Gather Again very simple, the task is to gather x things in the game world, collecting berries or the like. Escort The player must escort or follow a person or object from point A to B while keeping it safe. FedX The player is the delivery boy, they must deliver an item to a person or point. Defend The player has to defend a location from oncoming enemies, often for a set number of waves or time. Profit The player must have a certain amount of resources to complete the quest, contrary to gather quests these resources are resources the player would otherwise be able to use himself. Activate The player's task is to activate/interact with one or more objects in the game world or talk to a number of NPC’s. In some cases, this must be done in a certain order for a puzzle effect. Search Search an area, discover an area of the game world. This is useful for introducing areas of the map to the player and giving them a sense of accomplishment right off the bat, showing them a new quest hub or the like. Quest Patterns - "An engaging experience" Tasks are one thing, and in many games, that might be plenty but we wanted custom quest to let the users create chains of quests, specialize them and set them up in ways that draw the player into the experience, there are many ways to go about this. Arrowhead The most basic quest pattern, the quest chain starts out broad and easy, the player has to kill some low-level cronies. The next quest is narrower, the player must kill fewer but tougher enemies, lets say the boss' bodyguards. The last quest is the boss fight, the player has killed the gang and can now kill the boss. This quest pattern is very straightforward and works well, giving rewards either at every stage or only when the boss is dead. Side stub A side stub is an optional part of the overlapping quest. Lets say quest A leads to quest C but there is an option to complete a side objective B, which makes completing C easier or it changes the reward, for example. The player must escape prison, the side stub is “free the other prisoners” in this example escaping with all the prisoners is voluntary but it might make it easier to overpower the guards or the prisoners might reward the player when he gets them out. The side stub differs from a generic side quest in that it is tied to the main quest directly. Continuous side-quests These are side-quests that evolve throughout the game, one unlocks the next, but they are also affected by external requirements such as story progress. This pattern is often found with party members in RPG games, where the player must befriend the party member to unlock their story quests. Deadline As the name implies these quests are time sensitive. The task can be of any type, the important thing is that the quest fails if time runs out. This could also be used for a quest with a side quest where the side quest is timed for extra rewards but the main objective is not. Deja-vu quests This kind of quest pattern gives the player a quest they have done or seen before. In some cases, this “new” quest will have a twist or something that sets it apart. It can also be the same sort of quest that exists in different areas of the game world, perhaps there is more than one goblin camp? or perhaps the player has to pick berries daily. Delayed impact Delayed consequences of a previous decision. Often used in games where the story is important and the players’ choices matter. These quests are tied together without the player knowing. Let's say the player is set the optional task of giving a beggar some gold to feed himself. The player gives the beggar a few gold and is on his way. The next time he meets the beggar the beggar has become rich and rewards the player for his kindness with ten times what he gave. One of many The player is presented with a number of quests, they have to choose which one to complete, they can only choose one. The others will not be available. Hidden quests Hidden tasks that aren’t obviously quests at first glance or are hidden away for only the most intrepid players to find. This could be an item the player picks up with an inscription in it if the player then finds the person the inscription is about he can get a reward for delivering it. A good quest pattern for puzzles, these kinds of quests can really make the game world come alive and feel a lot more engaging, allowing the player to uncover secrets, Easter eggs and discover all of the world created for them Moral dilemma Punish the bread thief who stole to feed his family? often used in games that have a good/ evil alignment level for the players, these kinds of quests make the player make a choice about what kind of character they want to play, they get to choose if their character is good or evil. Side quests Optional quests, these quests are often found in level based games where the overall quest must be completed to get to the next level, the player can optionally do some extra tasks to get more points. The important part is that these are optional but they give the player a reward for, getting everything they can out of the game. Tournament Tournament style quests, a series of quests that get harder as the player progresses. An example could be a gladiatorial arena if the player defeats five enemies one after the other he gets rewarded as the champion of the arena, but if for example, he fails at the third, the whole tournament is failed and he has to start all over from quest 1. Vehicle missions Despite the name these quests are not confined to being about cars, these are simply quests where the players control scheme changes to complete the quest(s). An example could be; changing from running around in the game world to driving a tank to destroy a fort. Quest superstructure - "The whole package" With quest superstructures, we are venturing into general game design. The superstructure is how the player is allowed to complete quests in the game world. It's basically a question of whether the game is “open world” or a linear experience. The diamond structure The open world model, think games like The Elder Scrolls V: Skyrim, the player is introduced to the game through a quest, but after that, they can go wherever and do whatever quests they want. There are tons of quests of the above types and patterns, the player is free to pick and choose which to do, giving the player the illusion of freedom within the game world (the diamond). However, the game still ends by completing a quest that is locked and always a requirement to complete the game. This can, of course, be varied by different choices the player has made throughout the game or even have multiple endings. Quests can be concentrated into quest hubs, i.e. towns with lots to do or the like, but they don't have to be completed in a linear fashion Linear hub structure This structure consists of a number of required “bridge” quests that need to be completed in order to unlock the next area or “hub”, each hub can have any number of quests, this could be a town full of people in trouble, each with their own quests and quest chains to complete, when they are all done, the player moves on to the next hub through another bridge quest. Limiting the quest size of the hubs will make the quest structure feel more linear and thereby the game linear, and creating larger more open hubs can make the player feel freer. Outcome - "So many options!" The development of custom quest has been the quest to allow game developers to create quests and missions that use these types. However, no matter how well we have researched, some one will come up with a new and creative way of doing quests. The solution for us was to make the system more customizable. Letting users convert their quest prefabs to quest scripts that automatically inherits the core functionality, so the user can freely add their own additional functionality on top of the existing core Asset development as fuel - "A learning experience" Developing this way, splitting the production into sub systems that can function on their own and even be used by others is not something that should be taken lightly, but if you can build something lasting, something others can find value in using, then the final product will be all the better for it. Custom Quest started as a project we thought could be completed in a couple of months, it ended up taking 7. In part this is because we realised that if we were going to release the system, we might as well do it right, that meant creating a system that was customizable and robust, a system that can be added to the users game and not the other way around, a system we could be proud of. The experience of developing for other developers is quite different to developing a game. One that has made us much stronger as programmers and as a company, it forced us to think in new ways, in order to create a dynamic and customizable solution. Custom quest has evolved from an asset we could use in Quest Accepted, into a tool others can use to create a unique game experience. All in all, the experience has been a good one and Random Dragon is stronger for it, I would, however, recommend thinking about your plugin and extra time before you start developing. Sources: www.pcgamesn.com -"We know you aren't stupid" - a quest design master class from CD Projekt RED http://www.pcgamesn.com/the-witcher-3-wild-hunt/the-witcher-quest-design-cd-projekt-masterclass http://www.gamasutra.com/ - Game Design Essentials: 20 RPGs - http://www.gamasutra.com/view/feature/4066/game_design_essentials_20_rpgs.php?print=1 Extra credits - Quest Design I - Why Many MMOs Rely on Repetitive Grind Quests https://www.youtube.com/watch?v=otAkP5VjIv8&t=219s Extra credits - Quest Design II - How to Create Interesting MMO and RPG Quests https://www.youtube.com/watch?v=ur6GQp5mCYs Center for Games and Playable Media - Situating Quests: Design Patterns for Quest and Level Design in Role-Playing Games - http://sokath.com/main/files/1/smith-icids11.pdf Center for Games and Playable Media - RPG Design patterns https://rpgpatterns.soe.ucsc.edu/doku.php?id=patterns:questindex Special thanks to Allan Schnoor, Kenneth Lodahl and Kristian Wulff for feedback, constructive criticism and background materials.
  24. Hi. To be honest, but the game design for me has always been something unique and interesting. My path of game development first started with programming. After I began to draw, in order to be universal, but later, I discovered the game design and that was for me, on a pedestal favorite direction. Today I would like to touch on the types of players, why they play the games and pleasures of games. Be brief and clear. In our nature there are 4 types of players: explorers, killers, sociable and those who like committed to something. Crooks. This type of players are focused more on the quick passing game. It does not matter the study and details in the game. Killer. These guys love to destroy everything and kill everybody. Just put them in the tank, tell them where it is necessary to blow - trust me, they will not leave anything alive there. Sociable. They love socializing, but most of all they love online games where can someone make friends, work in team and to tell you the recipe for a delicious mother's cookies. Researchers. How do you think, what you like to do this group of players? I also think that they are exploring every path in the game where you can collect all achievements. Every time you create a game, ask yourself the question: "what kind of player I do my game? Is it possible to combine these types of players in my game, changed some part of it?" Incidentally, with regard to online games. Why do you think people play online games? First, they like competition, will compete to get to the top and gain respect. Secondly, people like to work in a team. Personally I play team games and more hours spent in team modes rather than in single. I love this mode. Thirdly, people play online games in order to meet and chat with friends, spend time with them online and meeting them to have constant, friendly contact. As you know, men play more games than girls. Their main game is the first 20 years. Action and aesthetics - their element. From 20 to 30 years, men are already playing something more calm and tactical, where you do not need a lot of push on the joystick, but need to think. And about men from 30-35 years to play in something calm, for example in genres "I'm search" and "Farm". But women, as a rule, begin actively playing with for 30 years. More women in the world, but I don't like the game. But often after 30 years of playing farm frenzy. Identify the main fun of the players: Fantasy. We love to feel part of another world, which could be anyone. Plot. Sometimes the plot can cause a pleasant sense of his sudden change of events, a dramatic denouement and linearity. Partnership. Teamwork is enjoyable. Discovery. The opening of the new - is the main game fun. Expression. Everyone loves to brag about. Obedience. Cool when you can control others. Feeling. When you realize that step the expected event, then the waiting becomes a pleasure. The gloating. When you killed your enemy, it's nice. Gifts. We love to receive gifts? Humor. No comment. Choice. To go left or right? I have a choice? Fulfilled goal. We love to reach goals and to feel pride because of this. Surprise. We love to be surprised. The Japanese are masters at it. Fear. We love to be frightened and to feel the shaking. This is an interesting kind of fun that we both and hate. A miracle. When we are strongly of something was surprised and experienced a wild delight from something. A tough win. That moment, when initially there was little chance to win, but you win. So when making a game, think of the fun highlights of your game and how much to add. My name is Flatingo and I love to make games. If you also like to make games, welcome to my YouTube channel. Good luck in your projects.
  25. I want to share my experience and collected here the most common mistakes in creating and advertising your games. I'll be glad if it helps you.
  • Advertisement