• 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
    • 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
  • Topical
    • Virtual and Augmented Reality
    • News
  • Community
    • For Beginners
    • 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
  • 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

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.

Developers

Developers


Group


About Me


Website


Industry Role


Twitter


Github


Twitch


Steam

Found 60 results

  1. 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.
  2. 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
  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. 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
  5. 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?
  6. 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)
  7. 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
  8. 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.
  9. centroid from vertices

    please any know how can i' calculate the centroid from any number vertices
  10. 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...
  11. 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.
  12. 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!
  13. "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?
  14. 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
  15. 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?
  16. 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!!
  17. 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 ?
  18. 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
  19. 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.
  20. 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.
  21. 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).
  22. 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
  23. 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!
  24. 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
  25. 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.
  • Advertisement