Jordan's EUCROMA Blog

[eucrogramming-blog-blog]

Eighth Week 25/03 - 31/03 Sound Manager Beginnings

This week was only 3 days long before holidays. We decided to use the programmers' free time to help out the Tech Leads in making a Sound Manager for Unity, so that the Audio people can do their job more effectively, with less interaction and dependencies from the programmers. It would be all the Abertay programmers (Steph, Jordan and I) as well as a Tech Lead, Alex, working on it together. We used the short amount of time we had this week to plan the code structure of the manager, as well as investigate how exactly was the best way to go about serialising our data in the manager. We used pair programming, Alex and I together doing the base of the program; making all the empty classes connect to each other correctly and whatnot. While Jordan Cameron and Stephanie looked up serialisation and went about attempting to implement that. As it was a 3 day week we didn't get a lot done, but the base of the program. So nothing works yet, but it looks like it's own editor and there's our own custom GUI. GUI programming is strange to begin with. The biggest problem I'm having with it is that you think you have to code something yourself and then a few hours later you discover a static function that was there all along, that does exactly what you need. I just with we had research time on useful functions already built into Unity, because there are a lot of classes that you wouldn't know what they did until you tried to use them. Next week will be all about making the GUI actually work and have all the required options necessary. I went home for the Easter Holiday. It was a good change of pace.

[eucrogramming-blog-blog]

Seventh Week 18/03 - 24/03 Crazy Runner

This week the production team were given the task of making a game in 3-4 days. The game document we were given was an endless runner game called Crazy Runner. The other groups set out to start making the assets, like the walls and the player character; while the programmer just went straight into it. I was given the task of creating the randomly generating obstacles, that come in the player's way. I accomplished this while also structuring he code in such a way to allow for on the go changes of: the spacing of the obstacles; their position and direction; the amount of them on screen (as each obstacle was reused after it had complete it's cycle, to reduce keep the game smooth). Unfortunately the game ended up just speeding up at a set rate and we never actually changed the distance between the obstacles. But the original code took those into consideration at the beginning so it was much easier to implement them later on, even if they weren't used. I also did the fog in the distance in the game, as well as the auto-jump, whenever you go through a hole in the obstacle. The fog is done using particle effects, which are incredibly fun to program. This week we actually got a finished and polished game out, that we're all proud of! it's actually fun as well, which is really good since it only took us 4 days. Here is the finished product: http://dl.dropboxusercontent.com/u/16179660/CrazyRunner/FINALBUILD.html

[eucrogramming-blog-blog]

Sixth Week 11/03 - 17/03 Culture

This week we didn't do much. We had a few semi interesting lectures on Eucropean Architecture, then we visited the Copenhagen National Museum. Luckily for me I had bought a bike the day before so the trip to the museum was easy. Later on in the week we were told that we were going to be participating in a quick 3 day project, next week. We'd be making a game called Crazy Runner, as another quick pipeline test. This time we were expected to have something playable by the end though. It's just an endless runner type of game, with a zany character and funny graphics and audio. I'm really looking forward to it, and getting back to actual work.

[eucrogramming-blog-blog]

Fifth Week 04/03 - 10/03 'Sprucing Up'

This week was set for adding the finishing touche to the Dancer/Fencer game (and animation for the others). The programmer's goal was to get the different scenes working together, and shifting between them properly; as well as trying to show the user what to do while keeping with the goal of having absolutely no user interface.

In order to achieve the minimum UI goal we had to be able to show the player that he could do actions, as simply as possible. Sometimes that was accomplished via the Camera; it would zoom into something you should go towards, or turn towards the goal, which worked very well. I think we could have made the Camera seem more subtle though, but oh well that's just nit picking. Another method we used to suggest interactability to the player was to make things 'glow' using particle effects. These particles flying on or around an object meant the object was interactable, and therefore you could press the action button to do something while near it. This also wasn't incredibly subtle, but it looked very nice at least. Programming Particle Effects is very fun as well; especially since you can give each particle another particle effect, themselves! Sometimes convoluted programming is the funnest, but mostly it's the exact opposite.

Throughout the week we were given more and more assets, which really helped. All the game animations and models and sounds eventually got into the game, so we succeeded, I suppose. The 'game' still plays horribly though. But that's partly because of the game script we were given. It's more like an interactive animation; it's not fun at all. But, as mentioned, to actually make a good game wasn't the goal; the goal was just to try, and see what goes wrong. So I'm very glad we did this task, even if I disliked it.

During this project though I did struggle with motivations. Mainly because of the aforementioned fact that this project's goal wasn't to create a finished product, it was just to work and see where the holes and bottlenecks in the production pipeline are. It is a good thing to be able to work without any stress of deadlines or expectations from everyone else. All you're expected to do is actually work. But without the motivation of having an end goal in sight, I found that I had very little to no motivations at all, while doing particularly boring work. Because of that my work suffered this week, and I let the team down. After an extensive talk with the Lead Programmer and a few Project Managers I have realised a few of my mistakes that led to this: I need to do any work I promise/state I will do, that promise/statement is a motivation in itself that I did not see at the time; I need to improve my communication in general, whether it be if I'm struggling or just giving reports on where I am with my work. I know that this is just a one off example, as in all other times I'm going to have some sort of motivation. It's just in this one I had literally none (that I could see at the time). So in another way this test project has helped, and I'm very glad we did it.

[eucrogramming-blog-blog]

Fourth Week 25/02 - 03/03 Production

This week we actually started coding! This coincided with Grant Clarke coming over to teach and help us with Perforce. He was only here for a few days, but it was really helpful.

He straightened out to us what we actually had to do for our modules back at Abertay. I don't have to follow the Coursework Specifications, I just have to meet the Learning Outcomes, as well as write a big 2000 words essay on how what I have done meets those outcomes. THis give me more freedom to do what I like, and we would have essays for most modules anyways, so it's actually less work overall. The trick is doing this work in conjunction with the work at EUCROMA.

I'm thinking about doing a Non-Euclidean Level Generator in Unity for my Procedural Methods module, back home. It would generate a series of rooms, randomly, that would not follow ordinary space. This sounds so fun I've already started testing it out in Unity :D

This week we got a good few stages of the game working. Unfortunately since it's in early production and we're using placeholders, it all looks terrible. But we can put up with that. We have a moveable player, Fencer AI and a working mirror. One of the big mistakes we made was to rely on the animation for movement. This was chosen because it was less work, as the movements were already in the animation; however this made us reliant on the animators to provide the animations before we could even test out scenes. Which really slowed down production, later on. Another mistake we made was choosing to go with open movement, instead of something like pseudo-tile based; it just made the whole game seem clunky and fiddle-y to actually accomplish any of the objectives (like block the Fencer). Some sort of tile based approach would have suited this style much more, especially with the rythme of movement fitting in with the setting.

But in the end, as I mentioned before, the end result doesn't matter. This was all just a learning experience; so I'm glad we made these mistakes now rather than later.

At the end of this week all (the whole production team) had to do a big presentation to a few out of office people (lectures and game producers) on what we had done over the past 2 weeks. The presentation went well overall and they had some good critical feedback, while still being aware that we were doing all of this as a learning experience.

Overall I'm really enjoying working in Unity. It makes a lot of things simpler, but there are some stuff you just have to know before hand in order to do correctly. I'm going to put in a lot more effort into learning Unity over these next few weeks before the actual big projects.

After a discussion with the Tech Leads and the Production Managers about future plans we found out that we're actually going to be making 2 games. This may require 2 Lead Programmers - one working on each game along with one Programmer on each and a floating programmer that works on both. Personally I would like the be the floating programmer that works on both of them; it seems like it would be more fun as well as more challenging. We'll have to wait until we start the actual games in a few weeks to decide if this structure is best.

[eucrogramming-blog-blog]

Third Week 18/02 - 24/02 Pre-Production (backlog)

This week we started actually planning the code out. This proved to be harder than it seemed. Programming is notorious for having MANY many different ways to do the exact same thing, so this took a lot of back and forth between us all to get something we all agreed upon. Which didn't matter anyways as it changed a few more times over the week back to almost our original plan for the structure. Oh well at least the plan was agreed upon again.

So since it was pre-production week we were to actually do any gameplay, we were to test out everything. Everything we did was probably going to be scrapped and done again, but it was just to see if our plan for the structure (especially for Audio and other groups) were going to work.

One big thing we tested a lot was the animations that the animators recorded in a Motion Capture this week. They all worked fine in Unity so everything was good. At one point when they were recording the Game specific animations the animators claimed one of us (me) to come direct the actors in the Motion Capture; as they felt they didn't know the game script well enough to do the movements justice. And it was in everyone's best interests to get the movements recorded correctly, first time. So I got to say "Action!" and "Cut!" with no hint of sarcasm, while informing the dancer and the fencer on what I wanted them to do, every scene. After a few hours of Mo-capping we had all of them done, and it was just up to us to wait for the animators to clean the shots and give them to us.

Giving us the shots only brought up more problems. We are using Perforce to share assets here, but Unity doesn't have a direct link into Perforce, so the programmer have to still use Unity's Asset server. So the Tech Leads wrote some scripts to move everything from Perforce in a way that Unity liked, then it would sync via the asset server on one of the computers (mine) over to all the other programmers. This worked for a while, then the script had problems, which we later discovered was down to people not using the naming conventions correctly. The main idea of it, though, is that the programmers don't have to go to Perforce for anything, we just get it delivered to us automatically, via the Tech Lead's Programs. I like that.

Also this week we made a group decision that Tasos would be the Lead Programmer. It goes towards some goals for his course and he seems the most qualified for it, so I am perfectly fine with this decision! That, and I get to write more code if I don't have to run about all the time; which is always good.

[eucrogramming-blog-blog]

Second Week 11/02 - 17/02 Planning (backlog)

This week we were given a script for the Fencer and Dancer game, and told to spend the week planning everything about the game. This was the programmer's task since the production and conceptual people are studying separately for the time being.

The script itself was okay, but seemed very vague in places as to what the actual gameplay was meant to be. This is probably because the script was meant for a game and an animation. We had the whole week to plan and flesh out ideas for it though, so it wasn't too bad.

At first I felt that the programmers being the game designers was just to give us something to do while the other teams did their work. But I soon learned just how much you actually need to plan a game before you can start it. The tiny tiny decisions at the beginning have huge effects later on and changing them down the line can be a nightmare. We struggled with a few parts, like deciding on how the movement of the player would work. But we were told we basically had free reign over the vague parts, and we could even talk to the script writer and ask for permission to change parts, so it wasn't too bad.

Over the week we met with people from all the majors here: Audio; Riggers; Modellers; Animators; etc. These meetings were to discuss what we needed from them for the game, and while we (as the would-be game designers) had the final say, it was more of an open discussion.

We didn't write a single line of code, or even plan the code structure, this week. All of it was planning, planning, planning. And thank god we did that, because (as I learned), it was really necessary. If we had started coding from the get go (or even started planning coding) then it all would have went to waste as the vision of the game shifted with the planning.

We were specifically told by Daniel (a lecturer) that the end product didn't matter at all. He was perfectly fine with us failing at this task and having nothing to show for it; it was just a learning experience. We're meant to find bottlenecks, identify problem, get used to working together and get used to working in Unity. I really like this idea of a no pressure approach to a task; it allows us to just get to work and not have to worry about results, this early in the game.

So this week I learned just how necessary proper planning is before jumping into production, and gained a new found respect for Game Designers. Sitting there and just planning a concept like that just drained me (and the rest of the coders it seemed). I personally just found it tedious and straining (especially when people disagreed). Arguing about code can generally be solved by just trying both approaches and benchmarking it or comparing the other positives; it is mostly logical. Didn't find much of that when arguing about concepts being better/most suitable than others.

[eucrogramming-blog-blog]

First Week 1/02 - 10/02 Arriving (backlog)

Quick sum up of coming to Copenhagen: the flight was fine; the public transport is awesome; the food isn't as expensive as I was warned; my accommodation is fine. The EUCROMA building is amazing. It's situated in the middle of nowhere, but that happens to be right next to my accommodation so it's very convenient. We have amazing internet here (100Mb) and all the production team have their own desktops! The programmer's computers are the best: 8GB RAM, a GeForce GTX 660 Ti Graphics Card and an 8-core 3.6GHZ processor. Anyone who needs one can also get a laptop as well, so I'm very very impressed with the hardware they have ready for everyone. This week we got a crash course on Unity. Unity seems like it's so incredibly easy to use, when you get over the initial hurdle of learning to use it. We got split into random teams and were told to make a random game in Unity, together. So Hannah (Production Manager), Katrine (Modeller) and I (Programmer) went and made a turn based zombie game thing. Using Unity was quite fun; it seems like a good investment of my time to learn it. Here's what we made. It was a weird first impression of working in a group office dynamic, but it was really fun. Also I was selected to be one of the students to do the weekly EUCROMA blog. We had a lot to talk about since it was the very beginning of the program, so it wasn't too difficult. The prospect of a weekly blog where we interview other students sounds really interesting though. The fact that we have keys to come and go from EUCROMA at any time is one of the best things about this week though. The preparation for this project has been fantastic so far.