Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 23 Feb 2001
Offline Last Active Yesterday, 04:43 PM

#5308091 What to consider for an RPG damage formula?

Posted by on 26 August 2016 - 02:41 PM

One thing that's always bothered me about games with medieval warfare and armor and damage calculations is that they rarely ever actually realistically model the effect and purpose of armor.


I remember going to a museum in Finland a few years back and looking at weaponry and armor from 500+ years ago. Knights were covered, head to toe, in steel. Almost nothing could penetrate that. Then they also have a kite shield and sword. A large squad of these guys, slowly marching towards you, was an invincible, inevitable death. The only way you could kill one of these soldiers was to tire them out, lift up their arm, and stab them with a very thin dirk beneath the armor. People didn't wear armor to take LESS damage, they wore it to take NO damage. Even a good scratch or cut could get infected and take months to heal, so people probably spent a lot of effort trying to develop armor which made them impervious to damage and used weaponry specialized against armored opponents. A mere peasant armed with a pitchfork would be minced meat, no matter their martial skill. Armor was expensive though, so not everyone on the battlefield had it. To wear armor was almost a status symbol, and to make it even more of a status symbol, some rich nobles would have their armor inscribed with decorations. One other surprise is in regards to leather armor. Leather armor is HARD. It's not that soft, supple leather which is designed for clothes and couches, it's leather that has been treated differently so that it hardens into a protective shell. It's not as hard as steel, but it will do a very good job of blocking most incoming attacks.

If I ever go and design a game with medieval combat mechanics, I would certainly try to take into account the realism of armor and its functional use. There would be no "Hey, I'm fully armored and yet a single sword swipe cuts me down!" bullshit. What's the point of wearing armor then? Might as walk around the battlefield naked because it's less encumbering and hot. Let's talk about heat and weight a bit too. I don't know about you, but I've had to wear full modern armor before (flak jacket, SAPI plates, kevlar, side SAPI, crotch cover) in the desert. It's bulky. It's uncomfortable. It's HOT. It's like wearing a snow suit in the middle of july. You don't want to move around much because its heavy and tiring. So, designed game mechanics could take advantage of this fact: The temperature, weight and amount of armor contributes to exhaustion, and exhaustion is a function of fighting capability (blocking and delivering blows). A part of battlefield strategy then becomes managing exhaustion, which is what was actually done! Lines would frequently rotate from the front to the back, rest and recover for a bit, move towards the front, and then resume fighting. Gradually, everyone gets really tired and more R&R doesn't help. But then the army which wins is the one which can bring in fresh reserve troops, preferably in a flanking maneuver. The enemy is too tired to fight fresh troops, and they're being flanked, so they either change focus to fight the fresh troops or continue engaging with the tired troops while the flankers mop them up. It's a fascinating mechanic :D

So... damage would be a function of the martial skill, exhaustion, equipped weapon type, sustained injuries, strength. The frequency of attacks would be a function of exhaustion, martial skill, and morale. An incoming attack wouldn't just be subtracted from the armor of the victim. That would be WAY last. First, you'd want to give the defender a chance to dodge, block or parry the attack. This would be a function of their martial skill, morale, exhaustion, equipped weapon type, mental focus, incoming weapon type, and sustained injuries. IF an incoming blow can't be dodged, blocked, or parried, then it is a hit. The hit would be registered somewhere on the body, but the actual damage inflicted would be a function of how armored that body part is and what type of damage we're inflicting (blunt, piercing, slashing, magical, fire, etc). The design goal would to make it so that an armored opponent *could* be near invincible. That's scary, and it should be scary. Nobody fucks with armored guards (see: swiss guard). If you're not prepared to fight an armored opponent, then you lose. Likewise, if nobody is prepared to fight your armored characters, they lose. Game "balance" would be less about balance on the battlefield, and more about access to resources prior to battle, so battlefield victory is partially determined by preparations before battle begins. (man, I want to make this game...)

#5307751 What to consider for an RPG damage formula?

Posted by on 24 August 2016 - 08:24 PM

Your first iteration is never going to be perfect. You'll have to do a lot of play testing to see if the damage and armor formula you're using matches the vision for how you want the game experience to feel. So... just implement it and try it out! Does it work? Is it fun? What kinds of interesting doors does it open up in design? Don't overthink this stuff too early. Get something working so that you can iterate on variations of the idea until you land on something you really like.

#5307523 Best book(s) for learning to program game mechanics?

Posted by on 23 August 2016 - 09:47 PM

In my humble opinion, it's about 10% programming, and 90% design and approach.

The simplest example I can think of is reducing a health value when a character takes damage. The code is really straight forward:

Health -= DamageAmount;

This is a game mechanic and the programming to implement it is pretty straight forward.

One thing that might help is to rethink how a game works on the backend. Rather than thinking of a disconnect between code and mechanics, think of the code as an implementation of a model. Like, a real time simulation. How that model / simulation should look and behave should be defined somewhere else, such as in a design document (ideally), or in your head. The goal of the code is to faithfully create the model, in a mathematical and logical sense. Technically, you don't even need graphics to have a robust working model (see: dedicated servers). The graphics are just a visual representation of the current state of the game model. Input is a way for people to change the state of the model. Networking is just a way to communicate the state of the model to other connected systems, and to send input requests to change the model state on the server. UI is entirely an aesthetic used to communicate to the player the state of the game model. Inventory is just a part of the model, which may or may not play a part in the game, depending on the design (does a bag weigh you down if you have too much inventory? etc).

So. With all of this in mind, I encourage you to create a text based adventure game. No graphics. Just text in a command prompt. This will force you to spend 95% of your time building out the conceptual model of how the game model works. Maybe if you just have a knight fighting a goblin, you'd be able to build enough structural scaffolding to understand how the backend model should look, behave, and interact with its components. Once you get this down and working well, you can optionally add graphics. But the mechanics and implementation will already be there. You'll eventually understand that the model you're using to represent the game state is view independent and doesn't need screen output. This is pretty much what most game programming is, and there's a lot of math to help create the model (think of calculating the trajectory of a projectile: 95% math, 5% graphics).

Lastly, this stuff mostly comes from lots of experience and practice. There might be books that might help with this, but it's kind of hard and silly to write out a concrete list of rules on how to do this because every case is different. It's more about adopting a good working practice. For me personally, I generally write out how my model should work, generate any necessary sketches of how the output should look, and come up with some idea on what kinds of numbers the model should output. Then, I come up with a code approach which creates the model and those numbers. The coding part is pretty much trying to create a logical model / simulation of the problem. Then I run the model / sim and see if the game output matches my model output. If the game model matches the design model perfectly, I am done. If the game model doesn't match the design model, it's time to ask two important questions:
1. Is the game model a correct implementation of the design model?
2. Is the design model a correct model of what I intended?
Sometimes, a game model is a correct implementation of a design model, but the design model is flawed and you have to revise the design model -- which I think is fun, because you learn! You discover you made some wrong assumptions! 

Another example to drive the point home:

You could create a model / simulation of our solar system and try to get it to be as accurate as possible. You can easily lookup all of the planetary data, such as size, distance from sun, orbital inclination, orbital period, etc. All of the mathematical models are available online. Then, you can run the simulation for an accelerated time period. Where are all of the planets positioned after 365 days? Do the simulated positions match up with the positions in real life? IF the numbers match up very closely, you have a good, working model. Then, things can get interesting and you can start asking some interesting questions, like "What happens to the model if I change the universal gravitational constant?" or "What will the solar system look like in 10,000 years, or 1,000,000 years?"

So, yeah... I hope this gives you enough to chew on for a while.

#5301473 you all say oculus rift but why not google glass?

Posted by on 20 July 2016 - 01:31 AM

I don't know how the hololens screen projection system works. I suspect that they have three very thin layers of glass and each layer contains the red, green and blue channel and they rely on the additive properties of light to render a colored image.


Rendering an imagine is the first of many big challenges you'd face if you're going to make your own AR device. Remember that augmented reality is... augmenting reality! That means you have to know a bunch of things about reality before you can augment it! You need to know where things are in reality space, so that means you'll need to have two cameras that are constantly doing image capture, feeding the capture to a processor, which then tries to gather depth information to create a "z-buffer" for the real world. Why do you need this? For occlusion of course. If you have a ball in augmented reality and it rolls behind the couch, your device will have to know that the 3D position of the ball isn't visible anymore because it is being occluded by the couch. But, maybe a portion of the ball is still visible? So you'd have to do some fancy logic against each pixel in the ball mesh to see if its depth buffer test is less than or greater than the real world depth buffer. Then you've also got to map out the shape of the objects in the real world so that you can have collisions with it. Your ball should bounce off of the couch rather than phasing right through it, and in order for that to happen, you have to do some time processing the environment around you in order to generate triangulated collision meshes. 


This is computationally expensive stuff, so the "magic" of the hololens is that you're really wearing a stand alone computer on your head which has enough processing power and battery life to do this decently for a reasonable amount of time. It's really quite incredible if you think about how much computational power you'd need to do this, and they've shrunk it down to the size of a head band. You also have a microphone, so you can issue voice commands to the system which is pretty smart at interpreting them (I've never tried that feature).


Anyways, trying to compare hololens to oculus rift is like comparing boats vs cars and complaining that your boat can't drive on the highway, or your car doesn't float. They are fundamentally very different...

#5297027 MagicLeap teams up with LucasArts

Posted by on 17 June 2016 - 03:36 PM

Yeah, the field of view on the hololens was the most disappointing part of the hardware. After trying it out and then looking at the marketing materials, I can tell that most of it is marketing BS. The hololens FOV is about equivalent to holding an 8.5x11 inch sheet of paper 18 inches away from your face. To view an entire scene which is larger than that FOV would require you to be constantly moving your head around to scan the entire scene.


The surprising bit about the hololens (which I'd never considered) is that because it's a hologram, the color "black" is transparent, so if you're a keen observer of both the hololens and magic leap videos, you'll notice that they very carefully design their scene objects to not have black or dark colors. It's an interesting design limitation, but by no means does it detract from the coolness of the hardware.

I think the super interesting challenge, which becomes apparent when you watch these AR videos, is whether or not they can handle dynamic background objects. Magic Leap is noticeably absent -- they're projecting their video onto a static background with no moving actors, so they don't have to worry about depth & occlusion rendering. The hololens does a decent job with this, but it's pretty easy to confuse the hardware.

My humble opinion is that the more secretive a company is about their future tech, the less likely it is that it is actually viable. Microsoft has given public demos and done hackathons with hololens, so we can make a pretty clear distinction between what is hype and what is real. Magic leap on the other hand... 100% hype at this point in time. I would be reluctant to trust journalists who are invited to a private demo because they are certainly going to be hand picked and biased to write only favorable input or risk not being invited back for a second viewing. 

Interesting new development though: Magic Leap has purchased a new office building in downtown Seattle, so maybe some of us will be able to get an inside scoop or preview on their tech in the near future.

#5293678 "The Lab" impressions and lessons

Posted by on 26 May 2016 - 03:43 PM

I just finished playing through a bunch of the demos in "The Lab" produced by Valve. Here are the salient things that stick out:

-The very first environment where you are standing on the top of a mountain on a gorgeous day in Washington (my home state!) is fantastic. I would say it is 90% there in terms of immersion. The textures are nearly perfect. It needs more ambient sounds (wildlife and wind). The teleportation system was almost perfect, though if you stand on the bottom portion of the cliff, you can't easily teleport your way back up the cliff because you don't have line of sight. I think the teleporting and visuals was the most remarkable aspect of this experience.

-Vortex Game: Your hand controller is a space ship and you shoot lasers. pew pew pew! you have to avoid little droids and their projectiles and lasers by moving your hand around. The screen gets chaotic pretty quickly. Somehow, I managed to beat the game on the first try. The interesting take away from this is that it's easy to forget where your hand is located spatially, so you can get shot from behind if you're not careful. The other interesting note is that it is very easy to dodge anything if you put your hand up close to your eyes and just use your eyes and body position to dodge stuff. This spatial positioning advantage is worth considering carefully for game designers.


-Slingshot: The voice overs and narrative were the best part of this game demo. Also, it's a lot of fun to catapult projectiles at exploding barrels. This was a near perfect game.


-The Lab: Of all the things they did, the one thing that was the most striking was their implementation of the dry erase board. You can grab the eraser and wipe the board, and the eraser position and orientation is line traced from its prior position to the motion controller position, and then placed on the impact point. This is exactly how you need to do all hand interactions with objects in VR. However, I think they messed up a bit with the markers because you can't control what angle you hold the marker at when you go to draw on the board -- they set it to a preset angle rather than using the angle you picked it up.

-Longbow: This is an archery styled tower defense type game. You are the one and only tower and you have to shoot hordes of paper cutout characters by drawing back a bow and shooting arrows at them. Each killed character emits two red balloons for body shots, three for head shots. Shooting balloons restores the 'health' of your gate. Shooting arrows with a bow is really fun. They almost did it perfectly. They've got a little bit of vibration feedback when you pull back the bow, and aiming it feels pretty solid. However, I think the arrow velocities need to be tweaked slightly. The biggest glaring problem with this however, is that my arms got tired very quickly! This became a huge problem, to the point where I had to consciously decide NOT to shoot at balloons because it would tire my arms, and I'd rather reserve my strength for shooting at the invaders. This means I had to start making physical fatigue management an important game play consideration. I tried alternating between putting arrows in my draw string and pulling them back and putting arrows in the draw string and pushing my bow forward. I think the most salient point here is that your VR games shouldn't have repetitive motions which involve players holding their arms out for long periods of time. You'll want to alternate the types of hand motions players use so that the diversity of arm use doesn't fatigue them quickly.


-Robot Repair: I've demoed this one many times, and its fun every time, though not very replayable. The interesting thing here is the sense of presence you get. I'd say they pretty much nailed it. You don't want to walk through walls or tables, or robots because they feel so real. Just for fun, I walked through the walls in the game. They let you do that, and it feels weird to clip through them. I think its a slight design problem, but probably not too big of a deal. One other thing I noticed is that when I was examining the holographic portion of the robot, it's holographic lines exactly matched the color of the lines of the 'steam chaperon' boundaries and I accidentally walked into a bookshelf not realizing i hit the borders of my play space. This brings up an interesting point which game designers can consider: play space management. If the player strays too far, you can pause the game and assist the player in returning to the center of the action. I think this might be the only permissible time to intentionally break immersion because player safety is a higher concern.

#5292834 Hololens Development

Posted by on 22 May 2016 - 01:54 AM

I've had the rare privilege of being invited by Microsoft to participate in the worlds very first holographic hackathon this weekend. I thought I'd share a few quick notes and thoughts so far:

Mind blowing stuff:

-The hololens is able to recognize voice commands. You can say, "Cortana, record this." and it will start taking video feed recordings!

-It has NO wires. The thing is a mobile computer which is strapped to your head. Take a minute to think about that and let it sink in.

-You can use three hand gestures to create user input commands

-You can place holograms on top of tables and on walls. How freakin' cool is that?! This is done by 'spatializing surfaces'.

-The devices uses cameras and infrared lasers to visualize your environment geometry and generates meshes. The advances in computer vision alone are mind blowing.

-The glasses are rendering at 240 frames per second!!! If you thought the 90 FPS for VR was high... lol


The unexpected stuff:

-Developing for augmented reality is about three times harder than for virtual reality (especially when it comes to design considerations).

-Augmented reality development is NOT the same as virtual reality development. VR is more focused on immersion and presence, while AR is more about layering extra information over the existing world. I can't stress how important this fundamental difference is between the platform types.

-The field of view was disappointingly small (think of looking at the world through a 15 inch monitor)

-The glasses use additive light to create holograms, so you can't draw dark colors such as black! That's just... invisible!

-The magic of AR is being able to keep a hologram stationary even though the observer is not

-It's designed for indoor use

-It can't handle non-stationary objects very well. Definitely don't take it out to sea.

-Dark surfaces and reflective surfaces will not give good results

-People are finding use cases for AR which not even science fiction writers could have envisioned (such as someone remotely using a tablet to draw in your view port as they see what you see, called 'telepresence')

-It's not going to work as well in cluttered and messy environments because all that junk is going to get turned into triangle meshes.

-A lot of the hardware design decisions were made to preserve the battery life of the device (laser pulse frequency, camera resolutions, screen size, refresh rates, cpu, etc).


The disappointing stuff:

-It only works with Windows 10, not Windows 7. (clarification edit: Your developer machine has to be running Win10, though I haven't tested this to be 100% sure.)

-At this point, only Unity3D supports it. No UE4 support yet :(

-Debugging is really hard, if not next to impossible because you deploy out to the device. This slows down dev iteration cycles.

-I need to get a lot more practice with AR if I'm going to be any good at it in the future



Final thought: The hololens is VERY impressive from the technical standpoint. However, it is also the first generation of hardware for this type of technology. It is the worlds first high quality mass consumer market ready device which is capable of rendering holograms on top of surfaces. I expect that the technological advances will increase rapidly in this area within the next 5 - 10 years. I think there are a lot of very interesting problems which Hololens could solve, but the solutions for it can't just be solutions taken from VR and ported over to AR (see: fundamental difference in objectives).

#5292143 Game Prices on Steam: should there be regulation/guidelines?

Posted by on 17 May 2016 - 02:19 PM

One thing I've learned from selling stuff: The price of an item is not the value of that item.


A hair clip costs $0.30 to make in China. We can then sell it for $10-15 in America. Profit margins may appear to be high, but so are overhead costs (booth fee, transportation, food and lodging, time and energy, etc). Yet, people buy hair clips; It's something they like and want, solves a problem, and makes them feel pretty and good about themselves.


Almost a decade ago, I sold Cutco Knives to people. A full set went for about $750-800. "How will I ever convince people to pay that much for knives?!" I wondered. "Isn't that too expensive?" I found out the price doesn't matter.

With every sale, you're playing a juggling act. You've got the PRICE which you're asking for the item, and then the potential customer has the PERCEIVED VALUE of that item. If Price > Perceived value, then no sale. If Price < Perceived Value, then sale! A sale is ALL about the pitch. The art of sales is to increase the perceived value above the asking price.


When I did computer services for people, I hated it and wanted to stop providing my service. My strategy was to double my rate to $60/hour so that people say, "That's too expensive, no thanks!". Instead, it backfired. I got more business! Why? Because by charging higher rates, people thought that I was worth what I was charging. The high number increased my perceived value! Whoops! But, it also works in reverse! If you sell an item way below the perceived value, then the perceived value is also lowered!


So, what do idiot people do when they suck at sales and want to sell something? They drop their price instead of trying to increase the perceived value of their commodity! But, does it matter to others? I would argue "No! Not at all!". It doesn't have to be a race to the bottom as you guys might fear, it just means you have to create a compelling pitch about the value of your game and why it's worth the money you're asking for. We could build a compelling pitch for most decent games selling for $2 and get people to pay $10. Oh no! Sales volume drops! Okay, suppose the volume of your sales drops by 50%. Instead of making 1,000 sales for $2, you make 500 sales for $10. The 1,000 sales gives you $2,000 but the 500 sales gives you $5,000. Now, do you want sales volume or sales value?? Even if your sales volume dropped to 20%, or 200 sales, you'd still break even. You increase your sales volume through marketing and compelling sales pitches, NOT by dropping your price. That's generally an amateur move. Don't think your game is worth $10? Well, your opinion on the value of your game doesn't really matter. If it helps you sleep better at night, maintain high production values throughout the development of your game! At the same time, stop undervaluing yourself!!!

#5290899 Getting objects within a range (In order, fast)

Posted by on 09 May 2016 - 05:45 PM

As others have said, a dictionary is the wrong container. The huge glaring issue you will run into is the edge case when two objects are exactly the same distance apart. Then you have a key collision.


I'd at least use an array. If all you care about is having objects sorted by distance from the position, the objects can be inserted into the array in sorted order. To save on CPU time, you should also not use the distance itself (which has a square root in the calculation) and instead use distance squared.

As others have said, octrees may be the right call for you here. I wrote an article on octrees a while back which may be helpful.

However, to be truly helpful, you could elaborate more on what problem you're trying to solve. Your current solution might not be the best solution of the available solutions at your disposal :)

#5286518 linestrip flickering

Posted by on 12 April 2016 - 01:48 PM

If you add in a static mesh and render it, does that also flicker?

#5285894 Community College or Game Development?

Posted by on 08 April 2016 - 02:17 PM

First off, an introduction!


Hello everyone! I've stumbled onto this site recently and decided to join so I'm completely new to this community. :)


Just out of curiosity, I wanted to get an idea of what you guys think think of the current situation I find myself in. First off, I want to make games. I've always wanted to make games ever since i was a child. I'm currently 19 and am going to Community College, working a part time job, and developing a game I plan to release on IOS and Android this summer. I've been developing this game whenever I can find the time for the past 2 months and I believe it has a lot of potential. As much as want to keep developing and spending more time on this project, I feel like my education is holding me back. So that leaves me to my big question...


Should I leave College after this semester to work on my project full time?


I know education is important but wouldn't it be easier to get into this industry with a 100% completed project rather than any kind of degree? This semester in itself has been tough just because I try to make time for my game rather then studying and my grades show that. I've been thinking about this for awhile now and I would definitely appreciate some advice from people currently in the industry.  :P


Education doesn't hold you back, a lack of education does. 


Use your passion for game development to fuel your studies. Got a boring math class? Figure out how you can use the math material being taught in game development. Got an english class with lots of writing? Figure out how that can help you write better stories and narratives for your games. Got a team project? Use this as training to learn how to work with and communicate with other people -- that is also a skill which gets used every day in game dev. I guarantee when you start taking this approach to education, trying to relate the material you're learning to the material you're passionate about, you'll get passionate about the material you're learning.


Also, don't be an idiot. Your priority should be school and studies first, game development second. Study hard and master the material you're being taught. Don't just try to pass a final test and do a brain dump afterwards, try to add the learning to your list of skills. Think of it like leveling up skills in an RPG -- max out those XP gains! Would you rather be a level 10 game developer or a level 2 game developer? Stay in school. Work hard. Stay focused. Work hard. stay motivated. work hard. Keep at it. You'll get there.

#5285892 Is it good practice for game development to learn multiple languages?

Posted by on 08 April 2016 - 02:02 PM

I think programming itself is language independent. Programming is fundamentally the ability to create a series of logical instructions, often utilizing mathematics.


A programming language, much like a spoken language, is a form of expression of the intended thought. Learning a new language can give you new insights into how to express your thoughts, but they don't necessarily make your thoughts better. That only happens through practice with the intent to improve.


I am pretty good at the language independent programming stuff. I can pick up another programming language in a few days and become reasonably proficient (excluding joke languages like Malbolge and brainfuck). The thinking process is "I want to do this action ten times, how do I create a for loop or a while loop, or repeat this series of instructions 10 times in this language?" After that, it's just a quick lookup of language syntax and I'm on my way.

#5261242 How hard it is to live from games as indie developer?

Posted by on 09 November 2015 - 04:58 PM

You're not ready to be a game developer. Especially not an indie game developer. You can try, but I think that at this point, you will fail and that would only discourage you.

You should start by focusing on getting the skills it would take to become employed at a local game company. Then, go work for one for several years. Figure out the work flow for each job. Figure out how the software development life cycle works and where you fit into it. By working in a bigger studio, you can get really good at a specific part of game development (AI programming? Environment art? animation? etc). When you can do a lot of it well, you may be ready to become an indie developer.

One thing that you absolutely MUST be able to do is work well with other people!!! I cannot stress this enough. No wildly successful game is ever made in a vacuum by one person slaving away in a basement for years. You'll have co workers. You'll have business partnerships. You'll have to talk to customers, and marketing people, and everyone under the sun. At your current job, I would take it as an opportunity to develop yourself and focus on getting better at working with other people. Figure it out. How do you communicate most effectively with your coworkers? How can you lead an effort? How do you get people to see your point of view and follow you? How does your existing employer make money? Why does the business work?

If you want to be a game developer, it's going to take a huge life commitment from you. It's going to take years and years of dedicated training and work, and it won't pay a lot. But it'll be fun, and I guess that's why most people want to get into it.

#5247270 Terrain LOD

Posted by on 17 August 2015 - 04:30 PM

Yeah... some of these ideas are not very good. You only load the terrain once, and that's at level initialization time. If you're pulling the height information from a height map, there's no reason why you can't just set the exact world coordinates for each terrain vertex. If you do this for every frame inside of the vertex shader, your GPU is going to be doing a lot of unnecessary processing work which could just be avoided by placing the XYZ coordinates at load time. Multiply that by every vertex in your terrain, and its going to add up.


The same applies to vertex normals. There's no reason why you can't just get this info at load time and store it in a custom vertex object for each terrain vertex. In fact, if you're going to be creating a height map texture for your terrain, you can also create a normal map texture for your terrain.


You're making 3D terrain. You don't use quad trees for 3D environments, you use octrees.


To avoid the T-junctions, you want to use skirts. The LOD level of a terrain chunk should NOT be influenced by the LOD level of an adjacent terrain chunk. In my terrain system, I had four LOD levels, and I had to be able to skirt lower LOD's to higher LOD's. Check out this wireframe to see what I mean:

Attached File  TerrainLOD.png   1.28MB   16 downloads

#5246540 AOM

Posted by on 14 August 2015 - 01:13 PM

I mean like programming language and graphics like opengl or what...

Doesn't really matter what programming language or graphics API was used. Whether they used C++, ASM, Java, C#, etc, doesn't matter. They could have made the game in any language. Likewise for the graphics API -- whether they used DirectX or OpenGL, doesn't matter. They figure out how to make the right api calls to do what they need their game to do. I like to think that game development is somewhat implementation agnostic.