DaMage

Woah, it’s been a while since I did one of these, now is as good a time as any then. Obviously I didn’t get much done on this project over the holidays, mainly due to a combination of graduating my degree at university and then getting another software job to work on. But as January and that other job was winding up, I have had some time to work on my game again. Also good news is I am into my PHD program with a scholarship, so I'm set for the next few years as far as a job goes and will hopefully have time to work on this still. After adding some ‘gameplay’ in the last post, it was really obvious that the basic AI I had was no longer going to cut it, and I needed to get that going in order to figure out if my idea for combat would work. Now the combat in my game is based around managing your fatigue while avoiding getting hit, pretty generic, but if you (or an NPC) lose all your stamina, you fall into a ‘recovery mode’ where you are very vulnerable to attacks. This allows you to either work down your enemy’s health by hitting them, or instead working their fatigue so you can knock them down. In order to fight, there are a few things you can do, attack, block or break. Attacking will cost some stamina, and will reduce the enemy health if you hit. Blocking drains stamina, but prevents attacks from doing damage, and breaking costs stamina, but will stagger your opponent regardless if they are blocking or not. Doing combinations of these actions and using recoil times and whatnot is where the skill comes into the combat. But now the real question, how do I explain this kinda complicated system to the computer? There are a few ways to do AI for this, for example the robotics lab at my university uses state machines for their AI, but for this I’ve decided to use simple flowcharts. Every AI cycle (which is every 100ms), the AI goes through a flowchart to determine what it should do next, these decisions are based on what it’s opponent is doing, what it was doing before and a bunch of random dice rolls to make it less perfect. To help design this, I actually planned out some diagrams that show the order of decisions and results of each outcome, so I’m going to put them here and explain them a bit. This is the start point for the AI. If it can see an enemy, it jumps into combat mode, otherwise it goes into a ‘wander’ state where it just moves around the level randomly. The wander states involves a bunch of pathfinding and checking where it’s at in relation to its goals and targets. Sometimes after reaching a goal, the AI will also just decide to stand there for a bit, that’s what the ‘Do Nothing’ step is about. Most of this is to do with pathfinding though, so let’s jump to combat. The decisions in combat are ordered from most important to least important, so obviously if the AI has low stamina the first and only thing it should do is try to retreat. If that’s not the case, the AI need to move towards it’s opponent, if it’s too far away pathfinding goals are generated, but if it’s close enough to attack, then we need to take action. First we check is the enemy is attacking, and roll a dice if we should block, if not, then we also check if we are currently blocking as the defend section also deals with dropping our block. Assuming nothing was chosen, we then roll a dice to see if we should attack, and then if we didn’t attack, we roll a dice to see if we start to defend. Finally, if we chose to do nothing, then nothing happens and the AI idles for a cycle. This lets the AI look like it’s thinking and allows for a player to attack. Each of these decisions breaks off to a another section of the flowchart, these are all small sections in the next diagram. First off we have defending, if we have chosen to defend and the enemy is attacking…well we really should defend, but if our enemy wasn’t attacking, we can choose to not defend anymore. This decision ‘loop’ works with the combat section and may change in the future if it gets more complex. Next we have retreating, which basically asks if we are close to the enemy, we move away, repeat until we have stamina again or we are far enough away. For attacking we check if the enemy is blocking, if they are we roll a dice to see if we will do a break on them. If they weren’t blocking, or we decided not to break, than we roll another dice to see if we attack. Now you may be wondering, why do we have so many dice rolls and why would you allow the AI to do stupid things, such as attacking into a block or deciding not to block an attack. The reason is simple, you need the AI to make mistakes otherwise it wouldn’t be fun to play with. In an earlier build I had the AI always block incoming attacks, but it made the AI nearly impossible to beat. You’d stagger them and if you didn’t time the attack perfectly, they’ve be up blocking the attack straight away. By adding some random chance in, the AI will only sometimes do that, other times it’ll try to do something else and get hit. Anyways, that’s the AI I’ve been working on, still got a bit of work to do, for example stamina isn’t implemented yet, so you can break and block as much as you like, but for this post, that’ll do! Here is a video of me fighting the AI.

So let’s see, my calendar says it's been about a month, so it's time for an update. I'm back at university at the moment, so game dev always comes second to assignments. For my second assignment this semester I want to use my game as an example of trying different ways to play games with one handed controls. But in order to do this, I needed to polish up some things and add some 'game' to my game. First off, I needed a user interface, things like health bars and menus. Now I could have gone and found a c++ library to do this....but where is the fun in that. I have worked with many different drawing APIs over the years, so I know the basics of how you should structure and encapsulate different elements. So I've programmed a couple of UI elements that can be put into different menus that display on screen, but I'm not going to go into depth about how I structured everything to work together, cause that would be boring software engineering stuff. Important part is that now I have an escape and options menu, along with some other controls like reloading the game and exiting. The options menu is pretty sparse and just contains a page for remapping controls, which is sort of required for this assignment about control schemes. Now for the game part. Last I left off I could move around the level and have animations play, but you couldn't really 'do' anything. So first I added some UI items for health bars that appear for you in the top left, and for enemies, over their heads. Then added a system so that when an attack animation plays, it will trigger a hit at the right moment of the animation (and do all the checks to make sure it does hit). Blocking an attack also causes the attacking creature to stagger, allowing for some very simple block-attack strategies. Now there was some combat, but the AI was bone stupid, it would just run up and spam attack. To fix this, I booted up Morrowind to see how it’s AI in that game acts....since it is the most similar game in style that I could think of. In that, an enemy will run up and attack, then either pause in place, or move around to attack from a different angle. That isn't too hard to do, so I added that to my wolves. The combat feels bad, but it does work enough for now. Definitely something I'll come back to later. The last thing I wanted to add was some sort of points system to make up for the lack of any looting at the moment. My level generation has a section marked 'treasure' so I made it so that chests were placed into levels at these places. When a chest is 'activated', or a wolf is killed the player receives points, in order to have 'completed' the level for my assignment, a playthrough will need to kill all the wolves and find all the chests. The points are shown in the top right of the screen. That’s it for now, hopefully I'll get another post up sooner than a month next time...but probably not. As an aside, I've just finished organising what I'm going to be doing for the next few years now that I'm graduating. I've put in application to start a PHD with a living expenses scholarship, where I'll be working with VR technologies in one of the university labs. With any luck I'll get it and be able to continue this game dev while I'm doing research.

I figure I should outline what I'm doing next and why exactly it's the next feature to work on. At the moment I am doing a course at university on human computer interaction and am doing a project based around disability accessibility. The first part of the project was a written report on one handed gamers, but now for the second part I'm doing a more practical task. Using what I learnt writing that report, and my own experiences, I'm going to attempt to design a controls system for my game that would allow it to be played with one hand. The reason this is a worthwhile task is that I've made my game using the standard, movement keys and mouse look, which is actually really hard to control with one hand....just try playing Skyrim using just one hand....it's possible, but not easy. So that's the task, but what do I need to do? Well I need to add some 'game' onto my game, such as the ability to do many different actions, and some gameplay (such as killing enemies) so actually test the control on. Here is my list: 1. Finalise the character model. At the moment I have a character model, but it only has a few animations because I was unsure how many more bones I needed to add to it for animations. Hell I wasn't even sure on the visual style I wanted. But to move on I need to make a decision there. 2. Create animations Once the character model is complete, I need to create a bunch of animations. Attacking, running, jumping, blocking and stagger. 3. Program interactions. At the moment my wolf creature will load in, path to the player, and attack non-stop. I need to improve this AI a little, then allow for some simple combat. The wolf needs to attack, then pause (either moving or not) then attack again. For the combat, I need to be able to attack and do damage, block attacks and take damage. 4. Once this is all done, I can look at designing some controls systems for my project. Ideally I want this to be designing controls by the 19th, I feel if I buckle down I can achieve all this by then. The hardest part will be the programming, but it'll be the most fun aswell, so here hoping that is smooth. PS: All this animating I have to do, I hate animating. I'm a programmer damnit, not an artist. PPS: Here is a picture.

If you really wanted to make a 'true' sky, you could make a sphere, then use a bunch of maths to calculate what colour the sky would be based on time, sun location etc...but it's really overkill, I did a little of that in a previous project, but it's more hassle than it's worth. What makes spheres so hard to texture is that it is just difficult to map a 2D image over a 3D sphere without getting seams (think trying to put a piece of paper around a ball).....a good artist can do it, but it's definitely not easy. I think you'll find in a big AAA game, how you described is exactly how they would do it, as it gives a good artist lots of control over how things look, but I'm not a good artist, so I do a simpler technique. If you do a quick look around online for skybox textures they are normally cubes with 6 textures, one for each side, which is why I think a bigger game would be like that. This works fine if you just need a static sky, but if you want moving clouds and weather effects (like I want to do eventually) that system doesn't work. Also, the main reason I wanted to only have 4 images is because of powers of 2. For mipmapping, it helps to have textures with sizes that are a power of two (so they can be divided down easily), which is fine if you want 1, 2, or 4 images in a texture....but if you want 5? well you'l have 3 empty spaces in your texture. I hate wasting space like that, especially in a texture that is going to be big already like a skybox.

Sooooo....I'm really lazy. The North and South look at the same, just mirrored, so I can used the same picture for them and just flip the UV map. Then the east and west each have their own image, and then the upward plane has it's own texture. There is no sky downwards...so I just cut off that part of the box and therefore it doesn't need an image. I tended to have some 'seams' along the edges of the box, so I added some more vertices to each side and pressed the 'smooth vertex' button a few times to deform it into a sphereish shape which helps hide the seams a bit cause they are now bent instead of straight lines. I make things up as I go along, I have no idea if that the 'proper' way games do a skybox, but it works well enough for me.

Had a uni report that was taking up all my time over the last few weeks, but that's finished now, so it's back to some game dev. I will come back to my water shaders later, I need to work on the refraction a little bit to make it look better, but for now I want to do the next thing on my checklist. A day night cycle. First off I need to make a skybox, this is where the texture for the sky goes. I started with a cube and just grabbed a skybox texture off the internet to see how it looked....not bad but a long way from what it should be. I've decided to separate the gradient of the sky from the clouds, that way I can have a static sky and move clouds around to make it more 'dynamic'. I've talked about the gradient of the sky before on here in an old topic, but here is the basics. On a clear sky you have almost white at the horizon, and a deep blue straight up, with a gradient in-between. Using a skybox, I can have a radial gradient on my top square, then have a vertical gradient going up the side squares. Night time is also easy, since you can apply an almost black colour across the whole thing....no worries. But dawn and dusk are much harder. Now you need a variety of colours on one side of the sky, with it fading to a solid colour on the other side. I ended up using Illustrator instead of Photoshop to make these since it's gradient tools are a bit more advanced. With a bit of playing around, I ended up with a dawn texture that looks like this: Now to the implementation in the game engine. The skybox is actually quite interesting, as it is implemented differently than you'd expect. It is actually a small box placed over the head of the player, and through some graphics tricky by making everything else render in front of it, it appears as it it's far away. The reason I do this is so the horizon moves with the player, I could have made it just really huge, but then you run into depth precision problems from making your view distance too big. The cube is then rendered, and depending on the time of day, it can transition between the different sky textures to give the appearance of it changing. The other important object in the sky is the sun and moon, so that was next. The sun and moon are simply two billboards that rotate around the player's head in a similar way to the skybox. The sun is simply a white sphere with a yellow glowing edge, and the moon was just some grey smudges and lines with a smaller glowing white edge. Basing their rotation around the player's head on the time of day in the game I could simulate them moving across the sky. Then I simply applied the time of day to effect the ambient light in the level and And Ta-Da! I have a very simple day/night cycle. Here is a video I made of it:

Phong actually has a bit of a sad story. He defined Phong Shading and the Phong Lighting model in his PHD thesis in 1973, models that are used to this day....while he was suffering terminal leukemia and died only 2 years later. It really was a case of someone who had so much potential dying way too young.

I suppose you can't see it, but in the picture above that light is being generated by a wall torch, that is not a player light. Water is a tricky beast when it comes to light. For example, normally you work with Ambient, Diffuse and Specular.....but Diffuse doesn't make sense on water since the surface doesn't block light, and ambient tends to be applied as a constant. The reason I've added the player light is just to give a little definition to the water shape when there is no direct light source to generate specular. I guess you could think of it like applying the level ambient light, just as specular. Thanks

There is a rule in games graphics that near enough is good enough, perfect simulation is great, but you have to make a trade off with performance to achieve it. For example, if you want realistic lighting you would use ray tracing, but that's too expensive for games, so a variation on the Phong model(ambient, diffuse, specular) is used instead. Now I was going to calculate the normals for the waves, then use them to figure out how have the reflection would bend off the water....and I realised....that's too much. My technique of just moving the sampling position around does a fair enough job of bending the texture, who cares if that's not how real water would look. I did still need the normals though, and I wanted the water to look a bit more 3D, so I moved the heatmaping to the vertex calculations (which also makes it faster, since it is expensive and doing it per-vertex is better than per-pixel). Here is a trippy picture of the normals applied to the waves as calculated on the per-pixel basis. On a tangent, unlike regular programming, you cannot 'print' out values to debug shader code, and you can't stop it during execution to see what is happening. This is because everything is happening in massive parallel on the GPU, so your only choice in debugging is to display out colours and try to figure out what is happening. This can be very frustrating if all you are getting is a black screen though. Now with 3D water, I needed to add lighting effects to it. This was a bit hard, but long story short, this is how it works. I need to blend together the reflection, the refraction, the colour of the water and the lighting values. The refraction and reflection already have the lighting applied to it's colour from rendering the picture, so it only needs to be applied to the water colour. In order to blend the water colour, the colour based on reflections is calcuated, then the water colour with lighting is added to that value. As long as the water colour isn't too bright this works well. However there was a problem, when it was fairly dark, the water looked bad, it was mostly black so you couldn't make out the movement. To fix this, I added an extra small light coming from the player's view that only applies to water. This then adds a small, but important, specular highlight to the waves so you can see them. Here is the finished product:

I was actually lucky enough to do a course on the graphics at university, which is known as the hardest programming course at my university. I'm not quite sure how you'd learn to write shaders without a really in depth lessons like that. It's all matrix/vector based maths, with some trigonometry thrown in. If you were just learning shaders you can start at the bottom, translate vertices into the right places, then sample pixels from a texture. But in OpenGL 3.0 onwards even that requires knowledge of the different screen spaces and how to build a projection matrix. There are of course tutorials, but I can't really point you to any and say 'this one's good', since i never learnt from them. In fact, I'd say most people are better off using what shader system a more advanced engine has, things like Unity and Unreal have very good tutorials for writing shaders. In terms of an editor, that's all just several years worth of software engineering knowledge, I've copied things from other game engines, like Bethesda's modding tools, and Unity.....but other than that it's just making whatever I think I need. This was my second attempt at an editor, so I was able to copy paste of the bits from my old one, but it suffered from a lack of planning as it was my first attempt at such a program. The editor itself is just Windows CLR C++ program, but for someone new, they would be better off working in C# for such a thing.

Okay, time to talk about what I've been up to. I've got a bunch done on the editor, object lists, and modifying the level. I need more game done though before i continue as some objects have not had all their attributes listed yet, so it's no worth creating editing forms for them. Here is what it looks like now. So it's back to the game, and I feel like doing some graphics stuff again....so it's time to write a water shader. In my levels all these pits are supposed to be filled with water (or not, I can set a water level in the editor). These pits: So shaders are used to colour in all the pixels on the screen once all the complex graphics stuff has happened....but a water shader is different again. Water reflects light, so if you view it at an angle you'll ofetn see a distorted reflection of the other side. Water also distorts your view underneath it, warping the shapes of things below the surface. Lastly it often has a colour to it (if not perfectly clean), so that also has to be added. So first I need to make a reflection, this is actually a common thing in complex graphics, so OpenGL has a thing specially built for this called a framebuffer. It allows me to render an image, then use that image as a texture on a future render. So we move the camera to the reflected position relative to the water, take a picture, then when we draw the scene, use that picture to draw the reflection. There is a tons of maths involved in that, but that's the simple version. Here is how it looks: That's a bit boring though, and unrealistic. Water tends to move (and in games it looks bad if it's not moving), so I need to find a way to move the water. The water itself is a single huge flat plane, so what we need to do is 'fake' some waves on it. The technique I eventually decided on, was to use pseudo-random points (not random, so they look random, but will always generate the same) and build a heatmap with them. The closer a pixel is to a point, the more it distorts the image. Without the texture, this is how the heatmap looks: Would you believe that those points are actually in a simple square grid, just a bit of cool maths to 'randomise' them, without it being random. Then when it is applied to the reflection picture: Each of the points move around in an ellipse and can overlap to give an interesting visual. However there is a big problem, water doesn't act like a perfect mirror, we need to see the bottom. Water refracts light however, so we also need to distort what we see. Another frame buffer to get a picture of everything under the water, and then we apply the same heatmap to distort that and tada! We have something that looks decent: I'm not happy though, I've done a good job at faking the water movement, but my technique is just distorting texture sampling and not doing proper transformations. For that I need to calculate normals, and if I'm going to do that, I might as well make the water plane itself move. Instead of a single huge plane, now the water is made up of many small squares, I can then apply that same heatmap to those points to physically move the vertices. That's where I'm up to, I'm going to go do that and see how it goes.

What do you want to do with this lesser power? Just give it to the player?

So geez, what it's been about 12 days since the last post. Let's see what's been happening. Ignoring about a week when I was too sick to work again, I've done a heap of stuff. Last time I was working on AI, but with a working basic AI, I needed some more content. If you want things to fight, they need the animations to do so etc etc. Realising I didn't want to go make more animations right then, I moved onto something else. First I wanted to create a new tileset, I was getting sick of the stone wall dungeon, and wanted to experiment with an outdoor tileset. The idea behind this one was the walls would be tall grass and open to some sort of skybox. It’s built with all the same pieces as before, so I can seamlessly swap a dungeon to it. Picture: But in creating this new tileset another long standing problem was starting to become worse, the fact that most the content is hardcoded into the engine right now, or in very basic text files. Essentially what I need is some dev tools to build the content with, so onto that! If you’ve seen my past projects I have actually started one of these before, so it was time to open up that project and copy a bunch of the low-level guff that I needed to create windows and draw stuff. And after a sortish while I have something that is starting to look like a level editor. At the moment it’s still loading all the content from within the code, but that’s fine, once I have everything loaded in and editable I will start building the saving system. I can currently load the only level and move stuff around. Next I need to build the object lists so I can added and remove items from the level. Picture:

It's big, but I'm taking every shortcut and design choice I can to make it smaller. And really, the content is what takes the longest to make, engine programming can be tricky, but it's much faster than modelling, texturing and animating a single object in the game. It's also why I'm going with a pixel style of art, since that is quickest to make without it looking 'terrible', nothing worse then going to 'realistic' and missing the mark badly. Making a game engine is really a case of problem solving and copying. You look at a system from a game, think about how you would program that, then try it out. In my case I am interpreting Bethesda's engine as shown in the Construction set, then fine tuning it to suit my needs. When making a new type of object, I frequently will open up one of the modding tools to see what sort of data they stored in order to give me ideas on what I might need. That guy is taking the easy way doing 2D graphics, I prefer 3D, it makes the problems harder But in all seriousness, 3D is only harder because all the maths becomes three dimensional, I've taken a (very hard) course at university that taught me a bunch of the 3D stuff, it is certainly not where a beginning should be. To that end though, simplifying to 2D is really useful, for example my collision model uses a 2D map so that I didn't have to do 3D planer stuff or 3D line checking, same with the AI pathfinding all based on 2D. Whenever I can I try to move a system into 2D.

I'm using C++ for the programming, basically because I already had a bunch of boilerplate code for setting up windows/opengl for C++ from other projects. I also like the raw memory manipulation you can do with it. More recently, I was able to take an existing (from a university project I did) A* star search class and plug it straight in, which was nice. I'm using the Collada file format for 3D models, exported from Blender. Using PNG files for textures and photoshop to edit them. Other than that, I currently just have various handwritten text files that provide additional information. Such as level data, animation information that isn't stored by the collada format etc.

DMEval (Dev Title) Last year I had A LOT of spare time and I spent some of planning out what I could do if I was to create a game. I've played around with creating a game engine a few times, but never really got far past loading a single level and moving around in it. But it's all valuable experience, and so this time I am making a game proper, and doing it all myself. I enjoy systems, figuring out and solving tasks within a game engine is way more interesting then actually creating game content. Not that I can’t make content, I have a reasonable understanding of Photoshop and Blender, but when it comes down to it, I prefer to write the code to sample animations, then to create the animations. For that reason, I’m not using a game engine like Unity or Unreal, I’m creating an SDL2 Window and drawing my game into it. Now about the game itself. I have a vague idea what the ‘world’ my game takes place in, but nothing in concrete yet. What I do know is I am creating a 90’s style RPG, think early Elder Scrolls, but with more modern mechanics. In order to make the project possible, I need to make content creation as quick as possible, so that has a huge impact on how the game is structured. The world will revolve around a central hub town/city/place from which you can travel (through menus) to dungeons. A dungeon is laid out using a bitmap, then within a level file other objects such as lights and furniture can be added. I like to talk things out when developing, in order to understand what I’m doing and to improve on it, so I’ll use this thread for that. Most likely reflecting on aspects once they are completed. 13th July 2016: For the past few days I’ve been working on the AI, previously I had written pathfinding code to allow an NPC to move around the level, but now I need to make them go into combat and do more complex movements. I have a special “AIHandler” class that makes all the decisions and sets all the AI variables depending on what happens. Then when the NPC is updated in the game cycle, it reads all the AI variables and applies the correct animations. The reason I need this is to get a final animation list of creatures in the game. I was creating my ‘wolf’ enemy and found that since there was no combat, I didn’t have a complete list of animations that the wolf needed. Like everything, the less animations I have to create the better, so if I make the combat I can determine the bare minimum. My AI is now able to go into combat mode (and out of if they lose sight of you), then will path toward the target and once in range attack. At the moment attacking doesn’t do anything, so that might be the next task, but it’s taking shape. In order to determine who to attack, the AI is assigned into factions, so the wolf is in the Wolf faction, which has a dislike for anyone not in the wolf faction. The system still needs work, but it’s good enough for testing right now. At the time of writing, here is a picture of what it looks like. FPS: 1400 (which for sanity, game logic is capped at 1000FPS)

So it's been about 2 and a half years since this topic started and finally the end has been reached. This project has had it's goals changed multiple times over the course of the project, but finally the WebRender HTML5 software render has been released! It may not be a game like what was originally intended, but it is still a very interesting piece of programming where JavaScript has been made to do things it was never intended for. Check out the website! www.webrenderjs.com Now the game has not been scrapped and the game engine is currently under-construction along with some other stuff to do with it. Hopefully start a new thread in the new years with a bunch of new content.

Yeah, I had balance tests, and although they suspect there is something wrong, it is not the cause of my problems...just a symptom.

Thanks everyone. :) Yeah, that was the first thing they tried back at the start of the year. Before this, sinus infections were the main cause for a migraine, so as soon as I got one a round of antibiotics would be used to clear it up. It's not really painkillers that I'm on (since painkillers actually do very little for the type of pain I have), it's a anti-migraine medication that suppresses symptoms caused by migraine. But after this long you just start getting used to having some pain at all times. The problem is that migraine can be caused by SOOO many things, and also many other things can have migraine like symptoms, so we just work through the tests and try to find a cause. As I said, this last round of tests have finally revealed some problems, so hopefully the cause will be found soon.

Where are we? 6 months on now, time for and 'update'. Started getting better late May, before taking a bad turn and basically too sick to get out of bed for a month and a half. Was moved to a Neurologist to look for a new cause, and also to try some different medication. Am now on a stupid high amount of migraine medication that at least lets me sit around and do some work on my laptop (though sitting at a desktop for a period of time is too difficult). I've had a bucket of tests that haven't turned up much yet, though they have suggested there might be something wrong with my blood pressure or heart, I'll have to wait until I see the specialist again with the last lot of results. So basically I'm still at the same point as 6 months ago, I do try to get on TESA....but I just seem to keep forgetting.

Welcome! You are not the only Aussie that lives in the middle of nowhere

One of the paid guys listed all the places that you can send part of the money to. TESA was not on the list, there were only about 5 places which Valve/Bethesda had negotiated with. It was only places that pop'd up after skyrim modding got big, as I hadn't heard of any of them except the Nexus. I think it was one of the earlier topics on the official forums, bugger if I remember where.

They do, they release using the MIT license. However the team feels that if they tried to take action and enforce the license they are more likely to get shut down on legal terms (since hacking the exe is a real grey area) than actually achieve anything. And if they were shut down, modding would be killed off and nobody wants that. As someone who follows TotalBiscuit's work, the video is okayish. He approaches it from the wrong standpoint as he knowingly states he has never been a part of a modding community. The first third is about the positives, the rest is the many problems with this....though he misses some of the more specific problems like sharing, team mods and legal problems. He also followed the video up with a 10min audio log to further expand some of the problems that he didn't explain well and had feedback about. Video: https://youtu.be/oGKOiQGeO-k Audio Log: https://soundcloud.com/totalbiscuit/thanks-for-the-thumbs-d

All I can say is that the Bethesda Forums and Steam forums are having their communities tear each other apart as users and modders attack each other over this. The nexus community however is having a much more civil conversation and the same thing here. I'm starting to think one of the outcomes from this is that people just move away from the traditional mod creation places. One good point was the mod tool makers were not consulted on this. The guys that make niftools and the blender plugins have done so for many modding communities....these tools are used by most mods for models. Now I am sure these guys will have the same stance as SKSE and not have a problem with making paid mods. But not every tool maker is going to be as nice. How long (most likely in future games) before we see mod making tools that cost money to use? Bethesda has a terrible track record with providing tools that work (and never have given model making/exporting tools). That is my biggest concern, when I started I couldn't have paid for modding tools, and if things drift that way younger modders will look to other games.