If you've read my previous post on paid mods for Skyrim on the Steam Workshop then you know that Valve was met with resistance from the gaming community. Amazingly enough just 4 days after the announcement Valve decided to go back upon their decision of enabling modders to sell mods on the Steam Workshop. I think this was a hasty decision which will have a negative impact on the future of modding, as well as Valve as a company.

Allowing for paid mods on the Steam Workshop was a bold move, one that could have ushered in a new era of mod making. Change is scary though, and whenever you try to change something people are going to get a bit upset. That's normal though and as time passes and people start seeing what those changes actually mean and they suddenly seem less scary. People were afraid about what they thought paid mods meant however they might have not understood all of the benefits that they may have meant.

There are things that Valve did wrong however which could have 

Something that I found astonishing was that the owner and founder of NexusMods which is probably the largest Skyrim modding community had no idea that Valve was unveiling something like this. Valve should have done their research and found this guy and brought him in to get his opinion on what they were trying to do. If anybody understands the modding community, or knows people who do understand it, then it would be that guy. He would have been able to give Valve some insight on what they were stepping into and what sort of assurances Valve and Bethesda would have to make to keep people happy.

A common complaint from gamers when it came to Skyrim paid mods was that the Workshop would become filled with cheap, poor-quality mods since there was no official curating of the Workshop. It's great that Valve is providing a marketplace for paid mods but this is actually a valid complaint that Valve should have predicted.

Valve needs to police the paid mods section of the Steam Workshop and keep sub standard mods out of it. Yes this means that Valve has to spend money to curate it however if paid mods do well (like Valve should want them to) then it should pay for itself. At the very worse Valve can appoint community members as mod curators which will weed out mods of poor quality which nobody would buy.

This could even be expanded upon by having certain requirements that paid mods must meet to be sold on the workshop however I'm not going to get into that.

From what I've seen, there were quite a few people who were only against paid mods because of the cut that mod makers were making compared to Valve and Bethesda. I mentioned this in my previous post and I still stand by it, I firmly believe that the content creators should be the ones coming out with at least 50%. If you want to understand my reasoning behind this then I'll direct you  back to my previous post. I will however say that I believe that by increasing the cut that mod makers make, it will also lower the average price of mods.

I don't actually know what you'd call a mod that many other mods depend on, so i'll just call it a "Core Mod" since it's required for many other mods. A very popular core mod called SkyUI was going to become a paid mod following the announcement of paid mods on the Steam Workshop. This caused a lot of people to become very angry since it meant that it would become required to pay for SkyUI if you wanted to use other mods, furthermore many free mods would rely upon SkyUI causing you to indirectly be forced to pay for free mods.

This is a very grey area. I believe that the author of SkyUI should receive monetary compensation if they wish, however since many mods already rely upon SkyUI it would be unfair to force all the players who wish to use those mods to suddenly have to pay for SkyUI. I believe a solution to this would be to make SkyUI free and instead a small percentage of the profits from all the paid mods that rely upon SkyUI will go to SkyUI's creator. This will solve the problem of the creator wanting compensation from their work as well as keeping free mods which rely upon SkyUI free.

Another solution would be to enable developers to release two version of their mods, a free version and a paid version. In this instance SkyUI could have a free version which free mods can depend on, and a paid version that offers more features that other mods can take advantage of if their users have the paid version of SkyUI. This would be a somewhat tricky solution to implement since it would mean that mod makers who depend on SkyUI would have to write code to support whether the player has either the free version or the paid version. 

This sort of situation however really only happens when a core mod suddenly goes from free to paid probably wouldn't happen if the ability to sell mods was present at the time the Steam Workshop opened for Skyrim. 

This isn't the end, at least I hope it isn't. Paid mods have worked for other game(s) and I strongly believe it can be done in the Steam Workshop. Valve had good intentions they just made some critical mistakes, and speaking of those good intentions I want to quote them here.

Excellent, I can get behind this 100%

Extra "encouragement" (money) is great for developers, but this shouldn't be a significant source of income to the developer. At the very least the developer should be making enough to pay for people to update modding tools, fix bugs, release new modding features, ect. Furthermore as the paid mods market grows so does the developers income so they should be placing their bets on the market growing.

This is very noble of Valve and I also support it and I feel like this is the best way to bring this about. This is the kind of future I want to see modding and the game industry to have, where games can be grown from mods seamlessly and organically.

So you've implemented lua into your game engine except now you're asking yourself, "When do I run my lua scripts and call the lua functions?" This is actually a pretty complicated question and requires a lot of time and thought to structure out what belongs where and how things interact with each other. If you've read an earlier blog post of mine then you've heard me say that the number one rule is: Minimize the number of times you have to go back and forth between lua and C+. Moving forward with the article we are going to continually refer back to this rule.

You need to call your lua scripts somewhere in your code so let's start off by figuring out where exactly we call the scripts from. Lets take a look at an example of the flow of logic across a single frame.

Pretty straight forward, we check for input, run game logic, progress our physics simulation a step, update our audio system, draw to the screen, and then repeat. So now let's take a look at each step and decide if that step involves lua and then later we'll go into how to structure it.

Input: All we are doing here is filling our keyboard state, gamepad state, and mouse state structs so that things like gameplay code or scripts can use it. Lua shouldn't be called here.
Game Logic: This is what makes our game a game, we run all the code or scripts that have to do with our gameplay logic here, so it makes sense that we should also call lua here.
Physics: Our physics engine is probably in C++ so we aren't going to call lua to do the simulation, when two objects collide however we might want to have some sort of gameplay logic however which may be in lua.
Audio: Most likely we're using something like FMOD or Wwise which you update every frame by calling their API's update function. I'm not sure why you would need lua in this step since any function calls to play a sound should be done inside of your game logic step.
Graphics: We need to draw things to the screen and this is where we do it. There are probably C++ sprite components which have a Draw function that gets called here and if we have lua scripts that draw things then we probably want to call those here.

So 3 out of our 5 steps involve lua scripts, Game Logic, Physics, and Graphics. Before we take a look at each step individually let's learn about something I call event hooking (or event handling.)

If I have 100 components to update wouldn't it be great to just call one function which updates all of them? Or better yet, if i'm in C++ and I want to run 100 lua functions involving gameplay logic, wouldn't it be great to just make one lua function call which then calls the 100 other functions so I don't have to jump back and forth between lua a hundred times? Of course it would be so let's make ourselves a way of "hooking" functions to an event, and then when we call that event all of the hooked functions get called!

Imagine this as having different "hooks" each corresponding with a specific event for instance Game Logic Update, Frame Update, Draw, User Interface Draw, ect. We "hook" functions and their context (in C++ this would be a pointer to an instance of the object we want to run the function on, in lua it would be the object's table) to the event and then when the event gets called we in turn call each hooked function. This is important since that means we can make a single lua function call from C++ which will then call the rest of the lua function calls we wanted to make.

A Hook System as described is very easy to implement and can be less than a hundred lines in lua. Here is an example interface:

 --[[ Hooks a function and a context to an event. The context will be passed in as the self variable to the function ]]--
Hooks:Add(event, context, func)


--[[ Removes a hooked function and context from an event. ]]--
Hooks:Remove(event, context)


--[[ Calls an event, ... so we can support a variable number of arguments ]]--
Hooks:Call(event, ...)

Now that you know what Event Hooking is let's talk about examples of using it.

An inefficient way of running update logic on all of your lua scripts would be to call each update function individually from C++, there is any easier way however. With using our hook system updating game logic lua scripts we just have to make one function call. The only thing we need to do is hook any functions that need to be run every update to an event like Logic Update or Frame Update and then call the event on our lua hook system.

By doing this we've drastically cut down on the number of transitions between lua and C++ which will greatly help our performance. If you end up needing more than just one hook call to lua inside of your game logic step then you might think about creating a GameLogicUpdate lua function which then calls each hook you need in their proper order. This however will give you only minimal benefits and might make your code harder to understand.

The only lua involvement that will happen during the physics step of your game engine will involve game logic that needs to be run upon two objects colliding with each other. It's probable that this will only ever happen for a few objects but it's important to make a solution that will scale nicely since you never know where you game might take you. Personally I've never had to deal with it but these are the steps I would take.

First off we need to cache every single instance of collision that happens in our physics step. This will probably be easy since we may already have a list of manifolds we use to resolve collisions between objects. Now that we have that list we should filter out any collision instances that we don't actually want to trigger a callback for, or keep them all, it's up to you.

Now we have a list of collisions (which should contain handles or pointers to the two game objects involved in each collision!) and we are going to send that to a lua in a single function call which will process each collision instance and run any necessary callback functions. Except for oh wait, we don't have anything to handle that yet! We have our hook system except that works for global events, not object specific events. Taking care of this should be a simple task of encapsulating an instance of our hook system into each lua object we have so we can hook functions to events which are object-specific which will not only allow us handle this situation but many others involving per-object events!

This is a big once especially if you're doing lots of draw calls from inside of lua. Similar to what we discussed in the Game Logic step we need to hook every single lua draw call and then simply trigger the event in C++ which will in turn call all of the lua functions needed. I'm not going to make a diagram for this since it's essentially the same thing as Game Logic.

In my Sophomore game project we had multiple draw hooks which were called per frame: Draw, PostDraw, and GUIDraw each with their own purpose. We did however run into problems caused by lua making hundreds of C++ draw calls per frame which breaks our rule of "minimize the number of transitions between lua and C++." We can solve this issue however by batching all of our C++ draw calls into one single call by using an array of all draw data.

Depending on how you use lua there may be many more times that you want to call lua functions from C++ and by no means should you try and restrict your calls to the three steps we've discussed. For instance I've heard of people actually using lua scripts as a way of creating their levels, it's essentially a list of instructions on what objects to create, where they should be, and other attributes they have.

Another very important instance that I left out involves tracking the creation and deletion of game objects inside of your engine. This will be discussed in another article involving the structure of your lua interface.

It's important to understand the fundamental differences between lua and C++ so we're going to briefly discuss them here. First off I want to explain the difference between "code" and "scripts" since I will be using them quite a bit in this post. When I say code i'm talking about C++ code, this code gets compiled into machine language, on the other hand when I say "scripts" i'm talking about lua "code" which is interpreted instead of compiled.

Interpreted languages such as lua are never compiled the same way C++ code is, instead it is read by an interpreter which runs the script by calling corresponding machine commands. Something that you may be interested to understand more about how this process works is if you've worked in Visual Studios and you've seen the disassembly of your code which shows your C++ code as if it were in Assembly. Lua has something similar called instruction sets which you can learn more about if you wish but isn't very important to this article.

Lua is (arguably) easier to use, understand, and learn than C++, but more importantly it is quicker to program things in lua. The killer though is that lua is an interpreted language and therefore a single line of lua costs more than a single line of C++ code, there are ways of lowering that cost though. However most of the time this doesn't matter to us, in fact I wouldn't ever worry about it unless you're doing some sort of computational heavy algorithm, parsing lots of data, or anything in massive volume.

As a rule of thumb, if it's gameplay logic do it in lua, if it has to do with the engine then do it in C++. The whole point of using lua is to speed up iteration whether this be gameplay, ui, hud, menus, match making, or anything that requires lots of tweaking. Lua scripts however need to call C++ functions eventually which leads us to the next part.

If you're using lua for gameplay logic then it's more than likely that you're going to be transferring vectors (2,3, or 4 dimensional) back and forth between your C++ engine and lua. You probably also have a math library with lots of functions relating to vectors like dot product, cross product, ect. Now wouldn't it be great to just have lua call your C++ dot product function, C++ is faster right?

Wrong. Well right and wrong, C++ is indeed faster however calling a C++ function costs you, and for each argument you pass to the C++ function it also costs you, same thing with getting a return value (which you can get more than one of in lua.)

With each box in the diagram there is an implied cost for that operation, for every bit of data transferred through that box the cost increases.

Instead of using a C++ dot product function we should use a lua dot product function instead, this will significantly faster than having to transfer the data to C++, do the computation, then transfer the result back to lua. Keeping the cost of this transfer in mind when implementing lua into your engine, as well as using lua in your engine is very important since this can quickly slow your game down.

You may or may not be using reflected C++ classes in your lua implementation (this might not be the right term in describing this but to me it makes the most sense.) If you have a metadata/introspection system in your engine then you can easily tune it to reflect C++ types into lua which will allow you to easily and automatically convert C++ data types to and from lua (by using lua's userdata functionality which allows you to attach binary data onto a lua object.) This allow will help in allowing you to tie C++ functions onto lua objects so that you may take advantage of lua's object oriented features. For instance we could call our C++ dot production function by doing:
local dotResult = myVector:dot(otherVector)
I'll probably write a blog post about the specifics of this later since it is very useful.

Using reflected classes and functions in lua is not always the best idea however, a great example of this would be our vector math library. In this case we should write a vector meta class (a meta class is the lua equivalent of a C++ class) as well as a lua vector math library. Then whenever we transfer a vector from C++ to lua we convert it into a lua vector and if we ever transfer it back to C++ we convert it to a C++ vector.

By doing this we actually increase the cost of transferring a vector back and forth between lua but we in turn cut down on the number of times we have to transfer that vector back and forth. Thinking towards the future and making these kinds of changes in your code and scripts are incredibly important to keeping your game running fast. When asking yourself if you should convert data into a lua meta class instead of sending it as a reflected C++ class, think about what sort of functions are attached to that class, what they do, how expensive they are, how often they are called, and if those functions call other functions which are in C++. 

In my Sophomore game project all of our UI and hud were done through lua since it allowed us to quickly prototype and iterate on the design without having to ever close the editor (Script hot reloading is a life saver.) There were some problems that arose from this however that killed our games framerate. Earlier I talked about the cost of transferring data to and from lua and how the more data you transfer the higher that cost gets. What's interesting however is that passing from lua to C++, five 4-byte integers (well actually it would be 8-bytes in lua but nevermind that) costs more then one 20-byte char array. This is big.

Really big. This means that if we package data together into a single argument instead of multiple arguments we can actually improve our performance. The only downside is our code will probably become annoying to read so we should only ever do this when performance is important, or when you have a specific usage for it. Like batching 500 draw calls from lua to C++ into one.

The big problem in some of our hud code was that we were making hundreds of draw calls from lua to C++ per frame. This meant that we had to jump back and forth between lua and C++ and back which becomes incredibly expensive. A solution to this is to instead load all of the data which we would be sending to C++ into an array, then when we have finished making all of our draw calls we send it all to C++ in one function call.

Draw calls are a great example of when you should batch C++ function calls, however don't go batcher crazy. Many things don't require batching, and when asking yourself if you should batch a certain C++ function call you should think about how often that function gets called (once a second, once a frame, a hundred times a frame?), how computationally intense is that function, and if it's even possible to batch that function call (never batch a function like changing an objects position.)

Minimize the number of times you have to go back and forth between lua and C++. Try to map out when and where these transitions are made and find points which have the highest volume and minimize them. By following these steps you will keep your lua scripts running fast and can push the most out of our game engine.

If you've been watching Reddit or any gaming news websites lately then you might of heard about Valve introducing paid mods into their Steam Workshop system. For those of you who don't know what Steam Workshop is, it's a platform that Valve introduced a few years back which allows players to download and use mods that modders have uploaded to the workshop. Until now all of these mods have been free of charge and with the recent announcement of paid mods, many gamers are up in arms.

In the early day of modding all mods were free and this meant hours upon hours of additional fun from games you've already purchased. Now it's important to understand that there are many different "types" of mods, and by no means can you consider all mods as equal. Some mods create such a drastic change in gameplay that they are nothing like the original game (see Half-Life or Half-Life 2 mods for example.) Other mods are much smaller and imply add additional features, quests, items, or even UI. These sorts of mods are much more common and are usually the ones found on the Steam Workshop.

"I paid X number of dollars for this game and I shouldn't have to pay for additional content."
Aren't DLC's exactly that though? Does the problem however, lie in the fact that the content was developed by a modder instead of the original game developer? Why would this be a problem though? Players constantly want more from their games, and mods give that to players free of charge. If you're the kind of person who doesn't want to spend any more money on a game beyond the initial investment then you already won't purchase any DLC's and purchasing paid mods obviously wouldn't be something you do either since nobody is forcing you to. This however leads us to the next concern.

"What happens when all of the currently free of charge mods become paid mods?"
This is a very real concern when it comes to the introduction of paid mods on the Steam Workshop. Without a doubt there will always be free mods, the real question is, are the best mods going to be free? Garry Newman, the creator of Garry's Mod which started out as a free mod before becoming a paid game, brings up an important point in his blog. Some mods just aren't worth charging for. If I create a simple mod that takes 10 minutes to make there is no logical reason for me to charge any money for it. There might be a few people who are willing to shell over a dollar or two for it except someone has probably already created the exact same thing as I, without a price tag.

Some mods however are the culmination of hundreds of hours of work from their developers who aren't going to make a single penny on it. For example take a look at Falksaar a massive Skyrim mod which adds over 25 hours of new content on a brand new land mass which is a a third of the size of the original game. Mods like this are rare, however they are also the most beloved by gamers. Falksaar is free, however many gamers would be willing to pay some sum of money for all the new content it adds to the game.

It's important however to think about what drives modders to create mods in the first place. Many modders simply enjoy turning their imaginations into realities through mods. They want to see new features, items, you name it, inside of the games they play. They do it for themselves just as much as they do it for the player community as a whole. Many of them don't care about making any money from it and will continue to create mods free of charge since it's their passion and they don't want to turn it into a job. We'll talk more about this in a later paragraph.

"The creator of the mod gets only 25% from Skyrim Mods!"

We should look at each party and justify why they deserve a cut of money made on selling a mod. We have Bethesda, the creator of Skyrim, Valve with the Steam Workshop, and the modder. Bethesda made Skryim, they also made the mod development kit that modders are required to use when creating Skyrim mods. Valve made the Steam Workshop, and the modder came up with the idea of the mod, used the development kit to create it, and uploaded it to the Steam Workshop.

Valve has to pay every month to keep the Steam Workshop running. All of the mods on the workshop probably takes up quite a few terabytes, which they have to pay for. The bandwidth for players to download these mods also probably adds up, and they have to pay for it too. Valve is the only party in this situation that actually has any sort of monthly cost they must deal with. Bethesda already created the game and it doesn't cost them to have mods sold, and modders just have to pay their bills, but that's not really relevant.

It's obvious that Valve is the one here who has a cost associated with mods being sold (or even the Workshop existing in the first place) so definitely deserve a cut of the profits. Bethesda was the one who made Skyrim, and without the game itself there would be no mods, so of course they deserve a cut of the profits too. The modder didn't have to make the Steam Workshop, and they didn't have to make the game either. If anything they did the least amount of work out of all the parties, but without them, there would be no mod to sell.

So is 25% for the modder really fair? As we've discussed Valve has to fork over money monthly just to keep the Steam Workshop running, not to mention they also developed it, they deserve a good cut of the profits as well. This leaves Bethesda which has already made their money back, but they still deserve a cut since without them there wouldn't be any mod's in the first place, the size of that cut could either be the same or less than that of Valve's but in the end what's really important is the share the modder gets. The creation of new mods should be rewarded graciously with atleast half of the profits going towards to modder themselves. It's no fair to see three quarters of your hard work going into someone else's pocket.

Paid mods were bound to happen eventually, and we're lucky that it's being ushered in by a company like Valve. Many of the employees at Valve were once modders and Half-Life started out as a mod itself. With the Steam Workshop we are about to see a period of time as both the modders and gamers begin to adjust and adapt to the new environment of paid mods.

There will be some terrible mods, but there will be more great mods. I am hopeful that in the future we'll start seeing paid mods with sizes similar to if not larger than the Falksaar mod for Skyrim. As mods becomes a profitable endeavor there will be more people who are interested in creating them. The added incentive of making money off mods also encourages mod developers to create them with a higher level of quality to attract more buyers. If anything we should start seeing higher quality mods appearing on the Steam Workshop then ever before, sure they'll cost money, but when they add features of the same quality if not better than the original game itself, can you really complain?

Imagine a day when there is a such a thing as a "Mod Studio," a game studio that just creates paid mods. In this future will they still be called mods, or will it bring about a new definition to DLC's? What if paid mods become so successful, so prominent, that game developers only release DLC's that they feel are just as good if not better than paid mods for their game? Is this not what so many gamers are demanding?

The future of modding may seem dark to some, but I can't wait to see what happens.