Collection: Brian Smullen 4th Year Portfolio



Level Design

I think the level design went very well overall. Right now the level is not exactly as I pictured it in the beginning but I have learned a huge amount of tools and techniques that could help in the process of making additional levels and making similar levels in future. 

I would like to see more models and props in the level but given the short amount of time for this project, that is impossible. I think if we had a full year of development we would see something truly spectacular.

We never investigated the possibility of procedural level building and I dont even know if it would be possible with a world like ours. But I think this is something that could really make this huge. If we could set a few properties and watch as the engine builds a level that would be great.

The last thing I want to mention is that I kind of regret not replicating a real track, we said from the start we didn't want to do that, but as time went on it seems like more people would have liken to see that instead. I still stand by my argument for not doing it that, because we would be trying to replicate a real track, even the slightest things out of place would make the whole track look wrong. Level design is a huge task and I don't think I have the experience or skill to replicate a real world track just yet, especially not in the short semester that I would have had to do it.

Unreal Engine

Unreal engine has worked very well for me throughout the project, I do have a few gripes though.

Firstly Unreal Engine has a huge amount of overhead, there are so many tools and features that will never be used by us and we should be able to disable them and remove them from the engine somehow. This huge overhead means that you need a very good computer to even run the engine, never mind a game full of high poly models and lighting. 

Secondly I think there are some issues with blueprints, they seem to take a very long time to get right where we could have just written the c++ code much faster.

The final thing is how unreal files are all binary which had a negative affect on our source control which you can see in the source control section.

Source Control

We used Git and BitBucket to manage our source control for All The Way Down. Git and BitBucket normally work very well and are very simple to use and have a great backup system where you can revert to previous commits, this is all great.

The problem arises when we are dealing with binary files. This means we have to overwrite files each time we push some changes. Because of this none of us can work on the same files at the same time. Consistently throughout the semester we have had unfinished sprints because one person was waiting on another to finish their tasks before they could start and it left them with not enough time to finish what they needed to do. I don't currently know of any way around this but maybe Unreal Engine provides some more suitable source control via plugins.

An additional problem caused by this was running out of space in our BitBucket repositories. Because we had to replace files with each push our history was forever growing by large amounts.

Overall I don't think Git and BitBucket are a good match for source control with Unreal Engine projects, well in teams anyway.



I don't have much to say about scrum but just a few little things.

Firstly, I found scrum to be an excellent tool for me to know when everyone is working and if anyone is falling behind on tasks. Scrum was also an excellent tool for helping to break big tasks into smaller achievable tasks. I think scrum has probably improved our overall efficiency but I think had we not used it we would have just kept working from the beginning until we were finished, in this case we would have completely burnt out by alpha. I think the use of scrum allowed us to relax a little bit and just take everything week by week rather than looking at the whole project and how much work was to be done.

I think the emphasis on scrum is a little strong in the class. Although it works very well I don't think we should be graded on our process. It's an excellent tool for helping in the project and poor proficiency with it should show in the releases. We don't get marked on Unreal Engine proficiency or Source Control, which in my eyes are equally important skills that are necessary for the project.

Team Project

Team Project is the best module I have had for experience so far. I have learned so much about unreal engine, scrum, teamwork, co-operation, co-ordination and much more, and for that I am very grateful, but I think there are some outstanding issues which need to be addressed for years to follow.

Firstly, I think the theme for the games needs to be dropped, it puts such a clamp on the creativity of the students and limits you to create something you don't want to make. Even though we were given the horrible task of creating a game for tourism we managed to come up with a fun idea early on where we would create a fun, stylized arcade racing game which we were all very excited about, but week by week the mentors sucked all the fun and creativity out of it and turned it into a realistic simulation game. Even if the theme is not dropped altogether it should be optional, or teams should have four or five themes to choose from. I think these limitations on creativity and fun are the one thing that stop these games from being truly amazing.

My next gripe is to do with the mentors of the class. I think their communication between each other is lacking. I have found that I get different answers from every member of the panel for certain issues and early on nobody could truly decide on what "tourism" really is, where we had two of the mentors nearly at the point of argument discussing if our game really had any emphasis on tourism. This is something that can be expected with seven people trying to work together. I just hope someone takes note of this and I think it was an issue of enough importance that it was worth mentioning. 

I think the workload in the first semester of Team Project is way too much. The problem I have with this is that I don't feel that a lot of it is necessary. The research area was fine but for group work I think we should have started development earlier and worked on the game design document as we progressed.

The final issue I have is the idea that everyone has to speak during a presentation. If we are being told that this is a real world simulation of a presentation scenario, it makes much more sense to me to elect the best two or three speakers and they can show off the best presentation and really sell the game better than someone who is not as good a speaker.