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.
Tuesday, 25 November 2014
Post Proposal Feedback Updates
Good evening, readers!
My grade for my Dissertation Proposal came in last week, prompting me to make this update informing you of any changes I will be making in light of recent feedback.
So, first of all, as it will be the first thing on most of your minds, my grade: it wasn't very good. A pass, of course, that's why I'm still going ahead with my dissertation, but still a low mark.
If you're not interested in why, then please skip the next few paragraphs.
Personally, I feel that my poor grade was due to a misunderstanding on my part regarding the word count. So, we were given a form with quite large fields for us to fill in and a long list of marking criteria at the bottom for us to refer to, which we then returned in full with all of our information on the dissertation.
We were also told that there was a hard word count limit, and if we went over that then the proposal would be declined.
Like an utter fool, I assumed that the rest of the form, the field headings, the explanations, and the marking criteria all counted toward the word limit. So, of course, I stripped out everything from my proposal that wasn't absolutely necessary, cutting the word count down to exactly the limit, but also removing almost all of the content.
When I handed the proposal in, it was apparently more than five-hundred words beneath the actual limit, was worded strangely in places, and included far less information than the tutors were looking for.
So, that's that. In future, I really need to actually ask about these things. I've asked for a chance to resubmit the proposal, but have been declined.
Alright, done with that. Moving on.
Following the feedback from the proposal, and other, earlier feedback, I have updated the Marking Criteria post to explain more about some of the less clear points, namely the provide more of an explanation about some of the points. Namely, I have expanded the explanation of my interpretation of "good coding practises", and reworded parts of the rest of it to be more specific and objective, rather than leaving it to the reader's interpretation.
Unfortunately, I can't directly tie any of the rest of the feedback given to me to anything other than a lack of content in the proposal itself. It was commented that my Dissertation title ("My Not-So-Brief Introduction to C#: A Series of Mini Projects") implies a lack of clarity and discipline; I intended for this to be informal and seem more friendly to the reader, though I can't really argue with the marker. Informal isn't going to help me in my career later down the line if I ever show this to a potential employer, but I'm not certain if I can change the name at this late stage. Something to ask about, I think.
Well, all things considered, that was a poor start to my dissertation. Other than the changes I've already made and attempting to alter the name to something more professional and descriptive, I can only do my best to work hard at the dissertation itself, and produce enough good quality work to make up for this.
I hope you have a cheerful time until the next post, readers.
My grade for my Dissertation Proposal came in last week, prompting me to make this update informing you of any changes I will be making in light of recent feedback.
So, first of all, as it will be the first thing on most of your minds, my grade: it wasn't very good. A pass, of course, that's why I'm still going ahead with my dissertation, but still a low mark.
If you're not interested in why, then please skip the next few paragraphs.
Personally, I feel that my poor grade was due to a misunderstanding on my part regarding the word count. So, we were given a form with quite large fields for us to fill in and a long list of marking criteria at the bottom for us to refer to, which we then returned in full with all of our information on the dissertation.
We were also told that there was a hard word count limit, and if we went over that then the proposal would be declined.
Like an utter fool, I assumed that the rest of the form, the field headings, the explanations, and the marking criteria all counted toward the word limit. So, of course, I stripped out everything from my proposal that wasn't absolutely necessary, cutting the word count down to exactly the limit, but also removing almost all of the content.
When I handed the proposal in, it was apparently more than five-hundred words beneath the actual limit, was worded strangely in places, and included far less information than the tutors were looking for.
So, that's that. In future, I really need to actually ask about these things. I've asked for a chance to resubmit the proposal, but have been declined.
Alright, done with that. Moving on.
Following the feedback from the proposal, and other, earlier feedback, I have updated the Marking Criteria post to explain more about some of the less clear points, namely the provide more of an explanation about some of the points. Namely, I have expanded the explanation of my interpretation of "good coding practises", and reworded parts of the rest of it to be more specific and objective, rather than leaving it to the reader's interpretation.
Unfortunately, I can't directly tie any of the rest of the feedback given to me to anything other than a lack of content in the proposal itself. It was commented that my Dissertation title ("My Not-So-Brief Introduction to C#: A Series of Mini Projects") implies a lack of clarity and discipline; I intended for this to be informal and seem more friendly to the reader, though I can't really argue with the marker. Informal isn't going to help me in my career later down the line if I ever show this to a potential employer, but I'm not certain if I can change the name at this late stage. Something to ask about, I think.
Well, all things considered, that was a poor start to my dissertation. Other than the changes I've already made and attempting to alter the name to something more professional and descriptive, I can only do my best to work hard at the dissertation itself, and produce enough good quality work to make up for this.
I hope you have a cheerful time until the next post, readers.
Second Tutorial Phase Announcement
Apologies, readers, I know this post is a day late, but I am happy to announce that the second project is officially underway. The Tutorial Phase will be running from yesterday, the 24th of November, to this Sunday, the 30th.
I will be employing a written tutorial which details the creation of a first-person maze game with randomly generated elements, which can be found here:
I'll create another post once the Tutorial Phase is complete, and I begin the Conversion Phase on Monday the 1st of December.
Until then, wish me luck, good readers, and have yourselves a very fine evening!
Sunday, 23 November 2014
First Conversion Phase Complete!
Another fine day to you, readers.
Getting right down to the content of this post, I've more or less completed the prototype version of the first game project, which is as far as I plan to take it for the time being. It's been a lot of work, particularly this weekend, and a lot of staring at the screen wondering what's not working, but it's finally complete.
As it stands, the three layers of platforms move at different speeds as intended, the player character jumps towards the mouse cursor as intended, and the camera moves from left to right at a gradually increasing rate, just as intended. Falling off the bottom of the screen or falling behind to the left side will result in a fail state, and restart the game.
Now, sadly this prototype isn't even close to being as complete as I would like. There is a distinct lack of polish to it, giving the game a rather bare-bones feel, and it isn't without its bugs. The only notable bug at the moment is a very serious (and often game-breaking) problem with the game over function, whereby the parallaxing layers of platforms won't reset properly. This typically leaves the character falling off the bottom of the screen continually, and forces the player to restart the game.
Otherwise, I haven't yet tried exporting the game for use outside of the Unity engine (which is bound to be all kinds of fun with figuring out window sizes and such), and there is also only a single level to be played, which doesn't change from playthrough to playthrough, or randomly generate its feature, resulting in very limited playability in the game's current state.
However, the level that is available feels very much like I hoped it would, and feels like a sufficient departure from the original mechanics I started with. Moreover, as much as I've playtested the game myself to craft the levels and ensure the code doesn't break under any typical circumstance, I'm still finding the game to be surprisingly enjoyable, and something I might play on and off if it had more levels.
There's something about the degree of challenge, combined with the difficult-yet-oddly-satisfying movement controls that leaves me laughing frustratedly every time I fall off a platform.
I'm considering revisiting this prototype later, and perhaps making a real game out of it (in my own time, of course). I'll also try to get it uploaded to UCS's WaterFrontGames website so that any of you readers can play it for yourselves.
For now, I'm going to stop there; it's late, I'm surprisingly tired, and I have an early start in the morning. Next week, we'll be undertaking the second project's Tutorial Phase.
Until then, I wish you readers a very happy evening and a wonderful goodnight.
Getting right down to the content of this post, I've more or less completed the prototype version of the first game project, which is as far as I plan to take it for the time being. It's been a lot of work, particularly this weekend, and a lot of staring at the screen wondering what's not working, but it's finally complete.
As it stands, the three layers of platforms move at different speeds as intended, the player character jumps towards the mouse cursor as intended, and the camera moves from left to right at a gradually increasing rate, just as intended. Falling off the bottom of the screen or falling behind to the left side will result in a fail state, and restart the game.
Now, sadly this prototype isn't even close to being as complete as I would like. There is a distinct lack of polish to it, giving the game a rather bare-bones feel, and it isn't without its bugs. The only notable bug at the moment is a very serious (and often game-breaking) problem with the game over function, whereby the parallaxing layers of platforms won't reset properly. This typically leaves the character falling off the bottom of the screen continually, and forces the player to restart the game.
Otherwise, I haven't yet tried exporting the game for use outside of the Unity engine (which is bound to be all kinds of fun with figuring out window sizes and such), and there is also only a single level to be played, which doesn't change from playthrough to playthrough, or randomly generate its feature, resulting in very limited playability in the game's current state.
However, the level that is available feels very much like I hoped it would, and feels like a sufficient departure from the original mechanics I started with. Moreover, as much as I've playtested the game myself to craft the levels and ensure the code doesn't break under any typical circumstance, I'm still finding the game to be surprisingly enjoyable, and something I might play on and off if it had more levels.
The game screen upon conclusion. In the top-centre, you can see the full map of the first level, the goal point of which is the very small red flag near the right-hand-side.
There's something about the degree of challenge, combined with the difficult-yet-oddly-satisfying movement controls that leaves me laughing frustratedly every time I fall off a platform.
I'm considering revisiting this prototype later, and perhaps making a real game out of it (in my own time, of course). I'll also try to get it uploaded to UCS's WaterFrontGames website so that any of you readers can play it for yourselves.
For now, I'm going to stop there; it's late, I'm surprisingly tired, and I have an early start in the morning. Next week, we'll be undertaking the second project's Tutorial Phase.
Until then, I wish you readers a very happy evening and a wonderful goodnight.
Tuesday, 18 November 2014
First Conversion Phase, Update 1
Good evening, readers.
This will be a very short post to keep you appraised of my progress with the Conversion Phase of my first project. At this point, I've only put a couple of hours at most into the project, primarily fiddling with the project settings and scene.
The basic scene is set up in my Unity project, with player and a few placeholder platforms in place. I've used very simple, block-y art for the meantime, just to get the idea of layers of platforms across to the player through some simple colour. I'm using the same pre-made player Prefab that was featured in the Brackeys tutorial; it contains some pre-constructed code, but I'll have to break that down anyway, and it has some nice animations to it to make the game look a little nicer.
I've also got the player jumping on mouse click reasonably well, although there's a lot of work to get done with the movement. I still need to make sure the player jumps towards the mouse pointer, and then affect which layer of terrain they're jumping towards by the pointer's position on the game screen (higher for a more "distant" platform in relation to the camera view, lower for a "closer" platform).
After fixing player movement, I'll need to get the platforms moving towards the left side of the screen, towards the player character, and perhaps implement some degree of random delay between their spawning. That should just be manageable with a single Script without too much difficulty.
Overall, a slow start to the project, but there's plenty of time and I'm confident I know what to do next.
This will be a very short post to keep you appraised of my progress with the Conversion Phase of my first project. At this point, I've only put a couple of hours at most into the project, primarily fiddling with the project settings and scene.
The basic scene is set up in my Unity project, with player and a few placeholder platforms in place. I've used very simple, block-y art for the meantime, just to get the idea of layers of platforms across to the player through some simple colour. I'm using the same pre-made player Prefab that was featured in the Brackeys tutorial; it contains some pre-constructed code, but I'll have to break that down anyway, and it has some nice animations to it to make the game look a little nicer.
I've also got the player jumping on mouse click reasonably well, although there's a lot of work to get done with the movement. I still need to make sure the player jumps towards the mouse pointer, and then affect which layer of terrain they're jumping towards by the pointer's position on the game screen (higher for a more "distant" platform in relation to the camera view, lower for a "closer" platform).
I've thought about adding a vertical beam to each of the platforms, to help sell the player on the sense of movement, but that's more a problem of design than code, so it needs to take a lower priority.
After fixing player movement, I'll need to get the platforms moving towards the left side of the screen, towards the player character, and perhaps implement some degree of random delay between their spawning. That should just be manageable with a single Script without too much difficulty.
Overall, a slow start to the project, but there's plenty of time and I'm confident I know what to do next.
Monday, 17 November 2014
First Conversion Phase!
A fine day to you, good readers!
The Tutorial Phase for my first project is now over, leading us to the Conversion Phase. As you may recall, this is the part where I apply my newly acquired knowledge of C# to adapt the mechanics learnt in the Tutorial Phase to form a new style of gameplay.
As mentioned in previous posts, I have been learning the coding techniques from a platformer-style game over the last week. This means I have available to me movement and jumping mechanics, some basic shooting, a scrolling camera, and parallaxing layers of terrain.
Overall, the tutorial was less useful than I had hoped; for one thing, many pieces of fairly critical code were pre-made class files from the Unity3D website, which the tutorial's creator didn't bother to go over. I have and will continue to review these, though they appear at first glance to be somewhat more complex than the code demonstrated. Another problem was that, unknown to me at the start of this project, the tutorial was (and still is) not complete. This means that I will be working with only partial knowledge of the game being demonstrated and the techniques used, but this should hopefully be enough to get on with.
So, then, what is my plan for the Conversion Phase? What manner of game will I be making?
In the interest of helping me to learn what I can from the tutorial, and better understand certain key components (namely the parallax scrolling and mouse position calculations), as well as mildly amusing/irritating my tutors, I will be creating a variant of an endless runner style game.
In the game I have in mind, the player will control a character using only the mouse; when the player clicks the mouse button, the character will jump towards the pointer. This will be used in conjunction with multiple layers of moving platforms, advancing towards the player at different (and gradually increasing) speeds, which the player must jump between to avoid falling off the edge of the screen.
I very much like the idea of using the parallax scrolling in a more mechanical manner. In the tutorial, it was simply used to make different layers of the fore- and background terrain move at different speeds as the player explored the game world, creating a pleasant movement effect, but I think the technique has more potential to certain types of games.
I'll begin work on this game either tonight or tomorrow, depending on how much I sleep and how much work I need to perform for a different project. Updates here will follow when I start making some decent progress and with any luck, a decent version of the game I have in mind will be ready by this Sunday.
Please do wish me luck, readers. Have yourselves a fine afternoon.
The Tutorial Phase for my first project is now over, leading us to the Conversion Phase. As you may recall, this is the part where I apply my newly acquired knowledge of C# to adapt the mechanics learnt in the Tutorial Phase to form a new style of gameplay.
As mentioned in previous posts, I have been learning the coding techniques from a platformer-style game over the last week. This means I have available to me movement and jumping mechanics, some basic shooting, a scrolling camera, and parallaxing layers of terrain.
Overall, the tutorial was less useful than I had hoped; for one thing, many pieces of fairly critical code were pre-made class files from the Unity3D website, which the tutorial's creator didn't bother to go over. I have and will continue to review these, though they appear at first glance to be somewhat more complex than the code demonstrated. Another problem was that, unknown to me at the start of this project, the tutorial was (and still is) not complete. This means that I will be working with only partial knowledge of the game being demonstrated and the techniques used, but this should hopefully be enough to get on with.
So, then, what is my plan for the Conversion Phase? What manner of game will I be making?
In the interest of helping me to learn what I can from the tutorial, and better understand certain key components (namely the parallax scrolling and mouse position calculations), as well as mildly amusing/irritating my tutors, I will be creating a variant of an endless runner style game.
In the game I have in mind, the player will control a character using only the mouse; when the player clicks the mouse button, the character will jump towards the pointer. This will be used in conjunction with multiple layers of moving platforms, advancing towards the player at different (and gradually increasing) speeds, which the player must jump between to avoid falling off the edge of the screen.
I very much like the idea of using the parallax scrolling in a more mechanical manner. In the tutorial, it was simply used to make different layers of the fore- and background terrain move at different speeds as the player explored the game world, creating a pleasant movement effect, but I think the technique has more potential to certain types of games.
I'll begin work on this game either tonight or tomorrow, depending on how much I sleep and how much work I need to perform for a different project. Updates here will follow when I start making some decent progress and with any luck, a decent version of the game I have in mind will be ready by this Sunday.
Please do wish me luck, readers. Have yourselves a fine afternoon.
Tuesday, 11 November 2014
First Tutorial Project Announcement
Hello, dear readers!
This is a very quick post to declare that I am beginning my First Tutorial Project. It will be running from now (the 10th of November) to Sunday the 23rd.
The tutorial I will be using is a YouTube video series for a simple platformer, created by Brackeys CEO, Asbjørn Thirslund.
https://www.youtube.com/playlist?list=PLPV2KyIb3jR42oVBU6K2DIL6Y22Ry9J1c
As I have explained in previous blog posts, this project will be broken into two distinct segments: the Tutorial Phase, and the Conversion Phase. What I will convert the tutorial-demonstrated game into, I don't yet know, not fully understanding the mechanics that will be explained.
My planned changes will be announced in another blog post at the end of the Tutorial Phase, on Sunday at the latest.
Until then, readers, have a great week!
This is a very quick post to declare that I am beginning my First Tutorial Project. It will be running from now (the 10th of November) to Sunday the 23rd.
The tutorial I will be using is a YouTube video series for a simple platformer, created by Brackeys CEO, Asbjørn Thirslund.
https://www.youtube.com/playlist?list=PLPV2KyIb3jR42oVBU6K2DIL6Y22Ry9J1c
As I have explained in previous blog posts, this project will be broken into two distinct segments: the Tutorial Phase, and the Conversion Phase. What I will convert the tutorial-demonstrated game into, I don't yet know, not fully understanding the mechanics that will be explained.
My planned changes will be announced in another blog post at the end of the Tutorial Phase, on Sunday at the latest.
Until then, readers, have a great week!
Friday, 7 November 2014
Academic Reading: Fundamentals of Game Design, Part 2
Hello again, good readers.
As promised, I have read parts of the chapter of Ernest Adams' book, Fundamentals of Game Design, Game Concepts. This should be particularly useful, as I will have to create and realize my own version of several games in the coming weeks, creating concepts based on and using existing mechanics.
Jumping straight into it, we are first adviced by Adams that finding an idea for a game is surprisingly easy; inspiration can be found in almost any source, just by looking at the world around you and thinking about how certain elements or processes could be used. Common sources of inspiration include the dreams and fantasies of the designer, other forms of entertainment media (such as films, books, or television), and even other games.
In these cases, however, the designer should take care not to steal the intellectual property of other people (creating a game directly based upon a movie without the consent of the owners of the rights to that movie, for example), and it should be remembered that good games are rarely formed around a single idea. Multiple ideas or inspirations should be used to flesh out a game concept.
When creating a game inspired by another game, Adams also warns that failing to add enough of your own creativity to the idea can (and in the past often has) leave a game which is unoriginal, or outright copies its source. Find a balance between innovation and the comfortably familiar.
This idea is not enough to be called a concept on its own, however. To advance to having a usable game concept, the designer must make many decisions about the game. Adams lists a number of elements important to creating a fully realized game concept, though in the unofficial and non-competitive context of my dissertation, as well as the limited time I will have with each project, developing the items he lists for each project would be not only unnecessary, but largely unrealistic.
I will use some of the methods he suggests to help flesh my game idea out for each final project (such as the high-concept statement, platforms, and primary gameplay mode), but will otherwise ignore this particular stage of game development, as it appears to be primarily intended for explaining the concept to others, such as when trying to pitch the game.
To help explain what Adams expects from a game concept, I'll go more in-depth with one of the points he says should be included in a game concept: a general summaryof how the game will progress. For this section, I will use my first final project idea (a simple top-down shooter) as an example.
When creating a lengthy game, the player should feel some sense of progress as they advance. This can be achieved by breaking the game into stages or levels, or by applying a narrative to the game, or both. Many games, for example, use a world map with a set number of levels shown on it to let the player view their progression through the game directly, counting how many levels they've already completed and how many they have left before finishing.
With the short amount of time available to me, I doubt I would be able to create a storyline for my game to offer the player, nor would it particularly emphasise coding aptitude beyond the presentation of the narrative. A level system, on the other hand, is probably very much accomplishable in the time I have, and would be effectively applicable in many future projects. These levels could take the form of a linear track, or could branch outwards into multiple paths the player can take, if I dedicate enough time to it.
Adams next asks what conditions should be met to complete a level. In a top-down shooter, there are a number of possibilities, the most obvious of which being shooting down a certain number of opponents. Other possibilities, however, include clearing and/or defending a particular area of the game world, reaching a location elsewhere in the world, or even completing small puzzles using the game's environment.
While Adams also goes into detail discussing storylines and whether they're necessary to a game, what they can offer, and how well the designer needs to understand the narrative at the game's conceptual stage, it doesn't offer us much help for this dissertation project series.
And that should about cover it for the Game Concepts chapter. I may refer back to this post later on in my dissertation, once I focus on the conceptualisation of my final projects, and may create posts going into more depth with this chapter if it becomes necessary.
For now, however, that should be all. The submission deadline for proposals is today, so please do wish me luck.
Until next time, good readers.
Adams, Ernest. Fundamentals of Game Design, Second Edition. New Riders, Berkeley, CA, 2010.
As promised, I have read parts of the chapter of Ernest Adams' book, Fundamentals of Game Design, Game Concepts. This should be particularly useful, as I will have to create and realize my own version of several games in the coming weeks, creating concepts based on and using existing mechanics.
Jumping straight into it, we are first adviced by Adams that finding an idea for a game is surprisingly easy; inspiration can be found in almost any source, just by looking at the world around you and thinking about how certain elements or processes could be used. Common sources of inspiration include the dreams and fantasies of the designer, other forms of entertainment media (such as films, books, or television), and even other games.
In these cases, however, the designer should take care not to steal the intellectual property of other people (creating a game directly based upon a movie without the consent of the owners of the rights to that movie, for example), and it should be remembered that good games are rarely formed around a single idea. Multiple ideas or inspirations should be used to flesh out a game concept.
When creating a game inspired by another game, Adams also warns that failing to add enough of your own creativity to the idea can (and in the past often has) leave a game which is unoriginal, or outright copies its source. Find a balance between innovation and the comfortably familiar.
This idea is not enough to be called a concept on its own, however. To advance to having a usable game concept, the designer must make many decisions about the game. Adams lists a number of elements important to creating a fully realized game concept, though in the unofficial and non-competitive context of my dissertation, as well as the limited time I will have with each project, developing the items he lists for each project would be not only unnecessary, but largely unrealistic.
I will use some of the methods he suggests to help flesh my game idea out for each final project (such as the high-concept statement, platforms, and primary gameplay mode), but will otherwise ignore this particular stage of game development, as it appears to be primarily intended for explaining the concept to others, such as when trying to pitch the game.
To help explain what Adams expects from a game concept, I'll go more in-depth with one of the points he says should be included in a game concept: a general summaryof how the game will progress. For this section, I will use my first final project idea (a simple top-down shooter) as an example.
When creating a lengthy game, the player should feel some sense of progress as they advance. This can be achieved by breaking the game into stages or levels, or by applying a narrative to the game, or both. Many games, for example, use a world map with a set number of levels shown on it to let the player view their progression through the game directly, counting how many levels they've already completed and how many they have left before finishing.
With the short amount of time available to me, I doubt I would be able to create a storyline for my game to offer the player, nor would it particularly emphasise coding aptitude beyond the presentation of the narrative. A level system, on the other hand, is probably very much accomplishable in the time I have, and would be effectively applicable in many future projects. These levels could take the form of a linear track, or could branch outwards into multiple paths the player can take, if I dedicate enough time to it.
Adams next asks what conditions should be met to complete a level. In a top-down shooter, there are a number of possibilities, the most obvious of which being shooting down a certain number of opponents. Other possibilities, however, include clearing and/or defending a particular area of the game world, reaching a location elsewhere in the world, or even completing small puzzles using the game's environment.
While Adams also goes into detail discussing storylines and whether they're necessary to a game, what they can offer, and how well the designer needs to understand the narrative at the game's conceptual stage, it doesn't offer us much help for this dissertation project series.
And that should about cover it for the Game Concepts chapter. I may refer back to this post later on in my dissertation, once I focus on the conceptualisation of my final projects, and may create posts going into more depth with this chapter if it becomes necessary.
For now, however, that should be all. The submission deadline for proposals is today, so please do wish me luck.
Until next time, good readers.
Adams, Ernest. Fundamentals of Game Design, Second Edition. New Riders, Berkeley, CA, 2010.
Academic Reading: Fundamentals of Game Design, Part 1
Good... morning, readers! (Good lord, is that the time?)
There is one element of my dissertation proposal that I've been putting off for a considerable amount of time: the academic reading. This is largely due to the fact that I had a great deal of difficulty thinking what I should (or could) read for the subject of my dissertation.
With the deadline fast approaching, however, I certainly couldn't put it off any longer, so I picked up some books and got to it.
In the end, I decided to use this portion of the dissertation to refresh and reinforce my knowledge of the fundamental elements of game design and creation.
Hence, one of the books I picked up from the library to go through was Ernest Adams' Fundamentals of Game Design. I will continue to read and refer to this book over the course of my dissertation, hopefully enabling me to produce better-realised games in at least the final project of each semester.
Going through it, I searched for areas that I would find helpful when conceptualising small or simple games, and how to boil a video game down to its essential elements.
The first section I read was entitled How Video Games Entertain.
Adams first emphasises here that, while a game is typically created to entertain, no one game will please every person. A good games designer should be able to produce games which entertain the player in a variety of ways, allowing them to target a specified audience every time they create a game.
Next, he highlights that the core entertainment value of a game lies in its gameplay, which hinges on the challenge the game lays out before the player. The player must have a reasonable expectation of being able to overcome this challenge, or else the game may seem unfair; if a powerful opponent is presented to the player, they should be able to believe that they in turn are suitably powerful enough to defeat it.
Gameplay, being at the centre of a game and the experience it offers, should be the first thing the designer considers when making a game.
Next, I delved into the factors that make a well-conceived video game, starting with The Key Components of Video Games.
Adams split this into Core Mechanics and User Interface: Core Mechanics generate the gameplay, defining the challenges of the game and the actions the player may take to overcome them, while the User Interface acts as a translator between the Core Mechanics and the player, converting input and output into something each can understand.
The example Adams offers is a player pressing a button to apply brakes in a driving game; the User Interface reads the button press, and tells the Core Mechanics to slow the car. The car slows, and the User Interface gives the player the appropriate animations and other visual and audio outputs to tell them that the braking has taken effect.
The User Interface can be broken down into two main elements: the interaction model and the camera model. The interaction model converts player input into actions within the game's Core Mechanics, while the camera model takes the events and challenges of the Core Mechanics and translates them for the player in the forms of images, sound, and/or other forms of output.
In the same chapter was a section entitled The Structure of a Video Game:
Adams explains that most games (except for the very simple) only present a subset of their complete gameplay at any one time. For example, a driving game could be split between driving the car and managing upgrades; two elements of the same game which offer starkly different challenges and actions available to the player (the player should not be allowed to purchase upgrades while driving, or to accelerate the vehicle while they're adding a better engine).
These different parts of a game are called gameplay modes.
Each gameplay mode should have a different User Interface from the others, necessary to give the player the appropriate feedback and input options.
Another element of a game's structure is shell menus. Shell menus typically exist before, in-between, and after segments of gameplay, during times when the player is unable to affect the game world. Examples of this are loading and saving the game, options menus, and often pause menus. If the pause menu allows the player to affect the game world in some way, though, such as purchasing upgrades, then it should be considered a gameplay mode rather than a shell menu.
Title screens, credit screens, and loading screens can be similarly termed shell screens, as they offer the player no interaction or feedback from the game's Core Mechanics.
This should do for the first post; after some further reading, I'll be back with my notes from the next chapter of Adams' Fundamentals of Game Design: Game Concepts.
Until then, stay well, readers.
Adams, Ernest. Fundamentals of Game Design, Second Edition. New Riders, Berkeley, CA, 2010.
There is one element of my dissertation proposal that I've been putting off for a considerable amount of time: the academic reading. This is largely due to the fact that I had a great deal of difficulty thinking what I should (or could) read for the subject of my dissertation.
With the deadline fast approaching, however, I certainly couldn't put it off any longer, so I picked up some books and got to it.
In the end, I decided to use this portion of the dissertation to refresh and reinforce my knowledge of the fundamental elements of game design and creation.
Hence, one of the books I picked up from the library to go through was Ernest Adams' Fundamentals of Game Design. I will continue to read and refer to this book over the course of my dissertation, hopefully enabling me to produce better-realised games in at least the final project of each semester.
Going through it, I searched for areas that I would find helpful when conceptualising small or simple games, and how to boil a video game down to its essential elements.
The first section I read was entitled How Video Games Entertain.
Adams first emphasises here that, while a game is typically created to entertain, no one game will please every person. A good games designer should be able to produce games which entertain the player in a variety of ways, allowing them to target a specified audience every time they create a game.
Next, he highlights that the core entertainment value of a game lies in its gameplay, which hinges on the challenge the game lays out before the player. The player must have a reasonable expectation of being able to overcome this challenge, or else the game may seem unfair; if a powerful opponent is presented to the player, they should be able to believe that they in turn are suitably powerful enough to defeat it.
Gameplay, being at the centre of a game and the experience it offers, should be the first thing the designer considers when making a game.
Next, I delved into the factors that make a well-conceived video game, starting with The Key Components of Video Games.
Adams split this into Core Mechanics and User Interface: Core Mechanics generate the gameplay, defining the challenges of the game and the actions the player may take to overcome them, while the User Interface acts as a translator between the Core Mechanics and the player, converting input and output into something each can understand.
The example Adams offers is a player pressing a button to apply brakes in a driving game; the User Interface reads the button press, and tells the Core Mechanics to slow the car. The car slows, and the User Interface gives the player the appropriate animations and other visual and audio outputs to tell them that the braking has taken effect.
The User Interface can be broken down into two main elements: the interaction model and the camera model. The interaction model converts player input into actions within the game's Core Mechanics, while the camera model takes the events and challenges of the Core Mechanics and translates them for the player in the forms of images, sound, and/or other forms of output.
In the same chapter was a section entitled The Structure of a Video Game:
Adams explains that most games (except for the very simple) only present a subset of their complete gameplay at any one time. For example, a driving game could be split between driving the car and managing upgrades; two elements of the same game which offer starkly different challenges and actions available to the player (the player should not be allowed to purchase upgrades while driving, or to accelerate the vehicle while they're adding a better engine).
These different parts of a game are called gameplay modes.
Each gameplay mode should have a different User Interface from the others, necessary to give the player the appropriate feedback and input options.
Another element of a game's structure is shell menus. Shell menus typically exist before, in-between, and after segments of gameplay, during times when the player is unable to affect the game world. Examples of this are loading and saving the game, options menus, and often pause menus. If the pause menu allows the player to affect the game world in some way, though, such as purchasing upgrades, then it should be considered a gameplay mode rather than a shell menu.
Title screens, credit screens, and loading screens can be similarly termed shell screens, as they offer the player no interaction or feedback from the game's Core Mechanics.
This should do for the first post; after some further reading, I'll be back with my notes from the next chapter of Adams' Fundamentals of Game Design: Game Concepts.
Until then, stay well, readers.
Adams, Ernest. Fundamentals of Game Design, Second Edition. New Riders, Berkeley, CA, 2010.
Sunday, 2 November 2014
A More Thorough Breakdown of the First Semester
A fine day to you, dear readers.
Following my previous post explaining the timetable for the first semester, it been recommended to me that I go into more depth about the games I will be creating, and the mechanics I'll be focusing on with them. Remember, my intended final project of this semester is a top-down shoot-'em-up.
So, straight into it with the First Tutorial Project:
I've chosen a fairly generic platformer tutorial series from YouTube to base my first project on.
https://www.youtube.com/playlist?list=PLPV2KyIb3jR42oVBU6K2DIL6Y22Ry9J1c
While platformers are considered (by developers, at least) to be fairly complex, I feel that this will carry a great deal of value for my final project in terms of mechanics, and will give me a strong knowledge basis to continue the project series on.
This tutorial will help me to produce the following relevant game mechanics:
Following my previous post explaining the timetable for the first semester, it been recommended to me that I go into more depth about the games I will be creating, and the mechanics I'll be focusing on with them. Remember, my intended final project of this semester is a top-down shoot-'em-up.
So, straight into it with the First Tutorial Project:
I've chosen a fairly generic platformer tutorial series from YouTube to base my first project on.
https://www.youtube.com/playlist?list=PLPV2KyIb3jR42oVBU6K2DIL6Y22Ry9J1c
While platformers are considered (by developers, at least) to be fairly complex, I feel that this will carry a great deal of value for my final project in terms of mechanics, and will give me a strong knowledge basis to continue the project series on.
This tutorial will help me to produce the following relevant game mechanics:
- Precise controlled movement
- A scrolling camera
- Basic aim-and-shoot mechanics
- Scrolling backgrounds
This tutorial will cover the first two weeks of the practical part of my dissertation, spanning from Monday the 10th of November to Sunday the 23rd of November. As I have stated previously, in that time I will spend the first week (the 10th to the 16th) following the tutorial, and the second week (the 17th to the 23rd) using the same code to produce my own variant of the game, demonstrating my learning.
Next, the Second Tutorial Project:
The second project will use a text-based tutorial describing the creation of a maze game as its basis.
The concept for this is fairly simple; the maze is created via random generation, and the player must explore the maze and find the way out from a first-person perspective.
This tutorial will provide me with the following mechanics and techniques:
- Simple randomly-generated three-dimensional environments
- A basic three-dimensional mini-map covering the level and player
This tutorial will span from Monday the 24th November to Sunday the 7th of December, the tutorial phase lasting from the 24th to the 30th, and the conversion phase lasting from the 1st to the end of the project on the 7th.
The Third Tutorial Project:
After a great deal of searching, I have had to settle for the final tutorial of the semester. The third tutorial describes the creation of a tower defence game in Unity; the problem with it is that the code is written in JavaScript, not C#.
Being (somehow) unable to find a reasonably good quality tutorial for a similar game in English which uses C#, I have decided to simply use this tutorial and translate the code to the best of my ability as I go. It will certainly be challenging, but the rewards of studying a tower defence game should make it worth it:
- Object tracking (rotating one object to follow another)
- More advanced shooting mechanics
- AI pathing
This project will run from Monday the 8th to Sunday the 21st of December. The tutorial phase will conclude on Sunday the 14th, and the conversion phase will begin on Monday the 15th.
Lastly, The Final Project:
With all of the mechanics I will learn in the coming weeks, the final project should feature:
- Reasonably precise player movement
- A scrolling camera that follows the player around the game world
- Randomly generated environments
- A three-dimensional map of the game world, including the player's position
- AI opponents which track and follow the player with some basic pathing
- And, of course, a good deal of shooting (with player-controlled aiming)
The final project will be running over Christmas and into the new year, beginning on Monday the 22nd of December, and concluding on Friday the 16th of January. While I fully expect my progress to slow over Christmas, with four weeks and no time set aside for any tutorials, I'm confident I will be able to complete the project on time.
I'm frankly optimistic about this project series. I'm eager to begin, and looking forward especially to the final project where I'll really be able to play around with the code techniques I've already started learning, and will continue to discover in the coming weeks.
Before I can get to that, though, I do of course need to finish my proposal, the next part of which will be academic reading. More blog posts will follow with that and any other areas I need to add to.
Until then, have a glorious day, readers.
Saturday, 1 November 2014
A More Realized Project Process, and Timetable for the First Semester
Good day, readers, I hope this post finds you well! Before anyone asks, yes, I have applied a new colour design to the blog; I was finding it difficult to read the old one, and it was rather boring and drab, I thought.
Anyway, onto business!
Anyway, onto business!
During the course of searching for tutorials and other sources of C# knowledge, I've been mulling over the project process my dissertation will follow, and with some inspiration from the sources themselves, I've come to what I think is a well-rounded timetable for my dissertation to follow during the rest of the academic year.
As stated previously, I'll be undergoing multiple smaller, tutorial-led game projects, leading up to a larger, more cohesive game project at the end of each semester, one at the beginning of January, and another perhaps due around Easter.
3 - 7 Nov
|
FRIDAY 7th NOVEMBER 4:00 PM SUBMISSION DEADLINE FOR PROJECT PROPOSAL
|
10 - 14 Nov
|
First Project – Tutorial Phase w/ progress updates on
blog
|
17 - 21 Nov
|
First Project – Conversion Phase w/ progress updates and game breakdown on
blog
|
24 - 28 Nov
|
Second Project – Tutorial Phase w/ progress updates on
blog
|
1 - 5 Dec
|
Second Project – Conversion Phase w/ progress updates and game breakdown on blog
|
8 - 12 Dec
|
Third Project – Tutorial Phase w/ progress updates on
blog
|
15 - 19 Dec
|
Third Project – Conversion Phase w/ progress updates and game breakdown on
blog
|
22 - 26 Dec
|
First Semester Final Project
|
29 Dec - 2 Jan
|
First Semester Final Project
|
5 - 9 Jan
|
First Semester Final Project
|
12 - 16 Jan
|
First Semester Final Project – FRIDAY 16TH JAN 4:00 PM SUBMISSION DEADLINE FOR FINAL PROJECT
|
I have decided that the first of these final projects (due after the Christmas vacation) will be a simple top-down shoot-'em-up game built in Unity with its integrated C# functionality.
In preparation for this, I will undergo three projects, each lasting two weeks, following online tutorials, and producing a game unlike the one the tutorial originally demonstrates.
I'm aware that this is unhelpfully subjective, and something that I could conceivably talk my way out of when breaking down each game at the end of the project, so I'll be asking my tutors to judge if the product is sufficiently different from the tutorial to effectively demonstrate my ability to use code to achieve my own designs. If it isn't, then I will aim to perform better in the next project.
After these three projects, the final project, lasting approximately four weeks, will use as many of the mechanics and techniques I have learnt from the tutorials as possible in a single game (subject to whether or not they are appropriate), to be completed and submitted at the end of the semester, on Friday the 16th of January. I will be using the same submission deadline time as the project proposal, to ensure that it can be handed in via the same methods. This will also be just in time for the Project Presentations, to take place in the following week.
The second semester is harder to predict, as much of my planning and intended goals will be based on what I learn during the course of the first semester. What I can say for sure now is that I don't intend to use Unity, preferring to broaden my range of knowledge to cover other platforms. Otherwise, it will likely take a similar structure of tutorial-led projects, concluded by a final project at the end of the semester.
Hopefully that sufficiently explains my plans for the coming semester, and doesn't leave you with more questions than you came here with. If you do have any questions, readers, leave a comment and I will be more than happy to answer them.
Until the next post, good readers, I wish you a very fond farewell.
Mini Project Progress Update 2/2
Readers! Good evening!
Apologies for no update yesterday, I ended up focusing on other work that day, and made very little progress with the C# tutorials. Today, however, oh, such wonderful progress was made!
First of all, triggers for OnCollisionEnter and OnTriggerEnter; whenever one object bumps into another or goes inside a particular space, the function is called. Very useful for a great number of things, including death events, and in Unity surprisingly easy to accomplish.
Just as useful, and perhaps more exciting, is the knowledge of importing assets from modelling programs such as 3DS Max, and animating elements of them. This technique was only demonstrated with a simple spike trap in the game, but my mind is buzzing with possibilities to apply this to.
Among these treasures were some equally important pieces, including level setup and progression, delay timers in progressing mechanics, and applying relative force based on an object's orientation.
So much potential for my dissertation projects, I can't wait to lay into them.
Anyway, I think this is pretty much everything I needed from the tutorial, but I'm going to continue with the series for a few more ideas and techniques. I probably won't document them here unless I make a major breakthrough with anything.
For now, I need to focus on the final components of my dissertation proposal, including academic reading and finishing the timeline. Should be fun.
Until the next post, I wish you a very good day, readers.
Apologies for no update yesterday, I ended up focusing on other work that day, and made very little progress with the C# tutorials. Today, however, oh, such wonderful progress was made!
First of all, triggers for OnCollisionEnter and OnTriggerEnter; whenever one object bumps into another or goes inside a particular space, the function is called. Very useful for a great number of things, including death events, and in Unity surprisingly easy to accomplish.
Just as useful, and perhaps more exciting, is the knowledge of importing assets from modelling programs such as 3DS Max, and animating elements of them. This technique was only demonstrated with a simple spike trap in the game, but my mind is buzzing with possibilities to apply this to.
Among these treasures were some equally important pieces, including level setup and progression, delay timers in progressing mechanics, and applying relative force based on an object's orientation.
So much potential for my dissertation projects, I can't wait to lay into them.
Anyway, I think this is pretty much everything I needed from the tutorial, but I'm going to continue with the series for a few more ideas and techniques. I probably won't document them here unless I make a major breakthrough with anything.
For now, I need to focus on the final components of my dissertation proposal, including academic reading and finishing the timeline. Should be fun.
Until the next post, I wish you a very good day, readers.
Wednesday, 29 October 2014
Mini Project Progress Update 1/2
Good evening, readers.
Well, after far too long, I finally have some manner of progress to report with the mini-project I've been working at.
Following the first few episodes of the second tutorial, I've successfully emulated the code for character movement and object waypoint patrolling, and my knowledge of using Materials and other Unity tools has been reaffirmed. While this isn't necessarily as much progress as I would like for the past two days, it's already giving me plenty of things that I could use in a game with a bit of time and patience.
This is what the Unity window looks like right now; somewhat bare-bones, but it should advance as I do more work with the tutorial series I'm using.
You'll be able to see the progress with tomorrow's update, and then a final update on Friday.
That's about all for now, I'll be back tomorrow with another update. Until then, have a good evening, and wish me luck.
Well, after far too long, I finally have some manner of progress to report with the mini-project I've been working at.
Following the first few episodes of the second tutorial, I've successfully emulated the code for character movement and object waypoint patrolling, and my knowledge of using Materials and other Unity tools has been reaffirmed. While this isn't necessarily as much progress as I would like for the past two days, it's already giving me plenty of things that I could use in a game with a bit of time and patience.
This is what the Unity window looks like right now; somewhat bare-bones, but it should advance as I do more work with the tutorial series I'm using.
You'll be able to see the progress with tomorrow's update, and then a final update on Friday.
That's about all for now, I'll be back tomorrow with another update. Until then, have a good evening, and wish me luck.
Tuesday, 28 October 2014
Estimated Project Process
Good evening, dear readers!
What with my attempts to begin a mini-project in preparation for the meat of my dissertation, I believe I'm prepared to begin estimating the process that each project will take throughout the year. There's not much else to say, I still haven't even gotten close to being ready to make a report on the mini-project itself (hopefully have something for you later this evening), so let's just jump straight in here.
I've found that I will be largely unable to predict the content of each tutorial without watching each of them prior to the planning process. AwfulMedia's Unity C# Beginner series (https://www.youtube.com/playlist?list=PLivfKP2ufIK7SCuf1Sevu196JhgKMX42T), which I've been using to familiarise myself with Unity and help myself begin learning the syntax of C#, spends a great deal of time explaining techniques and concepts that I've been familiar with for over a year now due to my experience with ActionScript 3. However, the series also explains a number of tools which I haven't yet had the chance to use, such as enums (or enumerators), and also re-explained some things which I've used but haven't fully understood.
The bottom line there is that I have been slowly going through each episode, learning new techniques and relearning ones I already knew about, bringing progress to a crawl.
The issue, then, is that each tutorial I use in this project series might follow a similar formula of assuming that the viewer knows very little about coding, and explaining everything along the way. I may not be able to filter this out, and it may not even be in my best interest to if I don't fully understand the way the creator is going about it. So, that will slow me down, potentially quite significantly.
Now, however, for the good news:
I am continuing to learn about Unity, not having experienced it a great deal before, and I'm seeing that it offers a great range of user-interface functionality; accessing and manipulating parts of the code is even easier and more useful than I think I realised before beginning this pre-proposal-project.
For now, I believe I'm able to separate the process of each project during the presentation into two segments, each taking roughly a week to complete:
What with my attempts to begin a mini-project in preparation for the meat of my dissertation, I believe I'm prepared to begin estimating the process that each project will take throughout the year. There's not much else to say, I still haven't even gotten close to being ready to make a report on the mini-project itself (hopefully have something for you later this evening), so let's just jump straight in here.
I've found that I will be largely unable to predict the content of each tutorial without watching each of them prior to the planning process. AwfulMedia's Unity C# Beginner series (https://www.youtube.com/playlist?list=PLivfKP2ufIK7SCuf1Sevu196JhgKMX42T), which I've been using to familiarise myself with Unity and help myself begin learning the syntax of C#, spends a great deal of time explaining techniques and concepts that I've been familiar with for over a year now due to my experience with ActionScript 3. However, the series also explains a number of tools which I haven't yet had the chance to use, such as enums (or enumerators), and also re-explained some things which I've used but haven't fully understood.
The bottom line there is that I have been slowly going through each episode, learning new techniques and relearning ones I already knew about, bringing progress to a crawl.
The issue, then, is that each tutorial I use in this project series might follow a similar formula of assuming that the viewer knows very little about coding, and explaining everything along the way. I may not be able to filter this out, and it may not even be in my best interest to if I don't fully understand the way the creator is going about it. So, that will slow me down, potentially quite significantly.
Now, however, for the good news:
I am continuing to learn about Unity, not having experienced it a great deal before, and I'm seeing that it offers a great range of user-interface functionality; accessing and manipulating parts of the code is even easier and more useful than I think I realised before beginning this pre-proposal-project.
For now, I believe I'm able to separate the process of each project during the presentation into two segments, each taking roughly a week to complete:
- the tutorial phase, in which I will follow the tutorial and learn the techniques I need, and
- the conversion phase, which I will use to rework the tutorial product into my own game, demonstrating understanding of the techniques.
Nothing is final yet, and this may well be improved, refined, or added to in the weeks to come, but for now I think it offers a nice, loose structure to work with.
For now, I'm going to go back to the mini-project, and will hopefully have some tangible progress to report later this evening, and if not (it is quite late), then I will definitely have something for tomorrow. Until then, have a fine... evening, I suppose, mortals.
Subscribe to:
Posts (Atom)