Hello, readers! I hope you all had a Merry Christmas!
Well, once again I have put myself in a position for which I must apologise; In the weeks leading to Christmas, I allowed my workload to slip out of control once more, and now that Christmas is effectively over, I have more than enough to keep me busy for the rest of my break from lectures.
My third tutorial phase is still not yet complete, let alone the conversion phase of that project. Again, I can only offer my apologies for this unprofessional behaviour I adopted, fix this mess, and aim to do better in future. My goal is to complete the third project this week, preferably before New Year's Eve (this Wednesday).
Currently I'm facing some issues with the third tutorial phase due to the creator of the tutorial using Unity packages which would cost more money than I currently have. I'll make do with what I have and try to recreate what I can of this package with my own skills, but my final product simply won't have everything the tutorial does.
As unfortunate as that is, I can only continue and learn what I can. The goal is not to have a feature-complete recreation of the demonstrated game, but to learn concepts and techniques to take forward to future projects.
Wish me luck readers. I'll have more updates for you once I've completed the tutorial, hopefully in the next day or two.
Friday, 26 December 2014
Tuesday, 9 December 2014
Rough Completion of Second Conversion Project
Good morning, readers!
Following last night's update, I can now confirm that I have, for the most part, completed the Conversion Phase of the Second Project. While it is hardly at the stage I would like it to be, missing several pieces of polish such as a score counter, move counter, and a delay between turns among other things, it does succeed in its basic mechanics of the original concept I had for the game.
The player starts out in the bottom-left corner of the randomly-generated, three-layer map, directly across from the (currently AI-driven) opponent in the top-right corner. The player makes the first move, taking one step North, South, East, or West by pressing 'W', 'S', 'D', and 'A' respectively; they cannot step outside the boundaries of the map, and cannot move from layer 1 to layer 3, or vice-versa. The opponent will then move, always trying to move closer to the player, though the algorithm for this is extremely basic, and hardly fit for anything more than a prototype.
While the player is on the top layer, they can only see the top and middle layers, and while they are on the bottom layer, they can only see the bottom and middle layers. While on the middle layer, they can see all of the terrain. Unless the player and the opponent are on the same layer, the player cannot see them.
The player can also press 'T' to reveal all layers of the map, and the position of the enemy for a few seconds. The opponent will wait for this to end before moving, and it will consume the player's turn, denying them movement.
The winner is the first of the two players to move onto their opponent. This has to be done on their turn, and ending the game one way or another currently only pauses the game until the player presses 'Space' to restart the game with a new map.
Following last night's update, I can now confirm that I have, for the most part, completed the Conversion Phase of the Second Project. While it is hardly at the stage I would like it to be, missing several pieces of polish such as a score counter, move counter, and a delay between turns among other things, it does succeed in its basic mechanics of the original concept I had for the game.
The player starts out in the bottom-left corner of the randomly-generated, three-layer map, directly across from the (currently AI-driven) opponent in the top-right corner. The player makes the first move, taking one step North, South, East, or West by pressing 'W', 'S', 'D', and 'A' respectively; they cannot step outside the boundaries of the map, and cannot move from layer 1 to layer 3, or vice-versa. The opponent will then move, always trying to move closer to the player, though the algorithm for this is extremely basic, and hardly fit for anything more than a prototype.
While the player is on the top layer, they can only see the top and middle layers, and while they are on the bottom layer, they can only see the bottom and middle layers. While on the middle layer, they can see all of the terrain. Unless the player and the opponent are on the same layer, the player cannot see them.
The player can also press 'T' to reveal all layers of the map, and the position of the enemy for a few seconds. The opponent will wait for this to end before moving, and it will consume the player's turn, denying them movement.
The winner is the first of the two players to move onto their opponent. This has to be done on their turn, and ending the game one way or another currently only pauses the game until the player presses 'Space' to restart the game with a new map.
So, from here, the plan is to resume my normal work schedule, beginning the Third Tutorial Phase. As you may be aware, this is a YouTube-based JavaScript Tutorial for a basic Tower Defence game. I will be completing this to the best of my ability, converting it into C# where and when I can. It may eventually be the case that I am unable to convert it, and will have to simply treat it as a JavaScript tutorial and take what I can in generic coding techniques.
Until my update for that, readers, I wish you a very good day.
Monday, 8 December 2014
Update on Second Conversion Phase
First of all, readers, I have to apologise. I've failed to keep to the deadline I set for the Second Conversion Phase, which was due yesterday. I feel as though my workload in general has gotten out of control over last week, and now I need to do everything I can to pull it back in.
As it stands, the second game project is not in any kind of a presentable state, but I'm going to spend the rest of today and probably most of tonight trying to complete it to at least a prototype standard.
My apologies again for this failure on my part. The workload I'm facing these days is a lot larger than I originally anticipated when I set out with my dissertation, and only I can be blamed for not being more prepared for it. Please expect another update on the current Conversion Phase project tonight or tomorrow; I'll also try to make sure this doesn't impact the next Tutorial Phase, which was due to begin today.
Have a good evening readers; please do wish me luck tonight.
As it stands, the second game project is not in any kind of a presentable state, but I'm going to spend the rest of today and probably most of tonight trying to complete it to at least a prototype standard.
My apologies again for this failure on my part. The workload I'm facing these days is a lot larger than I originally anticipated when I set out with my dissertation, and only I can be blamed for not being more prepared for it. Please expect another update on the current Conversion Phase project tonight or tomorrow; I'll also try to make sure this doesn't impact the next Tutorial Phase, which was due to begin today.
Have a good evening readers; please do wish me luck tonight.
Monday, 1 December 2014
Second Conversion Phase!
A fine day to you, readers!
The second Tutorial Phase is now complete, allowing me to go ahead with the Conversion Phase of this tutorial project. That tutorial, in hindsight, felt damned high-level. Lots of techniques and practises I've never encountered before, but which paid off immensely world. I was often surprised to find that certain methods worked as the author intended, but they invariably did. I can only hope now that some of the techniques rubbed off on me; I can at the very least say that I am certainly feeling more confident after completing the tutorial.
So, then the second Conversion Phase! An interesting set of mechanics at my disposal this week; camera overlay, basic block-y movement, and random generation of map tiles among other things.
I have in mind what could be comparable to a board game; two players each move a single piece on a "board" comprised of two randomly generated layers of terrain. Each player can only see one layer of terrain at a time, and must spend their turn to either change which layers are visible to them, OR to move their piece.
The piece that lands on its opponent's square first is the winner.
This takes advantage of the randomly-generating terrain method the tutorial demonstrated, as well as the moving or changing of cameras and which elements of terrain are visible. I could even potentially use the walls of the maze to make movement a little trickier.
The hidden information of this game, combined with a small board, could make for a tense set of decision-making, though programming an intelligent AI opponent would be difficult, and it's entirely possible that the game might be regarded as being too close to the original maze game the tutorial led me through.
I'll continue to consider alternative possibilities to improve this game, but for now, this will do as a framework to allow me to begin coding.
Expect the first update in the next few days, dear readers. In the meantime, I have plenty to be getting on with.
Until the next post, have yourselves a wonderful time.
The second Tutorial Phase is now complete, allowing me to go ahead with the Conversion Phase of this tutorial project. That tutorial, in hindsight, felt damned high-level. Lots of techniques and practises I've never encountered before, but which paid off immensely world. I was often surprised to find that certain methods worked as the author intended, but they invariably did. I can only hope now that some of the techniques rubbed off on me; I can at the very least say that I am certainly feeling more confident after completing the tutorial.
So, then the second Conversion Phase! An interesting set of mechanics at my disposal this week; camera overlay, basic block-y movement, and random generation of map tiles among other things.
I have in mind what could be comparable to a board game; two players each move a single piece on a "board" comprised of two randomly generated layers of terrain. Each player can only see one layer of terrain at a time, and must spend their turn to either change which layers are visible to them, OR to move their piece.
The piece that lands on its opponent's square first is the winner.
This takes advantage of the randomly-generating terrain method the tutorial demonstrated, as well as the moving or changing of cameras and which elements of terrain are visible. I could even potentially use the walls of the maze to make movement a little trickier.
The hidden information of this game, combined with a small board, could make for a tense set of decision-making, though programming an intelligent AI opponent would be difficult, and it's entirely possible that the game might be regarded as being too close to the original maze game the tutorial led me through.
I'll continue to consider alternative possibilities to improve this game, but for now, this will do as a framework to allow me to begin coding.
Expect the first update in the next few days, dear readers. In the meantime, I have plenty to be getting on with.
Until the next post, have yourselves a wonderful time.
Subscribe to:
Posts (Atom)