HiveMind Industries @hivemindindustries-blog - Tumblr Blog

One final update

It’s been a while since I talked about Phaser, what with the completely catastrophic failure of my original idea, In the end, I just followed a tutorial for making Flappy Bird and changed a few of the assets, added game modes, and refactored what I had when I discovered it wouldn’t work properly to work with require.js. At this point, Phaser is just a nightmare. I’m glad that with this final update on the matter and the submission being around the corner, I can forget it ever happened. So, onto the business of what the game now is. I had the idea of changing Flappy Bird, a simple and relatively easy-to-implement game, to include elements of 2048. The square or cube you’d play as would go through one of two checkpoints in lieu of the usual pipes, doubling the score if the player chose the right one (or causing a game over if not). This, however, seemed too complicated for me to include having just overscoped and completely failed at my previous game. Instead, I have included three game modes for the original Flappy Bird, where pipes and gravity increase as the difficulty goes up. As this was a design-based module, I also edited some of the assets so that the game isn’t just the same thing over and over again. When the score for a gamemode is recorded, the game gives the player a chance to go to one of the other modes if desired. Here’s a few pictures of the Phaser game in its final format. Although it was just tutorial-following and a little bit of code refactoring, I’m far more happy that I got something working completed in time for the submission than something that completely failed in every single respect. I can now completely forget about this module, and move on to greener pastures. With this submission, the second year has officially ended and I can completely focus on a possible placement, one exam in the summer, and my final year project. This blog post also marks the end of HiveMind Industries. I have decided that if I am to be serious about what I want to create, and I want to make something that is truly excellent, this blog with all my previous, pitiful failings is not something I want kicking around. Good bye, coursemates and followers. It’s been fun, and I’ll still be around, but it is, as they say, it. Best wishes to all. -The HiveMind Boffin

#aint207

Nope.

I spent eight hours trying to figure stuff out for Phaser last night. EIGHT. HOURS. I’ve just finished completely scrapping the project, which I’ve wasted so much time on, in liew of something - anything - else. There was no miracle cure for changing layers, and there was no possible way for the game to work as intended without it. A simple, boring puzzle room platformer with no novel mechanics would have been a complete pain to make in Phaser, a basic knock-off of my previous Stencyl iteration, and, essentially, a full waste of time. I think it may just be me being bad at JavaScript, but Phaser doesn’t seem to like giving many errors or working with something in an intuitive way. At least with C#, Unity and VIsual Studio I know exactly what has gone wrong and where. But I’ve trawled stackoverflow for hours, searching for something that might even slightly allow a player to remain instantiated with an inventory across two layers, allowing the player to actually see the avatar they’re controlling, and getting it to interact with anything on that second layer at all. The player still hits walls on layer one, isn’t visible, doesn’t instantiate properly, has no animations or sprtes working on the second layer, and simply Will. Not. Work. I have no idea what I’m supposed to do now, bearing in mind I have about seven weeks left to figure something out that works as well as intended, but I think I might just go back to the drawing board and make something that does. I’ve left everything from this project still in the repository I will be submitting, so in case it was something completely simple and obvious that I’ve spent eight solid hours trying to fix, at least whoever marks the work can see it for what it is. Hopefully this documentation will still get a few marks, but I’ve now accepted that I don’t think I’m going to be able to pass this module.

#aint207

Player movement

Player movement now works along the four main axes (this code’s similar for all four, so I’ve just included left in the image), but there is still the issue of layer-switching that I cannot seem to solve for the life of me. I tried destroying the player and instantiating it on the second layer, but then the player image won’t show up at all, or it won’t appear on-screen. Let this be a lesson in massively, massively overscoping a project. And with the deadline coming closer, there is no way without a miracle that I can get this game even slightly working. I haven’t even finished testing the first level yet! Hopefully I can get a solution before March rolls around, but if not then I think it’s back to the drawing board.

#aint207

First code

Since brackets decided not to work properly for this update, the source code looks a bit rubbish. Anyway, this is supposed to demo the primary form of world-based interaction in the game: layer-switching. It somewhat works properly, but because both layers are relatively similar there’s no real gameplay yet. In addition, setting collisions for absolutely everything in the level and all the tilesets takes a huge amount of time. I may have to try and figure out a better way of getting everything loaded in properly. If I’m lucky I’ll be able to successfully load the player in, too, although it seems as though even if the player is loaded in, they can’t actively move between layers! This is a major, major issue, and if I can’t figure out something that might help matters then I might have to rethink my idea entirely. I’m worried that if I can’t get this solved then I won’t have enough time to get something else reasonably polished before the deadline comes around, especially since the assignment specification is fully expecting a complete game.

#aint207

First level ideas

So here’s a look at the first few levels. The player should be given the option, later in the game, to revisit some of the earlier tutorial-style levels, so that hidden clues, easter-eggs and items can be picked up. Since the game is supposed to be about moral choice, this should give a nice touch to the game for those who are genuinely interested in the lore, and aren’t just playing for the sake of completion. Eventually, as shown in the level design post, there should be a number of different endings depending on the moral choices of the player. But for now, the first few levels are relatively simple. I can think up the rest as I go along; cluttering up this blog with every single level idea would take forever and be very boring. Apologies for the rushed handwriting - I was in a flow.

#aint207

Crunch Time!

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.

#aint209

Menu concept

Having brainstormed the menu system, I thought I’d also include my initial ideas for the main menu. The general concept is basically the same as for the Stencyl game, but I’ll explain what’s going on here anyway. The player is presented with a main menu, where thy can play, load, exit or see credits (as well as check out this blog).

On clicking play, the player is sent to the level screen, where they can see the eventual layout of the facility. More levels are unlocked as the player continues through. Before starting I’d also want to include a page to explain mechanics, lore and so on. If the player loads, then they can pick from any level or room they’ve previously been to. Next time I’ll be taking a look at the design for the first few levels. Before I forget, I’ve also included require.js as part of the Phaser framework I’ll be using. It should mean that the instantiating of the entire game is much easier, and will make some of the code look a tiny bit neater. Apparently it saves time coding too, which is quite cool.

#aint207

The C# Necronomicon: XIII

[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.

#aint209

Starting Off

So, with this new project, I’m planning on using the assets I spent months working on last year to my advantage, changing things around and adding in new mechanics and assets as needed. This way, I have a number of things that can already be tested with, and I don’t have to worry about cloning something else for test purposes. It also means I get a decent feel for what the game might be like by the end of play. Another idea would be a morality-based choice system. In the last game, the issue of choice for the first six levels was never implemented due to time constraints - originally I wanted the player to be able to go through a number of different rooms depending on which choices they made over the trustworthiness of the narrator, the best direction to go from a ultilitarian perspective, and the discovery of various clues and items. To that end, I’ve included here a rough concept of how I would like some of the levels to be organised. I know that by the end of this module, the entire game will probably end up being much less than this, but as a general endgame I’m including it anyway.

#aint207

The C# Necronomicon: XII

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).

#aint209

The C# Necronomicon - X-XI

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.

#aint209

Infiltration: Project Delta

As part of the second year of the course, I have been instructed to build a game using Phaser, a JavaScript-based game engine that runs in HTML5. Blog posts for this game shall be posted under the AINT207 tag, which is the module code. As a result, I have decided to recreate my old Stencyl game from the first year: Infilitration. With a new name, design and approach, the game that I could never finish shall be released under a much nicer framework, and, hopefully, won't be abandoned after the first six levels. More to follow.

#aint207

The C# Necronomicon: IX

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.

#aint209

The C# Necronomicon: VII-VIII

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.

#aint209

The C# Necronomicon: V-VI

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).

#aint209

The C# Necronomicon: III-IV

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.

#aint209

The C# Necronomicon: II

(Side note: I'll be catching up with the lessons already given until the time of the next one, at which point I'll post about them on the day. Information about how the Dark Magic has been used to improve the game shall come shortly afterwards, so that if something cool is mentioned but something in a later lecture can be used instead, I won't have to do twice the amount of work for the same payoff. Ph'nglui mglw'nafh C# Unity wgah'nagl fhtagn) Part The Second The second Dark Magic spell goes by the name of the Singleton, which is a single instance of a class. One cannot have more than one singleton upon pain of death, for that was how they are created and how they remain until the end of time itself. A singleton does not need allocating, meaning that there are no null pointer references for it, ever - especially useful for bumbling apprentice C# sorcerers such as myself - and has constant global access, meaning you don't need to pass around pointers to it anyway. The vice of this spell is that is a lazy solution - yes, it is global, but that means everything might access it at any time. Yes, it stops null pointers, but only by cheating - passing pointers to classes that are needed is far more noble solution to your null woes. But then, doing it properly is not Dark Magic, and what would be the point of that? Unity, being a goody-two-shoes system, will be very angry at you for trying to use a singleton. It knows Dark Magic when it sees it. It is afraid, and is right to be. It has no power here. You, as developer, are. To use a singleton, we just enforce it to be one: once attached to a game object, any access will only create one instance. If used for a score, then when it is first accessed, it instantiated - if then accessed again, it will return that instance.To allow that class to then be used once alone, simply make sure this happens within the Awake() function. How Could This Apply To Drunk Space!? Perhaps for the life counter. It would probably make more sense to change the classes to singletons so that they can be accessed if I add power-ups or life regens or something similar. I probably won't need to use them, since the lives make sense as they are - but we shall see.

#aint209

Trending Blogs

Recently Viewed Blogs

HiveMind Industries