#aint209

The second Demo Or Die for AINT209 starts in just under half an hour. The game is functionally the same as before, and nothing's really changed in terms of gameplay, but a lot of under-the-hood functionality has been fixed. Before, there were about 6 different HUD scripts - now all condensed into one. As well as this, movement was generalised into a single script that uses the values of the axes passed into it instead, whereas before there was one script for each player. Speaking of players, I don't think anyone has actually played the game with four players yet, so that should be interesting. A few other little changes came into play as well - building on the final subspells of the C# Necronomicon - and some items were made Serializable because it made sense to see their values in the inspector. I fully expect people to ask why it's exactly the same as before, though.

[Side note: late post today, as it was my birthday on Monday and I wanted to celebrate instead of post!] Part The Last The final spell in the figurative tome of great and unspeakable evils is that of knowing the engine - exploitation. This spell is actually a conglomeration of smaller ones which allow the developer complete control over the Unity framework, and as a result, should only be attempted by Necromancers with a level of 20 or higher. My own level is not nearly sufficient to power these particular evils to their greatest potential, but nevertheless, it is worth trying. The first is concerned with delaying a MonoBehaviour. Sometimes, the delaying of a class or frame is useful for setup, as it may be reliant on others being set up first. To halt time in this respect, chant the Words of Power, sacrifice a goat to the Elder Gods, wear a mask made of the bones of your forefathers, and finally wrap the code that requires delaying in the following: IEnumerator Start() { yield return new WaitForEndOfFrame(); } The second is concerned with adding parameters to a destruction method, which could be useful for playing sounds as a GameObject is destroyed (a Wilhelm Scream upon death, for instance). The third is bending the custom editors from last week to work for inbuilt Unity classes - adding reset buttons to a Transform component, for instance, might be useful for testing animations. The fourth describes a way of making variable names, when changed, still serializable. Referring to that variable with its previous name may be important for values that need saving within the system, at which point the developer must paint their name with blood on the skin of an ox and use the following line of code: [FormerlySerializedAs(“originalName”)] Placing code in the correct folder is an extremely important practice - it can be a nightmare searching for prefabs in the code if there isn't a predefined folder to put them in. Organising a filesystem is imperative if a developer wants to share their knowledge with everyone, and, judging from a lot of online examples, is not adhered to as well as it could (guilty as charged!). This fifth subspell should be one of the most obvious and immediate to use when starting a new project. The sixth subspell is simple: keep Transform scales to a 1:1:1 ratio, if you can. [Side note: there are many others, but far too many to mention here.] How Could This Apply To Drunk Space!? The most important thing to gain from this final lesson in the C# Necronomicon is that if all else fails, keep a library of relevant, useful, or interesting code on you at all times. The internet may not be available everywhere, so it is always important to make sure that there are backups around of whatever one might need. The Necronomicon suggests backing up all data on previous projects to a memory chip embedded in the skin on the back on one's hand, but if you don't have one handy, a flash drive shall do instead.

Part The Twelfth A common problem with development is that when something is complete, there is a tendency to forget about what has been used in a previous game so as to make the next one better. A great example of this is in the first Kingdom Hearts game - after completing the game, the assets were mostly lost or discarded. Ten years later, when developing the HD remaster of the game, a lot had to be made again, pushing back development for several months. This is a product of forgetting the most useful of black magics - hoarding. A more practical application of this has already been mentioned regarding the object pooling spell, but it can be taken even futher when hoarding game objects and code that would otherwise be garbage-collected. Instead of allowing things to be simply cleaned up, why not have two methods that Create() and Release() objects as necessary? To cheat even further and awake C'thulhu from his slumber in R'lyeh, why not make them both into static singletons and make them only a few lines long? Adding GameObjects to the pool is simple enough - make a new PoolObject class and wrap up whatever is needed in it. Make a PoolList in order to see what's being used and what's not, and then add and remove PoolObjects as necessary. No destruction, no garbage-collecting, and a much cleaner-looking game How Could This Apply To Drunk Space!? An easy way this could be used might be for explosions - creating and destroying explosions for every single shot made would completely throttle the framerate, as it is currently doing. Hoarding the same shot over and over again, or the same few shots, and resuing them when necessary, might be a lot better on the framerate, but most likely would be rather hard to implement (unless you cloned the explosions as well as pooled them, which could take up more time than might be strictly necessary).

Part The Tenth The tenth spell allows for direct manipulation of the Unity MonoBehaviours. A programmer can manipulate the system's display functions in order to remove values that should not be editable and edit values that should not be. To this end, attributes can be added to values to stop them from showing up in the inspector, or to create new context menu items if necessary. The most useful values for this spell are [HideInInspector], which stops values from being edited without going into the code itself; [NonSerialized], which hides a public variable and stops it from being instantiated, and [ExecuteInEditMode], which allows a script to be initialised eithout being in-game. Part The Eleventh The spell of the custom editor allows a programmer to create new custom windows and inspectors over the top of the Unity framework. For instance, if a developer wished to load levels using an XML file, they could combine these dark magics together using EditorWindow to create a new window and populate it with whatever XML they would need to load at a certain time - exceptionally useful for large games with several levels to load. [CustomEditor(typeOf(SomeScript))] would allow for a custom window to be made based off an XML level loading script, for instance. How Could This Apply To Drunk Space!? Editing the values of the speed, pitch, roll and velocity of the players was a complete nightmare for both iterations of the game - the most annoying aspect being that I couldn't check to see if it worked properly or to a decent level of immersion without starting and re-starting the game - so it would have been useful to hide those values in the inspector when they did not need editing, and to allow them to be put into practice without constantly playing, which would have been good for attributes. A custom editor probably would come in handy at some point, but not with this game, as nothing really warrants its usage.

Part The Ninth The ninth spell of the Necronomicon is called the shader. Using this particular form of black magic allows the devloper to make a game go from good to moste evile great, as all a shader is is a program that changes the way that the renderer displayes pixels on-screen. This spell is divided into three subspells, or horcruxes, if one prefers, which allows the overarching spell to be used through three distinct stages. The first - vertex - takes a 3D vertex and processes it into a 2D position on the screen, along with colour, texturre, z-values and so on. Vertex shaders are used to modify the positions of a particular set of pixels (such as animation), and output to either of the other two shaders. Vertex shaders can only take in vertices, and cannot create them as a result. The second is known as geometry, and is used to take data from the vertex shader and create new vertices from them. Initially, these were used to handle things like tessellation and mesh details, but have seen more use in creating new primitives such as lines and triangles. Not only do geometry shaders take in the vertices, but also the various connections between them (so it can take in a triangle, say). The output of this shader is finally passed to the third subspell, which directly affects what the player will see. The last is pixel; used for displaying the final result of a shader on-screen. Pixel shaders take in vertex data, shade each face according to a number of parameters, such as global lighting, textures and position, and output them to the screen. Multiple pixel shaders can be executed per pixel, known as a pass. How Could This Apply To Drunk Space!? The suns that I used in the previous iteration of the game were very... samey. It was rather easy to become lost, or to fly off into nowhere, but quite difficult to figure out how far the sun was away from you, and so on. I sort of cheated when making them, too - adding a skybox texture to it rather than anything beter - so it may be worth using shaders to make them different colours, shapes, making them spin, and so on.

Part The Seventh Perhaps the oldest and most necromantic of the Dark Magic learned in the C# Necronomicon comes from its ancestor, C. In the language of old, classes were not called as such, and worked differently. In C, this was known as a Struct. All a struct is is a collection of data - so if you had three floats in a struct, they'd occupy certain bits of memory directly, meaning that everything is global and all relationships between that data need handling yourself. In C#, structs are used differently, and have evolved from their ancestor to be rather useful in terms of reference checking and keeping things simple. Structs cannot have a null reference, so there is always some kind of value in them (just like in dread C, where the data in a struct would always take up a particular position). Part The Eighth Though not really Dark Magics, the Necronomicon includes basic information of how to bend lists and arrays to the will of the devloper. The fundamental difference between the two is this: a list's size can be edited at runtime, but an array's size cannot. Because both use an internal block of data, this is the only true difference between the two in terms of Unitybending, but it means that lists will use garbage-collecting (from adding and removing entities whenever necessary), and conversely arrays are non-editable at runtime. So, if a developer needs a rudimentary inventory then a list would suffice, but if a certain number of assets require loading then an array would make more sense. In Majesty, an array was used for each album's cover art and music, but a list was used for collection of the albums. How Could This Apply To Drunk Space!? Structs probably would not be worth using as there isn't much to initialise at the start, and since lists and arrays are fairly commonplace, both may make an appearance later on once code has been cleaned up.

Part The Fifth The fifth spell is known as the static, and it allows a standard class to contain values that can never be allocated. The static class is more used for utility within Unity, where values that should not be changed by anything else are stored - kind of like a "settings" class. At runtime, the class is allocated once, when the application is executed, and that's it. So it's just a collection of global data and methods, which is incredibly useful if you plan to use the same things over and over again. It's good for wrapping up functionality such as movement, mathematical or string operations, and because they never get deallocated, it means everything inside it will never be deallocated, keeping the dreaded framerate spikes to a minimum. Part The Sixth And so we move onto perhaps the most useful of the dark magics - so useful that it's actually an industry standard in gaming - so for all those who assumed gaming was an evil soul-sucking industry full of hate and bile, you'd be right! I mean, even without XML you'd have been right anyway, but it's certainly a most evil spell that makes even the most lowly of developers look like Gaben Satan himself. It's a way of condensing an entire game, if you wished, into a single file. It looks a lot like HTML, except more evil; the developer can define their own tags, their own information to go within them, and whatever else. For instance, defining a <config> tag and then putting something like <player lives="3"/> inside it does exactly what it says on the tin. All values are strings and will need converting, which is fair enough - but otherwise, it's functional, easy to read and simple... the exact opposite of what programming languages should be. Using all the previous Dark magic spells within XML would be easily possible. How Could This Apply To Drunk Space!? Generating the entire scene in an XML would be pretty useful, but the settings probably wouldn't be worth the effort for the size of the game. Static classes would help with cleaning up code, so I may use one for the shooting and one for the movement of the spaceships (because having four different classes doing the same things depending on where it's attached is silly).

Part The Third The third spell of power within the C# Necronimicon is that of the Delegate, which is essentially a shortcut to functionality in the form of some kind of pointer. If a developer wanted to pass an argument to more than one method, such as a position setter, rather than using a boolean and passing that to a method, it it is possible to define a delegate boolean, which accepts a location to set a position to and passes back a boolean value. This could be useful for removing if-else statements for setting a position, because the delegate works via a boolean which works in the same way. Part The Fourth The fourth spell goes by the ancient name of Coroutine, which can be used to temporarily halt time - within a game, that is. Well, within the processing, at least. These are extremely useful for pausing one process to start another one, and then continuing that process once it is complete. Scripting events or waiting for an action would warrant using coroutines. Coroutines are easily recognised by the yield at the end of the method, which provides a break point in that particular method. In Majesty, I think I used a coroutine for checking to see which albums were picked up, or maybe I used it in initialisation to check if albums had the right tracks or artwork. Most of the time, coroutines should only be used for minor things (as they allocate, which, from the first lesson, isn't the best idea - I wonder if making a coroutine singleton is even possible?), How Could This Apply To Drunk Space!? A delegate wouldn't really make much sense in the game because there's nothing that really needs shortcutting. A coroutine could be used to check if the current player has died, and if so, stop controls from working, fade the player out, remove a life, reassign controles, and then fade the player back in. This is what has been used in the example given by Richard, so I might steal a bit of it and get it working in my game.