Summing Up

Hello, readers, for what will likely be the final time.

Well, the dissertation is over; I set it up, carried it out, and now here we are, waiting for the grades to be distributed.

Not really sure what to say, now that I'm here. Thanks for the support? It's been fun, I guess?



Truth is, it's been a project. I set deadlines and worked on them, sometimes I hit them, sometimes I missed them entirely. I think I'm satisfied with the result of the dissertation, as I've learnt a thing or two over its course that I doubt I would have otherwise.

The goal was to get me learning C# to an applicable degree, and I think I've succeeded with that. Even if I can't quite nail every single line of code off by heart, or if I don't know every technique in the book, I know where to look to find them now, and I have a much larger backlog of my own code to look at for help.

And on top of that, I've learnt more about using Unity; working on six projects (five more than I would have originally this year) in the engine will do that, I suppose. So I've got that going for me, as well.

And finally (at least in this little list I'm doing), I've continued to learn more about myself and my ability to self-manage. Throughout the project, I failed to hold myself to deadlines when I became complacent and allowed the work to pile up until the last minute. Whether this is an issue with my time management or simply a lack of motivation to hit the deadline, I'm not sure. But those are areas that I can work to improve on.



So, then, for things learnt over the course of the dissertation, we've got:

• improving my knowledge of C#.
• improving my ability to use the Unity software.
• improving my understanding of my own ability to self-manage.

I'd call those useful skills, with the career I have in mind. I probably could have made better use of this dissertation and my time this year in general to improve my coding skills, but then I could have done a great deal worse. I'd call this a fairly good result in that range of possibility.

Maybe about a 12 or 13 on a d20 roll.

So, then, where do we go from here?

This blog is pretty much done. I doubt I'll have any further use of it once I've received my grade. However, depending on how things turn out for me, I may begin another development blog using this same profile, so if you're desperately interested in reading more of my exploits in game development, then keep an eye on it.

As for me, hopefully my work this year will give me at least a passing grade, and I'll graduate from UCS this summer. Once I'm sure I've got the marks to leave with my degree, it'll be onto job hunting for me. With any luck, I'll be able to find a decent position suited for my abilities and preferences with game development, and start making games, as well as a modest living. With a little more luck, I'll be able to do it quickly once my grades are secure.

I'm apprehensive to push my luck with any speculation beyond that.

It's been an interesting year, full of learning and the like. Hopefully, I'll be alright going forward, with everything I've been taught. Only time will tell.

Have a very good day, and a wonderful year, readers. Wish me luck!

Second Semester Final Project COMPLETE

A fine day to you, readers.

Well, I certainly had some interesting coding problems in the final run-up to completion; I managed to completely lose track of the way the code worked for the sideways perspective of the game-view (necessary to ensure proper generation of the levels via the code), and ended up having to make a bunch of edits and compromises to the way it works on the fundamental generation code.

But, it's good that I encountered these problems when I did, rather than any later; the issues have been resolved, even if I'm not overly fond of the resolved result. It's really just niggling annoyances, things like having to switch the "width" and "height" variables around in some places, but not in others, makes the code less user-friendly and intuitive. But I made a number of comments explaining it where it's needed, and it's not a serious problem either way.

With those bugs out of the way, I am happier to say that, after the tutorial levels (the first four grids, which introduce the base mechanics of the game), there are two further levels. They're not as refined as a professional level should be, but they're enough to demand some thought from the player before making a move.

Personally, I'm happy for these two levels to roughly represent some later stages of gameplay, the first one showing perhaps an early to intermediate level, and the second a more advanced stage, either intermediate or late level, requiring more careful thought and possibly some experimentation by the player.

Along with the other levels, this should draw a rough picture of how the game will stand if development of levels were to continue without any additional mechanics or features. Of course, that isn't to say that more mechanics couldn't be introduced, and many puzzle games make great use of adding more elements to the gameplay, making the game more and more advanced as the player continues to play.

If I had to guess, the most likely route of new mechanics would take one of two forms: new Bubble types that interact with the rest of the grid in different ways (perhaps popping different patterns of surrounding Bubbles, or which only affect other Bubbles if popped directly). The other possibility would be some restricted player ability to add Bubbles to the board themselves, letting them bridge or fill in gaps on the board, which would function nicely with the "Line" Bubbles, which require that constant bridge to continue going.

Overall, I'm satisfied with this game where it stands. I've learnt a bit about managing grids in code (such as via Multidimensional Arrays), and maintaining absolute understanding of the way the code may compensate for in-scene variances, especially with variances of perspective.

And that's that. The end of my dissertation. I've handed in all of the Conversion Phase and Final Project files, and all that's left to do is to wrap up this blog and call it a year. I'll post another update tomorrow with my full thoughts on the dissertation, including how it went, what I learnt, how much I'm going to miss all of this, the usual stuff.

But, until then, I'll just say thank you, readers, and have a wonderful day.

Second Semester Final Project Update 4

Hello once again, readers!

Well, this is the final update for the Final Project, both of this semester, and of the dissertation!

Progress has been somewhat slow over the past few days, with me taking a more relaxed workload in face of the end of the year, but progress has still been made in many areas of the game.

First, there's a bunch of new things to improve my game:

A restart button, allowing the user to completely reset a level at any given time, restoring the bubbles on the field and the number of clicks they have available. This really just does the same thing as starting a new level, calling most of the same functions, excluding those which progress the game by increasing the Current Level number.

More fixes to the game code, allowing the size of the grid to be set larger and larger (on a level to level basis), without any elements (such as bubbles or parts of the board) being cut off by the camera. This is really just a few extra lines of code which change the position of the camera based on the size of the grid that gets loaded; simple fix, but it works for all grid sizes tested so far.

Tutorial-style text, which is displayed during the early levels of the game to help the player understand exactly what's going on and how to play the game, without simply trying out a bunch of random inputs. Trial-and-error (in my opinion, at least) isn't the best way of teaching a user how to make use of the most basic mechanics of this type of game. I also threw together a basic arrow in 3DS Max, imported it into Unity, and duplicated it a few times in a Prefab object to make a simple indication system, marking out particular bubbles of interest for the player.

Thus far, it's been a decent few days for the project. My main concern going forward is design for the mid-to-late game levels; I still have to put a lot more time and thought into it, but from my early attempts, it's proving much more challenging to come up with sufficiently difficult bubble layouts than I anticipated.

I'll give it a good go, but that may be the weakest part of my project upon its conclusion, which is unfortunate considering that this is a puzzle game I'm trying to make.

Just a reminder, the final submission date of this project is Friday the 8th of May, giving me a limited time to finish it up. I'll post a final update on Friday, summarising my final progress, as well as a closing post, wrapping up the dissertation and giving my thoughts on the project as a whole and the progress I feel I've made during it.



Until then, I wish you a very good day, readers.

Second Semester Final Project Update 3

A fine day to you readers!

It's been a busy couple of weeks. My group project final presentation was completed yesterday, with a long run-up of prioritising bug fixing the game over sleep, along with everything else. That regrettably includes the dissertation project, meaning that progress since the last update has been minimal.

With today being scheduled as the final day of the project, I am forced to conclude that the final project simply isn't in any kind of state to be called done; in its current state, it barely constitutes a proof of concept, let alone a prototype. On top of this, there is still plenty more for me to learn from the game, regarding both code and the Unity engine.

For these reasons, I have made the decision to extend the deadline of this project to the final deadline of the dissertation, Friday the 8th of May, giving myself another week to continue learning and refining the game.

Honestly, I personally doubt that the project will surmount to anything incredible even with the extended deadline, but perhaps I will have enough time to make something that demonstrates at least some basic competence with Unity and C#.

A final post concluding this project should follow on Friday at the latest, with perhaps a mid-week update of progress, to keep readers of this blog informed.



Until then, have a fine day readers!

Second Semester Final Project Update 2

Dear, oh, dear, readers, I really do need to do better with these updates, don't I...

Good evening, readers, I have another update for you with the Final Project puzzle game I've been working on.

Again, I sadly have not been able to put as much time into this as I would like, but progress is being made nonetheless. Since the last update, I've more or less redone the bubble popping system, moving the co-routine to the individual Bubbles to cut a bit of length from the Main script. While doing this, I made the necessary modifications to ensure that each bubble that pops will run its effect, even after being popped by the effect of another bubble.

This makes it possible to chain-reaction bubbles effectively, allowing for more domino-effect popping than the previous method did.

I also modified the popping effects of the bubbles, adding in two new types: the Basic Bubble, which simply pops on its own when clicked without affecting any other bubbles, and the Explosive Bubble, which pops all bubbles immediately surrounding it.

The Line-Popping Bubble remains, but will no longer be the standard bubble on most levels. 

The final new feature is the finalised level system, which utilises a Level subclass to build hand-made levels through the code. Each level incorporates a unique Two-Dimension Array which can be modified in the individual level class.

This means that there is a parent "Level" class, which is subclassed in "Level 1", "Level 2", and so on. This allows the Main script to treat all of the levels as the same script be referring to them as their parent class, while still letting each level have its own variable values, including the overall layout of the level.

I've so far create three levels, each one introducing the current types of bubble. The next thing for me is to begin creating some levels which use these bubble types and provides some challenge to the player. Some more mechanics may be necessary, but I'll consider that possibility after exploring the current mechanics.

For now, that's about all the progress that I'm ready to report on for now. I'll try to update more often and more regularly in the future. Until then, have a fine day, readers.

Second Semester Final Project Update 1

Hello, readers!

Apologies for the lack of updates in the past couple of weeks; various projects have been keeping me busy, and I haven't had much time to work on the Final Project, and didn't see any point in providing updates with no progress to report. I have finally managed to pour a couple of hours into it today, however, and have settled on and set up a fairly nice central mechanic for the puzzle game I'll be building.

The player starts with a square grid of bubbles, which can be popped by clicking on them. Popping the bubble produces a nice little particle effect, and makes the sphere of the bubble vanish.

Once a bubble has been popped, the game pops the rest of the bubbles in lines above, below, left, and right of the clicked bubble in a short chain-reaction. The code for this was relatively simple, but took a little bit of thought to get them to pop in order, all at once. It was a fairly simple matter of having the four directions of popping in a single function with four Booleans detecting whether the edge or a blank space had been reached; the function was headed by a While Loop that checked if all of the Booleans had been completed, and included a yield WaitForSeconds delay at the bottom of the While Loop.

The bubbles are contained in a Two-Dimension Array to which they're added as they're created, similarly to the Maze Game I created in the first semester. This makes it incredibly easy to target specific bubbles within that Array, using the coordinates that are assigned to them.

Overall, I'm happy with this as a start to the game. It's a fairly nice puzzle mechanic which, with some basic level design, can make for some tricky levels. It also offers some room to develop one-off mechanics with the popping chain (such as a "bomb" bubble, which bursts all bubbles around it when it pops, or a way of bouncing the chain reaction around the board), and is generally just quite satisfying to watch. It wouldn't be incredibly hard to allow the player to set up some fairly intricate, almost domino-like patterns in the bubbles, which they could set off with a single click, sit back, and watch play out.

With another couple of weeks, I can hopefully develop this into something very pleasing to add to both this dissertation, and my portfolio.

I'll try to keep updates coming more regularly. Until the next one, have a fantastic day, readers.

Second Semester Final Project START

Greetings readers!

The time has come again to plan and prepare the Final Project of the semester. This should be the final piece of work I produce for the Dissertation (unless I decide to create any additional prototypes in my final weeks of the academic year and document them on this blog).

For this final piece, I've decided to return to using Unity and MonoDevelop. It's by far the best games creation program I've used, uses C# natively, and is becoming a powerful standard in the industry. Being able to use Unity more proficiently increases my employability and showcases my ability to use C# far more effectively than any other program I can presently use or have access to.

As for the game itself, I don't really feel like I've made any serious progress with C# over the past semester, certainly when compared to the first semester; as such, I will be using this to simply demonstrate my existing knowledge and abilities, and hopefully gain a little more experience and something new to show off in my portfolio. As such, I'd like to produce something polished and interesting, something with simple mechanics and some level of audience engagement. The Top-Down Shooter game I created for my First Semester Final Project was a passable demonstration of mechanics, but it didn't give the player much of a reason to play the game, and wasn't nearly as polished as I would have liked.

Puzzle games are usually quite good for engaging the player audience, and often only require a bare minimum of mechanics to produce, so I'll start there. I would also like this game to be three dimensional (in visuals if not gameplay), as my portfolio is noticeably lacking in anything but 2D Flash games.

This should be enough of a description for me to start working on the game. With any luck, I should have an update for Sunday, depending on how busy I end up being during the week.

Wish me luck, and have a very good day in the meantime, readers.

Fifth Tutorial Phase Update

Good evening, readers.

This Tutorial Phase has been something of a flunk, I'm afraid to say. In usual fashion, I left the work until the end of the week in order to focus on the more immediate project deadlines, but when I got around to finally starting the tutorial, I discovered that, as the tutorial explains, XNA was discontinued by Microsoft for Visual Studio. However, the tutorial failed to mention that it was utilising an older version of Visual Studio (2010, I believe, which I do not have access to), and Microsoft's Developer Network doesn't offer versions of XNA for the modern versions of Visual Studio.

So, in short, the tutorial was sadly impossible to follow for me, and useless even if I had found an alternative solution. Sometimes the progressive nature of computers is a problem.

So, then, what is to be done with the Fifth Conversion Phase? I think that spending some time learning the Visual Studio program would help, and there are several particular points I'd like to address in that regard.

As yet, I haven't learnt how to import assets (such as images) into Visual Studio, something I'd hoped to learn from the tutorial. While I can't follow the tutorial through, I can try the same techniques the creator used, and find alternative methods if they don't work due to incompatibility.

In addition, I'd like to experiment a little with the possibility of scrolling images and environments within the program, perhaps finding a way to accomplish this in a partial segment of the window.

So, then, I'll spend some time focusing on these points. If I have time, I'll produce a prototype game demonstrating these elements; if not, I'll at least have learnt and practised them, ready for use in future prototypes.

I'll post another update documenting my progress on Sunday the 8th. Until then, have a fine day, readers.

Fourth Conversion Phase COMPLETE!

A fine evening to you, readers!

The Fourth Conversion Phase is now complete, and the resulting prototype is more or less done for the time being.

It's a great deal simpler than I originally hoped, in terms of code, visuals, and gameplay, and is a significant downgrade from the previous prototypes made in Unity. This can partly be explained with the fact that I'm still new to the Visual Studio interface, and it took a great deal longer to accomplish certain simple tasks than if I had more experience. Hopefully, this means that future prototypes will be more advanced, and will take less time, allowing me to develop and polish them even further.

In its current state, the prototype plays Rock-Paper-Scissors with the player in a very basic capacity; the player gives their input first, and the "opponent" responds immediately, using a random number generator to decide what its move is. The random numbers are weighted to reduce the occurrence of draws between the player and opponent, encouraging positive or negative outcomes.

In this manner, it's more or less entirely random whether the player wins or loses, and their moves are technically pointless, in terms of which move they make. So long as they make a move, the chances of winning or losing are equal to any other move they could make; for example, a player who chooses their moves with careful deliberation and bluffing would have the same chances of victory as a player who chose Scissors every turn.

With more time, I might design same kind of system to allow the computer to recognise this kind of behaviour, increasing the chances of it countering repeating moves. This would likely work by adding value to an integer variable, and then using that variable in the random number generator when the opponent chooses its move. However, this is a back-end feature which doesn't greatly affect the user's experience at this stage.

A timer, displayed at the top of the game screen, counts how long the player has to make their move; failing to choose a move before the timer completes will grant the enemy a free win, and a subsequent point to their score pool.

On top of this Rock-Paper-Scissors mechanic is a second, also very simple gameplay element; there is a button on the right side of the game window, separated from the Rock-Paper-Scissors game. Clicking this button fills up a bar (which is also constantly depleting at a gradual rate); filling the bar increases the value of the player's wins, granting them an advantage over the opponent by letting them gain the required number of points with fewer wins in the Rock-Paper-Scissors game.

Once the bar is filled and the player's win value increases, it also becomes harder to fill, increasing the required input by 50% with each fill. So, if the first fill takes six clicks, the next should take nine, if the player is clicking at the same rate. Once the player's win value reaches five, it become exceedingly difficult to fill the bar any further, and likely impractical as the game timer progresses, giving the opponent more points. However, by this point, adding more value to the player's wins is largely unnecessary; five points per win is enough to beat the game with two successful moves, while the opponent will always need ten, meaning that the odds are heavily in the player's favour by such a point.

It's up to the player to strike a balance between making moves and improving their win value. Currently, it's largely more practical to focus more time onto increasing their win value, as different moves have little effect on the outcome.



Finally, I'd like to quickly mention some problems I currently have with the prototype, as this is far from the best thing I've made, and hopefully I can put together something better for the next Conversion Phase; as I've mentioned, the way the opponent chooses moves is pretty poor, allowing the player to simply choose any move of their own and still have the same chances for each possible outcome. I would like to have had the time to put together a slightly smarter AI which tried to anticipate the player's moves, and which can be bluffed against.

Also, the game itself, as it stands, is far from entertaining; it's an almost painful clickfest of trying to pick out moves and increase win value for a few seconds, before simply picking any random moves and hoping to win sooner rather than later. The game fundamentally needs some more design work to improve on this issue.

And lastly, the game doesn't even look nice, using basic Webdings symbols, labels, and the simplest of UI elements. Compared to the prototypes made in Unity, or even the Tutorial games from the Fourth Tutorial Phase, this prototype is just ugly, which doesn't really help with the poor gameplay.



That's about it for now, readers. The Fifth Tutorial Phase will begin as of tomorrow, with a YouTube tutorial creating a mixture of XNA and MonoGame framework games, and will conclude on the 1st of March.

Until then, have a fine evening, readers.

Fourth Conversion Phase Update

Greetings, readers!

So, it seems I forgot to update the blog regarding the start of the Fourth Conversion Phase at the beginning of this week. I seem to be apologising a lot in regards to late updates, which is certainly worrying; I'm going to have to look into a way of enforcing deadlines on the blog posts for myself at some point.

For now, however, I'll just say that the Fourth Conversion Phase HAS begun, and the game I will hopefully have ready for Sunday of next week (the 22nd of February) is going to be a little simpler than some of my previous conversion projects, but I'd like to focus a little more on applying some polish and user-friendliness to it. Menus, for example, and maybe some simple sound effects.

The basic idea is a Rock-Paper-Scissors style game in which the player fights an AI opponent, likely using a very basic RNG (or Random Number Generator) system to choose moves. Wins against the opponent will be building towards a pool of points; whoever gets their pool to the target goal, wins. So, for example, the goal could be ten points, and each player could receive three points per win against their opponent's move, meaning they would need four total wins to beat the game.

The point of this is to continue to make myself more familiar with Microsoft Visual Studio, in particular regard to connecting the code with the base program. The tutorials taught me how to reference objects in the central class file, but I still need to learn how to connect objects to their own pieces of code.

For the game itself, I need to think of a way to determine how much each win is worth, and tie that into the gameplay. A possibility could be to have a second game (still very simple, Noughts and Crosses maybe) which the player also works on to determine their win value in the central game. I'll put some thought to it perhaps next week, and focus on the core Rock-Paper-Scissors mechanics this week.

I'll have an update tomorrow to show what progress I've made in the first week, and how I plan to go about next week. Until then, have a fine day, readers.

Fourth Prototype Phase COMPLETE!

Greetings, readers!

I think I should perhaps write "Complete" in all-caps for all of my Completion update titles from now on; make it easier to find them among the list of dull, dull post titles.

But yes, I have just finished the final touches of the Fourth Prototype Phase. As you may recall, the tutorials in question were three very basic demonstrations of Microsoft Visual Studio 2013 from their Developer Network site, which can be found here:

https://msdn.microsoft.com/en-us/library/dd492135.aspx
https://msdn.microsoft.com/en-us/library/dd492162.aspx
https://msdn.microsoft.com/en-us/library/dd553235.aspx

The main purpose of these tutorials was less to see C# in use, but more to get at least a basic understanding of Visual Studio and how to use it in a simple capacity. This includes things like creating tables and labels in the Form, and manipulating them in terms of size, context (such as text fields and colours).

On top of just working with these in a basic capacity through the program itself, I needed to learn how to access and work with the visual elements of the program through the built-in code functionality. Visual Studio has an interesting method of accessing elements through code; instead of linking the objects up to class files as I might with Flash or Unity, they're all considered children of the central class file, and so far I have only seen them being manipulated through that central file.

Visual Studio also has a tool for adding functions to the code rather elegantly; each object you place on the form (such as a field, button, or label) has certain Events which can be added to the code simply by double-clicking on them, or tied to an existing function in the class file. For example, you could build in a button, go to its Events list, and tie in an existing method in the code to call when the player clicks the button; or mouses over it, or any other number of pre-set possible Events tied into each object in the Toolbox.

This isn't that different from the way Flash and other programs use Event Listeners; the main differences are that each type of object is restricted in what Events can be tied into it, though the Events that can be used with it can be very easily scrolled through to find the right one that the creator is looking for. I imagine that Events that can't be found in the list of the object could be generated in the code if need be.

Overall, this it a fairly easy program to use, though I could see the pre-set objects in the Toolbox very quickly becoming stale, particularly in their appearance, which contains very few cosmetic options beyond colour.



Going forward, I still need to put some more thought into the game that I could create from the techniques demonstrated in the tutorials, as well as my existing knowledge. I'll create a blog post announcing the beginning of the Fourth Conversion Phase, and should describe what I plan to create there. Expect that tomorrow, or by Wednesday at the very latest.

Until then, readers, have a wonderful day.

Second Semester Update: The Coming Projects

Hello, readers, once again!

We're now in the second semester of the academic year, and I have had enough time to put some thought into my dissertation project, and where to take it from here.

As you may or may not know, the original plan was to follow a similar setup to the previous semester of using online tutorials to learn new coding techniques with C# and build small game prototypes with that knowledge every two weeks. However, this will be changing slightly, as I will detail here:

Firstly, the previous two-week development cycle for the projects will be changed for a three-week cycle, allowing another week of work on the Conversion Phase so that I can hopefully put together something more polished and ready for submission. Please expect an update to this blog after the completion of each Tutorial Phase, an update one week into each Conversion Phase, and a final update at the end of each Conversion Phase.

Second, I will no longer be using Unity, as it wasn't offering me experience with C# as much as UnityScript; while useful, that wasn't the purpose of this dissertation, and has therefore been changed. From here, I intend to use Microsoft's Visual Studio Express 2013.

Third and finally, I have reduced the number of tutorials from three to two, allowing myself enough time to complete both with the new three-week development cycle, and still having plenty of time to work on the final project for the semester.

At this stage, I believe I have enough understanding of coding to be fairly competent with C#, provided that I learn the basic syntax and Visual Studio software, so the focus of the tutorials will be on those two goals.



So, then, with no further preamble, here are the two tutorials I will be completing and reworking over the next six weeks:

1: I will be following the following three tutorials available on the Microsoft Developer Network that cover the basics of Visual Studio 2013.

https://msdn.microsoft.com/en-us/library/dd492135.aspx
https://msdn.microsoft.com/en-us/library/dd492162.aspx
https://msdn.microsoft.com/en-us/library/dd553235.aspx

These should give me enough knowledge and confidence to use Visual Studio itself, whilst allowing me some freedom to use C# in a basic capacity. Once the tutorials are complete, I will estimate what my capabilities are to experiment with the software and coding techniques, and spend two weeks trying to fulfil that estimation, possibly pushing the prototype a little further if I feel I'm able.

The Tutorial Phase should be completed on Sunday the 8th of February, and the Conversion Phase should be completed on Sunday the 22nd of February.

2: I will follow a YouTube tutorial creating some small games using XNA and MonoGame frameworks in Visual Studio.

https://www.youtube.com/playlist?list=PL8YsBsQXUFy-tilPKhtxtrdanVmIQvzzX

Parts 4 and 5 currently appear to be missing from the playlist, but can be found on the uploader's channel. I will link these if necessary in my summary post after the Tutorial Phase is complete. Again, I will estimate my capabilities after completing the tutorials and work towards what I think is a realistic goal before beginning my Final Project.

The Tutorial Phase should be completed on Sunday the 1st March, and the Conversion Phase should be completed on Sunday the 15th of March.

Following this, the Final Project for the Semester will begin on Monday the 16th of March, and should be concluded for Friday the 1st of May, following Easter.



I believe that's all I have for you for now, readers. The only thing left to do is to declare that the Fourth Tutorial Phase has officially begun.

Please do have a fine evening, readers, and wish me luck in the coming months.

Final Project Update - First Draft Complete!

Good afternoon, readers!

I'd like to take this opportunity to again apologise for the delays of the Final Project, but I'm happy to say that it is now about ready to be called done, at least for prototype purposes.



Allow me to offer a quick breakdown of how the game currently functions:

As you should be aware, the Final Project of this first semester was a top-down shooter incorporating elements of the previous projects including shooting, precise movement, random generation, and enemies with a simple pathfinding AI.

When the game starts, the first thing that must be done is the generation of the level, currently a maze similar to the one developed during the Second Tutorial Project.

An instance of the maze level, almost fully generated.

Once the level has been fully created, the game chooses a number of random coordinates in the maze, first spawning the Player, and then the Goal location which the player must reach. Code is in place which attempts to prevent the Goal from appearing too close to the Player's spawn point, though it isn't currently foolproof. Due to the nature of the maze, however, even when spawning within the limit set around the player's spawn point (currently a radius 1/3 of the full size of the level), walls often block it from being immediately accessible.

Once the Player and the Goal have both been spawned, the game will generate Enemy instances to populate the maze with hazards for the player. Once they're spawned, the Enemies choose a random set of coordinates and move towards them; once these coordinates are reached, they choose another set and do the same, simulating a "roaming" behaviour.

The Enemies also have a rotating Raycast attached to them which, if it comes into contact with the Player, will cause the Enemy to give chase at a higher speed, attempting to get close enough to attack the Player.

From left to right: an Enemy, the Player, and the Goal

The Player, meanwhile, can move around the maze, attempting to either evade enemies or destroy them using a simple gun mechanic which knocks them back before destroying them with the second shot. This knockback allows the Player to push back Enemies, potentially creating a window to escape through if they get cornered. If the Enemies hit the Player enough times, however, the Player dies and the game restarts, generating a new level. The Player's current health is represented by the five white boxes around them. A box will disappear every time the Player gets hit, and once they are all gone, the Player is out of health.

That's a basic rundown of the essential mechanics currently present in the game. At this time, there are a few things I would like to add if I have the time, including a victory screen displaying the Player stats from that game (such as Enemies killed, damage taken, etc.), and alternative Goals than simple locations to reach, such as killing a set number of Enemies.

There are also a few bugs which I haven't succeeded in completely removing, including one involving the Enemy pathfinding code which sometimes returns one or more Alerts when the Enemy attempts to calculate a new path before the previous one is finished, resulting in a serious performance impact. Most of the other bugs are simpler, such as the random coordinates trying to access out-of-bounds values, or some combination of the Player's Bullet's speed and hitbox size which lets it go through walls from time to time.

While I've attempted to address all of these issues, I simply either can't find an effective solution, or didn't have time to completely erase the cause. I have attempted to reduce the frequency and/or severity of each of these, to greater or lesser degrees of success.

Well, I believe that's that, readers. I will try to complete some more improvements on this project if I get the time, but I need to put some serious effort towards preparing the projects for the coming semester, as well as setting up a website where all of these games can be accessed and played. We will have to see how well that goes before I can consider returning to continue work with this project.

This weekend I'll be participating in the Global Games Jam, but after that I will be turning all of my attention to my uni projects, including this dissertation.

Until then, I hope you have a wonderful day, readers.

Final Project Delays

Good evening, readers.

I'm sorry to say that the situation regarding the Final Project is as I feared; the prototype simply won't be ready in time for tomorrow. I've made some decent progress with it so far, the player movement's about where I want it to be, the shooting seems fine for the most part (just a bug enabling the player to shoot through walls to iron out), and I've got the enemies spawning in random locations.

The next steps are to have the enemies move about chasing the player, which will require some path-finding code I'll have to modify from the tower defence tutorial, and to apply some manner of objective to the game.

Other, less important things include ensuring the enemies don't spawn too close to the player, adding a health system to the game including damage from enemies and heals from certain mechanics (I'm thinking certain types of room which allow the player to heal inside them), and victory and defeat conditions and states.

Hopefully I'll have something presentable by Monday for the Dissertation Presentation, and a more complete version by the end of that week. I also need to start thinking of the next term of projects; my main thought so far is to move away from Unity, as a great deal of the coding has been using Unity Script rather than C# itself, which, while very useful, is not the purpose of this dissertation.

Several more blog posts will soon follow, readers, hopefully with more information on all of these things. Until then, have a wonderful day.

Third Project Update: Discontinuation

Some unfortunate news today, readers.

Due to time constraints and issues with the tutorial in question, I've decided to discontinue the Third Project, including both the Tutorial and Conversion Phases. This is partly due to the fact that the tutorial, while initially easier to follow than anticipated due to the game code using Unity Script rather than Java Script in most places, also contained heavy use of Unity Packages including one which required purchase (for more money than I had at the time).

Having difficulties working around this problem, as well as the Christmas delays on work, and the fast-approaching deadline of the more-important Final Project of this semester, due on the 16th of January, less than two weeks from today, I have reluctantly concluded that simply ending the Third Project for now would be best for the dissertation as a whole.

Even with the Third Project being closed, I'm uncertain if I will be able to complete the Final Project in time, while having it as advanced as I had originally hoped. I will do my best, but I may have to push the deadline back by another week or two depending on my progress. This is especially likely as I will also be trying to keep up with other projects during the same time.



I can only offer my deepest apologies for all of this. Clearly, I grossly over-estimated my working ability, particularly during the Christmas break.

I hope that my next update will be with happier news regarding my dissertation.

Until then, readers, have a fine day.