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.

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:

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

Confirmed Changes to my Dissertation

Hello again, readers!

Following some discussion with my tutors, I am going to go through with a recommended alteration to my current work plan for my dissertation. The project series will remain about 80-90% the same, but now will include a "final" project each semester.

This final project will be a larger game which incorporates mechanics and coding techniques learnt during the course of that series (with roughly three games worth of experience in each), demonstrating an ability to tie multiple mechanics into a single, cohesive game.

For this, I will plan out the mechanics I will need to learn, and select specific games and tutorials that will teach me these mechanics in preparation for the final project for that semester.

This will lean my dissertation slightly closer to a design perspective, but will still be primarily focused on coding, and should still teach me everything that I need to reach my goal of learning C# and demonstrating coding proficiency.


The first of these games, due sometime in January/February (date to be confirmed later), will be a fairly basic top-down shooter. This will involve:

• player movement
• player health
• bullet firing
• a scrolling camera
• at least two types of enemies with some simple pathing AI
• exploding parts of the environment
• possible controller compatibility.

This is a game I would be reasonably confident making in ActionScript 3, so hopefully it shouldn't prove too challenging with the preparation from the projects leading up to it. If I find myself with extra time, then I can also attempt to incorporate a basic degree of random generation to the enemy spawning and/or terrain.


I will begin my search for specific mechanics in tutorials this week, but first I would like to complete a short C# project to let me get a better idea of the process of these projects, including how quickly I'll be able to work with this language, as well as to iron out any problems in my existing knowledge of the language and platform.

I'll begin this tomorrow, and should be done by Friday, giving me a week to locate the tutorials I need and plan out the timetables of my projects before the deadline for our proposals comes about.

Daily updates will follow, beginning with another post tomorrow with my opening progress (please don't expect a great deal).

Until then, have a fine day, readers.

Marking Criteria

Hello once again, readers!

On my course, part of the proposal for our dissertations is to lay out some basic marking criteria to help the markers to know what they're looking for in our work. This means that, for example, a modelling dissertation with focus on texture artwork won't be marked down too heavily for poor sculpture quality.

As I stated in my introductory post, the emphasis of my dissertation will be on coding, specifically in the C# language. This means that I would want the marker to focus on the same elements of the products that I create, rather than, say, the artwork, or the fundamental design of the game.

So, what kinds of things would I like the markers to look for in the games I will be creating for the dissertation? Well, for one, does the game function?
If the game simply doesn't work, then that represents a serious problem in the code, and a failure on the coder's part to fix it before the deadline. A game which doesn't function can't typically be legally sold, and will give the user a very bad experience. In this context, my games need to be able to load, play out, and end without any serious problems which would directly prevent the user from progressing or the game proceeding to operate.

Does the game include any noticeable bugs?
Even if the game works at a basic level, bugs can ruin the user's experience by affecting their ability to play the game effectively, breaking their immersion, or preventing them from advancing. These should have been ironed out by the coder(s) before the game's deadline.

Is the product even a "game"?
Obviously, for a product described and marked or reviewed as a game, it should actually be a game. For the purpose of this dissertation, I would like the definition of a game offered by Eric Zimmerman and Katie Salen (in their book Rules of Play: Game Design Fundamentals, page 80) to be used to ensure my products are games:
"A game is a system in which players engage in artificial conflict, defined by rules, that results in a quantifiable outcome."
That means that the products must have some level of gameplay and user-interactivity, a set of rules to govern this gameplay, and both victory and failure states (whether implied or explicit) based upon the user's actions.

Other than these major points, I would also like my work to be checked for good coding practise; this means that I must follow basic practises like:

• commenting explanations of each part of the code
• laying out the code in a sensible manner (I keep variables at the top, where they're easily accessible, and prefer to lay out functions in a conceptually chronological order, such as Activation at the top and Deactivation at the bottom) whenever possible
• and ensuring that the code is efficient (or at least isn't horribly inefficient). This mostly involves ensuring that no un-used, un-needed or repeating variables or functions remain.

Now, while my dissertation is primarily coding-based, there are also some lesser elements of basic design, notably in the planning stages of my projects, and in the implementation of the mechanics. Of course, the design shouldn't be the focus when marking my work, but I think that it's only fair that the design of the games I create affect my grade, positively or negatively, on a Computer Games Design course. Therefore, I would like the markers to look at my products (particularly my final product of each semster) as games and assign a small percentage of the mark to the gameplay, and whether or not it is enjoyable to them (or if they can understand how it would be enjoyable to others).

This should provide a basic set of principles I wish to achieve with my dissertation work, and which form the basis for marking my work. If any of my tutors reading this find any problems with it, then I'll be more than happy to add to or rectify this post.

Until the next post, dear readers, have a fine day.

Quick Update

A very short post today, just informing you readers of the situation regarding my dissertation.

I'm going to push back the planned week-long project by a few days to allow me to get a bunch of academic reading done, among other things. I'm eager to get that going as I can't accurately scope my dissertation projects until it's done, and because I want to get a good feeling for the rest of the project series.

Otherwise, I've had it recommnded to me that I alter my dissertation once again. It was suggested that I plan to include a final project either at the end of the year or at the end of each semester, incorporating the mechanics of previous creations into a more comprehensive (likely casual) game.

This would slightly shift the focus of my dissertation to include some minor design, and would require me to carefully pick out tutorials to plan for the final product, but it would also demonstrate an ability to incorporate multiple mechanics into a single game coherently. It's worth considering, and I plan to run it by our coding tutor, who is my primary supporting tutor for my dissertation.

That's about all for now. Have a fine day, readers, and I'll be back with more information regarding the pre-proposal project (alliteration!) probably by Wednesday.

Dissertation Updates

Hello once again!

During my hiatus from updating this blog, I've had time to consider my dissertation plans, and to come up with some ideas of how to improve it and make the most of this opportunity to learn C# (and prove that I'm learning it).


First thing, I'm going to be adding an additional rule to the mini-project cycle: While I intend to continue to use online tutorials to assist me in learning C#, I am now going to make my final product during each project a short game or prototype which uses the same mechanics or techniques in a different way than shown in the tutorial. This way, I won't simply be following a tutorial to the end piece and not demonstrating any learning or coding ability.

For example, if I use a tutorial to create a version of Pong, then I should use that to create a game which uses the bounce and movement mechanics to create a different game, perhaps something closer to Breakout.


Second, I have yet to formulate any kind of timeline for my dissertation; I was originally intending to structure my schedule for the next few months based on each tutorial as it came to my attention (e.g. two weeks for a Pong tutorial, three weeks for a basic FPS game tutorial, etc.), but I realised that I don't have any kind of point of reference for my ability to code in C#. Therefore, I'm going to spend the majority of next week (Monday 20th of October to Sunday 26th of October) using a basic tutorial to create a simple game in C#, to get an idea of what my standing abilities are and how quickly I can learn and create using the tools I have selected for my dissertation.

More details on this, such as the tutorial I will use, will follow this weekend in another blog post.


Finally, I am expected to perform some manner of academic reading to assist in planning my dissertation, but I have thus far had difficulty thinking of any kind of reading that would help in my case. I will continue to look into this, getting some help from my tutors, and will hopefully have a better idea of this next week.


That's about it for now, I think. More information will be coming along in the following days/weeks.


In the meantime, have yourselves a fine day, readers.

Employment Options Part 1

A fine day to you!

It's been a long time since I've added to this blog, largely due to the group project taking the main focus of my efforts lately due to a recent deadline. But, that deadline is now past, and in the interest of keeping the blog up to date, I've decided to get to work prepping my dissertation

As part of our proposals, my student group has been encouraged to look at job applications and the requisite and desired traits. These will help us to decide what we want to do for our dissertation, and to refine existing ideas to make them more applicable for employability. Pretty good idea, all things considered.

For this post, everything highlighted in yellow will represent a skill or qualification I intend to have by the end of my course, while everything highlighted in red represents a skill which I neither currently have, nor expect to have attained before the academic year is out.

So, let's take a look at some job advertisements, and see what employers are looking for.


1: The People Network - C#, Java, C++, Delphi SOftware Developer

Qualifications:

• Software developer expertise in C#, C++, Java, Delphi, or XML

Desirable:

• Knowledge or one or more war gaming, mathematical modelling, simulation and defence analysis
• Object Oriented (OO) Design (inc UML) and implementation expertise
• Knowledge of military concepts and doctrine
• Experience of 3D modelling and visualisation
• Teaching/Training experience

This is an excellent place to start with looking for jobs. This position, working in small project teams to provide expert analysis and development of mathematically-based war-game software, requires the experience in C# I'm currently lacking, while I can still meet many of the desired traits (including experience with 3D modelling and knowledge of war gaming). With the C# experience my dissertation will offer, I would personally feel moderately confident in applying for this position.

2: Senitor Associates Limited - C# Developer

Qualifications:

• Proficient in C#/ASP.NET/HTML/CSS/XML/SQL Server
• Commercial awareness
• Excellent communication skills

This position, described only as a greenfield project, is somewhat less ideal for consideration; even with the C# experience I would gain with my dissertation, I would be missing the ability to use a number of coding languages. While it is mentioned that not all of these would be needed, the applicant would need to be strongest in C# and ASP.NET, with experience working with SQL Server. While it is unlikely that I would try applying for this or a similar position after my course, this application helps to highlight that C# proficiency is a desirable trait.

3: Goodgame Studios - Game Client Developer

Desirable:

• Several years of progessional experience with large software projects, ideally in game development
• Very good skills in object-oriented programming and MVC
• Very good knowledge of one of the following programming languages: Java, ActionScript 3, C++, C#
• Experience in the area of current game mechanisms
• The ability to look outside the box and solve problems
• A sense of responsibility, commitment and an open, friendly character
• You enjoy working in interdisciplinary teams and have a passion for games
• You have good knowledge of English, both spoken and written

Another good position to look at here; the only issues here are my lack of large software project experience, and knowledge of either C++ or C#. Otherwise, this would be an ideal position that I would be happy to apply for (aside from moving to Germany, but I'm not entirely opposed to the notion).

4: The Audentia Group - Front End Developer

Desirable:

• Ideally, 2:1 or above in computer science, games development or software engineering
• Experience with gaming/gambling
• Skills in TYPESCRIPT, C#, UNITY, JAVASCRIPT, BACKBONE JS, PHONEGAP, GRUNT BOWER, MARIONETTE, JQUERY, INTELLIJ IDEA, SASS, PIXI.JS, RUBY, GIT, JENKINS, MAVEN, ACTIONSCRIPT

The advertisement for this position lists a lot of skill areas that I haven't even heard of, let alone have experience in. I do know and understand a few items, however, and C# is one of their desirable traits. Once my dissertation is complete, I would be hesitant to apply for this position, but not unwilling.

So far, I've listed four working positions I could apply for with greater C# skills and experience, and there are plenty more already- or to-be-posted. This post is beginning to drag on quite a bit, so I'll leave it at those four for now, and may create another post later with more.

Mentioned multiple times both in these options, and in the posiitons I didn't list, is a desire for applicants with skills or knowledge of the .NET Framework. I think it may be worth looking into it as a possible addition to my dissertation; I'll research it a little more, find out exactly what it is, and consult my tutors.

Otherwise, that pretty much wraps us up for now. Have an excellent day, readers.