What follows is a reflective review, made a few days after I handed in this project. Although it’s quite long I think it has relevance to this section of my blog:
Toolset
In the beginning I was extremely naive on what working with unreal was all about and what the challenges would be. Having spent the summer in full time employment I had done scant preparation, the only thing I had done was to read Mastering unreal, which gives a somewhat rose tinted view of what it is like to use the tool.
It was this vision of the unreal environment that misfooted me at the start of the year. I was expecting to be using unreal editor to build all of my level and almost drag and drop actions and scripts into place. I have to say that I am glad that it wasn’t like that however.
The script is awkward to get the hang of but I think I have good working knowledge of its structure. I can even say what the two key points of information were:
a. The fact that the playercontroller contains almost anything that you might want to alter within the player experience.
b. The unreal team have built tie-ins to most other things.
I found that once you understand the communication route between the playercontroller, the pawn and the HUD then it becomes a relatively straight forward task to get things done, the key word being relatively.
I have found that when working in unreal just like units of distance there are unreal units of time. I found that it was a lot harder to get things done in unreal script meaning that it was a very difficult task to get a simple task done. One problem was that there exists no IDE, well not a fluffy, totally usable environment like Microsoft.
It must be said that when we are not talking about code the story changes. UnrealEd is a powerful tool which I didn’t really appreciate originally. I found it fairly straight forward but never considered the amount of things it does for you, lighting models for example work straight out of the box in the standard case. Audio is handled very simply, as are asset imports. In fact the only thing I didn’t like was that it doesn’t tell you what it’s doing transparently enough. I regularly have to call the log to see just why this or that doesn’t do something. I know it sound whiney, but I prefer to get a message when things don’t work, rather than just not having anything appear.
Schedule
The scheduling was something that I was very keen to implement. It makes something of a paradox when I consider that I didn’t get a structured working schedule until fairly late on in the development. I want to stress that this isn’t anything to do with not seeing the use in them. This is definitely not the case. I was really into the idea of one, but I struggled to make it accurate.
Initially my issue was that I had a design document with a few features that I wanted to implement, but these features were all based on existing unreal code. I made up my first schedule in a fairly simplistic way. It was fair to say that I wasted time doing it, because it bore no relation to reality in either time scale or scope. Following this I entered a learning process where I was consciously thinking about the length of a task. Having spent 4 or 5 hours searching for a way to get text onto the screen in a class exercise I found it a, frankly, terrifying task as the weight of the material was huge. This made for a very pessimistic second attempt to schedule, where I was expecting to have to spend hours and hours on the most basic of tasks.
I soon realised that like most things it was a mix of these two perceptions. In some cases it was extremely time consuming. In others, it wasn’t. I reckon that there could be a function to describe ‘unreal time’:
WorkTime is dependent on the familiarity to the functions dependencies and parents.
That is not to say that if you work unreal more you naturally get better at it. Rather I believe unreal is best used in a team structure where you can learn your dependencies and parents and then be able to do anything you wish in that system quickly and efficiently.
Another key factor that I didn’t account for was flow disturbance. I found that if I spent time working at university I was only about half as effective as when I was at home. The reason for this was that I have a habit of helping people out.
All these factors contributed to me not getting an effective schedule together.
The question is do I think this harmed my progress? In a strange way it had a dual effect for me. It meant that I had more dead time between tasks because I hadn’t organised what I wanted to do into hierarchies. But it also meant that I was extremely productive when I knew what I was doing because the task was still perceptibly as large at any given time as it was at the start of the project and it caused me more pressure. Now up until this past two weeks I would say that pressure is a good thing, but I have found it one of the most unpleasant feelings in the world to have a constant level of stress above that which is necessary. I was fine to a point, but then a personal situation arouse that I would normally take in my stride, but it totally destroyed my flow for far longer than I expected it to. As a consequence I have been suffering extreme stress which clouds judgements and is therefore best avoided if possible.
So the answer to my question is yes, I think allowing myself to become that stressed only gave me perceivable benefits so long as nothing bad happens in my non-working life, which when were honest is never guaranteed.
It is one of the most important things that I have learned in this semester. Scheduling saves lives… fact!
In terms of the game, I’m really pleased with what I have made. It’s the first game that I have made, that I have genuinely enjoyed playing (which is quite surreal). If I were to do it again I would burn more time planning and replanning even if that cost coding hours because it is only with planning that you can be sure that your product will be tight and ultimately sellable to investers.
What went right?
All in all because of the time that I put in at the start I don’t think I have been perceivably damaged in terms of deadlines , however with correct planning I feel I could have been much more productive in that time. I have learned something new about myself, I find it very important to have structure if I am to achieve the best results.
What went wrong?
I feel that I could have had the polish higher on this hand-in if I had got more done at the start. Like I said above, I am proud of what I have achieved but it still needs work to improve the wow-factor. As this is an advertisement of me I want it to be the best that I could make it. The fact is that I could have made it better with more time, so that is what I intend to do in the future.
The last word
I feel that I have gained a much deeper appreciation for both scheduling and game engines, I found it hard to be working on such a huge codebase with only a few resources (drastically less than a Microsoft toolset for instance), but I enjoyed the challenge for the most part. This experience has made me more confident in my abilities to learn languages in short time spans and still produce acceptable work.
Future development
If this were to go to a full title I would happily integrate these levels into the project. I have never really appreciated just what game music can do for mood before and I am impressed of the effect.
In truth I would like to make the game more actual puzzle and mystery based than these levels suggest. I think the key thing about this kind of IP, to be successful you need a good balance between puzzle and action, something that tomb raider has always benefited from.
