Thanks for the information. Having looked on the University of Lincoln's website (assuming you did the BSc (Hons) Computer Games Production course), the course description states the following
"This award is designed to prepare students for employment in the games industry, as a game designer or producer, or in other roles such as games tester"
and also
"This programme also gives you wider skills in media technology, so that you can follow careers in areas such as web and multimedia development"
From the sounds of it, the actual process of 'making' a game isn't actually covered in the course, which is a real shame, but hopefully you have the enthusiasm and dedication to take what you have been taught and do what you want in the future :)
Spree
Developing A Game
Quote:Original post by kaidiez
University of Lincoln.
Dammit. I was hoping they would have improved it by now :/. I did the course a while back when they were still in Hull and found myself in exactly the same position you are in at the moment. I had a strong suspicion that this was the University in question when I read your first post. There were a few good tutors though, K.Jacques for one :).
Basically, I 'bummed' around for a year afterwards, got enough money to do a MSc at the University of Hull. Now I am in the industry :D.
You might want to look around for scripting jobs (Lionhead are hiring at the moment) which is suitable for breaking into the industry. The programming involved isn't too advanced and it exposes you to the creation and development of game. From there you can easily move up to a programming position.
Good luck.
Author
heh small world!
yea kevin is prob one of the few teachers i liked.
Thanx ill have a look at that site aswell.
The course i done is not done anymore I dont think then, my course title was along the lines of:
Games Computing and Software Development.
Now the first years are doing stuff like how to make game music and who knows what else.
yea kevin is prob one of the few teachers i liked.
Thanx ill have a look at that site aswell.
The course i done is not done anymore I dont think then, my course title was along the lines of:
Games Computing and Software Development.
Now the first years are doing stuff like how to make game music and who knows what else.
I remember meeting a few lecturers from Hull and Lincoln (I think, there were a few game development oriented universities involved) when I was doing some demos for a seminar at Abertay a few years back. The lecturers were pretty eagre to learn about how we were using our PS2 kits to teach console development. I remember showing them a few of the PS2 games that had been developed by my peers, as well as explaining how my own PS2 game functioned. They were particularly interested in animation controllers and collision handling for 2D sprite games.
A friend of mine, James Bird, who won the Sony PS2 "Technology Group Quality Award", was also there at the time. It was certainly interesting discussing how we go about developing games with lecturers from other universities.
A friend of mine, James Bird, who won the Sony PS2 "Technology Group Quality Award", was also there at the time. It was certainly interesting discussing how we go about developing games with lecturers from other universities.
This sounds a lot like a problem I had with my course.
Halfway through my degree my University decided to bring in a set of games units which I decided to pick up. I realised that this was the first time they were being run ever and that they would probably be a little basic, however I was very disappointed with it all.
The games programming unit consisted of the standard Direct X tutorial. The lecturer had zero knowledge of Direct X before the unit started, and literally just went through the tutorials step by step, learning while he "lectured" us.
One moment that will probably stick with me for the rest of my life was when he was demoing something he had made over night. It was a simple app that loaded a helicopter mesh inside a sky box and he could rotate it with the keyboard. He said that to make it move you had to tap the keys. One student asked the question "couldn't you just have it so that if you hold the key down the rotation accelerates continuously? Like in other games?" to which the reply was "I don't know. I don't play games."
We never really touched on the actual process of making a game. I believe in another unit the steps were outlined, but we never really went into them. We did have to develop a game in the games programming unit however it was more of "just put everything in the tutorials into one package". I got bored with that idea and developed a terrain engine to fly my helicopter around in and actually got a reduced mark because I didn't implement some really trivial things of which I cant remember right now, but to say I was annoyed is slightly understating.
One positive that has come of this is that in all my Uni course I didn't really have a direction to my career, but after seeing how dreadful the course was I decided to make it my goal to come back to the University and eventually be running the course after I take a few years out for experience/contacts. ;)
I've just got my first job in games development on the mobile phone platform in a company with close links to EA so I'm well on track of my goals. As they say, every dark cloud has a silver lining.
As for your question, I would say that the most important thing you can do is give yourself small goals to reach. Something like "code a FPS with 80 different types of weapons and 400 levels" might sound exciting, but when you actually start coding for long sessions and feeling no closer to your goal, it's very easy to lose interest. When you split it up into goals that you can probably reach by the end of the day the feeling of progress is so much greater and it's very easy to keep up a momentum that way.
Good luck to you.
Halfway through my degree my University decided to bring in a set of games units which I decided to pick up. I realised that this was the first time they were being run ever and that they would probably be a little basic, however I was very disappointed with it all.
The games programming unit consisted of the standard Direct X tutorial. The lecturer had zero knowledge of Direct X before the unit started, and literally just went through the tutorials step by step, learning while he "lectured" us.
One moment that will probably stick with me for the rest of my life was when he was demoing something he had made over night. It was a simple app that loaded a helicopter mesh inside a sky box and he could rotate it with the keyboard. He said that to make it move you had to tap the keys. One student asked the question "couldn't you just have it so that if you hold the key down the rotation accelerates continuously? Like in other games?" to which the reply was "I don't know. I don't play games."
We never really touched on the actual process of making a game. I believe in another unit the steps were outlined, but we never really went into them. We did have to develop a game in the games programming unit however it was more of "just put everything in the tutorials into one package". I got bored with that idea and developed a terrain engine to fly my helicopter around in and actually got a reduced mark because I didn't implement some really trivial things of which I cant remember right now, but to say I was annoyed is slightly understating.
One positive that has come of this is that in all my Uni course I didn't really have a direction to my career, but after seeing how dreadful the course was I decided to make it my goal to come back to the University and eventually be running the course after I take a few years out for experience/contacts. ;)
I've just got my first job in games development on the mobile phone platform in a company with close links to EA so I'm well on track of my goals. As they say, every dark cloud has a silver lining.
As for your question, I would say that the most important thing you can do is give yourself small goals to reach. Something like "code a FPS with 80 different types of weapons and 400 levels" might sound exciting, but when you actually start coding for long sessions and feeling no closer to your goal, it's very easy to lose interest. When you split it up into goals that you can probably reach by the end of the day the feeling of progress is so much greater and it's very easy to keep up a momentum that way.
Good luck to you.
Quote:Original post by kaidiez
The course i done is not done anymore I dont think then, my course title was along the lines of:
Games Computing and Software Development.
That's the one.
Quote:Now the first years are doing stuff like how to make game music and who knows what else.
Been there, done that ;), along with Level editing and 3D animation with 3DS max.
The course basically suffers from "jack of all trades, master of none" problem.
As aside note, Hull are using actual Gamecube Devkits for a while now. One of the projects we had for a our MSc was to port our group project to the Gamedev in less then 14 days with just the DevKit and SDK + documentation. Now, that was interesting :P/
If you're interested in getting into developing your own game then IMO there are two main issues your going to need to tackle:-
1) Understand your technology and the tools you're going to use..
I know this probably sounds like a no brainer but I'd seriously reccommend you sit down and spend some time getting familiar with whatever APIs, IDEs or languages your going to use for the portfolio piece your looking to put together.. Nothing kills your motivation to continue like when you click compile and the IDE throws up 100 error msgs, the likes of which you have absolutely no idea how to deal with because you don't know what you're doing with the APIs you are using..
When I started working on portfolio work (after I graduated from a pure Software Eng degree with only a rough knowledge of DirectX 8.0 and 9.0 and a dream of building a complete 3D board game) I spent the vast majority of my initial development time working through each task I wanted to perform incrementally.. I'd say something like "ok now I want to get a blank window up on screen", "now let's get a FPS counter up on there too" or "ok now i'm ready to build my state mahines" and then i'd break the task down and learn how to do it, step-by-step and often prototyping specific elements in seperate projects so that once I got the code working I could implement it into my main app.. The key is control and manageability and you need to make sure that as you progress, you take the time to learn each step thoroughly enough so that you're not quickly overwhelmed and can understand everything you do (which is essential for when you run into bugs which you will far too often..)
And finally...
2) Plan before you code...
At each step you should sit down and think about what you want to implement next and using your knowledge of the tech/tools, how you're going to do it.. You should also take some time to properly flesh out your ideas for the game before hand which can drastically improve your ability to control the scope of the game and also help you to understand (once you're familiar with the tech) how to organise your data structures, classes etc.. Before I started coding I spent a little time putting together a rough design document for the game (which as far as design docs go, was conprehensive enough to know what needs to be done and to give me a good idea of how) and yet wasn't so long winded that I got bored of writing (roughly only around 5-10 pages in total).. I also went so far as to try out some UML descriptions of the game classes I thought I would have needed which, although would be way to low-level for a proper design doc they did help me understand things better at the time (also they were not fully representative of what went into the actual game but they helped tremedously in terms of starting off in the right direction so that I wouldn't have hit a point where significant re-factoring would have been necessary)..
At the end of the day if you spend enough time carefully planning before you try to jump straight in then you'll find that not only will you end up in a position where you can effectively make consistent progress, maintaining your motivation to finish, but you'll also get a good chance to effectively put into practice alot of the software engineering principles/practises which you should have learned academically (at least to some degree) which will drastically help you in terms of working productively and help avoid time spend re-writing poor code..
This then means that you don't ever have to restrict yourself to starting with a "pong" or tetris clone and you can set your sights on something a little bigger from the offset whilst also learning sooo much more in the process..
Overall I must have spent the better half of 4 months after graduation working on my 3D strategy board game and once it was complete the sheer sense of accomplishment and experience I gained proved to be invaluable since that single demo managed to land me my first job in the industry..
Good Luck!
1) Understand your technology and the tools you're going to use..
I know this probably sounds like a no brainer but I'd seriously reccommend you sit down and spend some time getting familiar with whatever APIs, IDEs or languages your going to use for the portfolio piece your looking to put together.. Nothing kills your motivation to continue like when you click compile and the IDE throws up 100 error msgs, the likes of which you have absolutely no idea how to deal with because you don't know what you're doing with the APIs you are using..
When I started working on portfolio work (after I graduated from a pure Software Eng degree with only a rough knowledge of DirectX 8.0 and 9.0 and a dream of building a complete 3D board game) I spent the vast majority of my initial development time working through each task I wanted to perform incrementally.. I'd say something like "ok now I want to get a blank window up on screen", "now let's get a FPS counter up on there too" or "ok now i'm ready to build my state mahines" and then i'd break the task down and learn how to do it, step-by-step and often prototyping specific elements in seperate projects so that once I got the code working I could implement it into my main app.. The key is control and manageability and you need to make sure that as you progress, you take the time to learn each step thoroughly enough so that you're not quickly overwhelmed and can understand everything you do (which is essential for when you run into bugs which you will far too often..)
And finally...
2) Plan before you code...
At each step you should sit down and think about what you want to implement next and using your knowledge of the tech/tools, how you're going to do it.. You should also take some time to properly flesh out your ideas for the game before hand which can drastically improve your ability to control the scope of the game and also help you to understand (once you're familiar with the tech) how to organise your data structures, classes etc.. Before I started coding I spent a little time putting together a rough design document for the game (which as far as design docs go, was conprehensive enough to know what needs to be done and to give me a good idea of how) and yet wasn't so long winded that I got bored of writing (roughly only around 5-10 pages in total).. I also went so far as to try out some UML descriptions of the game classes I thought I would have needed which, although would be way to low-level for a proper design doc they did help me understand things better at the time (also they were not fully representative of what went into the actual game but they helped tremedously in terms of starting off in the right direction so that I wouldn't have hit a point where significant re-factoring would have been necessary)..
At the end of the day if you spend enough time carefully planning before you try to jump straight in then you'll find that not only will you end up in a position where you can effectively make consistent progress, maintaining your motivation to finish, but you'll also get a good chance to effectively put into practice alot of the software engineering principles/practises which you should have learned academically (at least to some degree) which will drastically help you in terms of working productively and help avoid time spend re-writing poor code..
This then means that you don't ever have to restrict yourself to starting with a "pong" or tetris clone and you can set your sights on something a little bigger from the offset whilst also learning sooo much more in the process..
Overall I must have spent the better half of 4 months after graduation working on my 3D strategy board game and once it was complete the sheer sense of accomplishment and experience I gained proved to be invaluable since that single demo managed to land me my first job in the industry..
Good Luck!
Currently studying (MEng) Computer Science with Games Dev. at Hull and it sounds like it's improved somewhat.
We turned out 3 games for coursework and 1 for my final dissertation (which was a 5 person group project, of which 3 left before it started, so the game ended up crappy anyway)
The first was a copy of R-Type in the second year, interesting to do as we had a basic introduction of OpenGL and Windows programming and told to get on with it. Nothing specifically advanced (no particle systems, physics, audio, input etc.), nor was the actual process of games design covered.
The second one was a physics simulator using ice hockey. The module was extremely well covered. The only flaw was that the lecturer could describe what he wanted to explain properly and often reverted to just drawing pictures with formulae. Also, his time dalmations were amusing, but offputting.(Even so he was brilliant at what he did) :)
The third and final coursework game was a Geometry Wars clone in which the process of Games Development was explained (only took 3 years...I thought that was why I was taking this course). I'd refer to this coursework as an "emalgamation" of all the things we had done previously in order to create a working Game Engine. However, the timescale we had to complete the work was far too small. (8 days) So in 90% of cases the engine couldn't be designed properly and it turned into a basic procedural game.
My dissertation was to create a Multiplayer Real Time Strategy Game. Myself, (specialising in Networking) was to create the distributed database and Network Interface. We had an AI member, Core Engine member, Graphics member and Physics Simulation member. Unfortunately, they all chose to leave the project at the beginning of the year as it was "far too difficult" for them. Leaving myself and the AI designer.
I don't like putting the work I do down, but it was a complete shambles. We now had twice the workload to do in 2/3rds of the time. (Deadline changes due to University semester changes)
It turned into a 2D "Colour Block" RTS which doesn't work 60% of the time (due to "Incorrect Application Configuration" never found out what caused this).
I have several problems with the way the other person conducted his behaviour in regard to programming, but I won't bring my personal problems to the forum. Needless to say, not only was I programming my own section, but all of the peoples who left and about 20% of the AI aswell.
Anyway, what was I saying? Oh yeah, going onto the MEng course next year. (1 year industrial placement financed by the "state".)
The reason I'm not doing the MSc is simply because I can't afford to do so. From the things I've heard about the MEng, it doesn't matter which course you do it's all the same and quite often the Games Dev. students will be working on systems not relating in anypart to Games.
Wish I had the cash for the MSc, but that's life right? :)
We turned out 3 games for coursework and 1 for my final dissertation (which was a 5 person group project, of which 3 left before it started, so the game ended up crappy anyway)
The first was a copy of R-Type in the second year, interesting to do as we had a basic introduction of OpenGL and Windows programming and told to get on with it. Nothing specifically advanced (no particle systems, physics, audio, input etc.), nor was the actual process of games design covered.
The second one was a physics simulator using ice hockey. The module was extremely well covered. The only flaw was that the lecturer could describe what he wanted to explain properly and often reverted to just drawing pictures with formulae. Also, his time dalmations were amusing, but offputting.(Even so he was brilliant at what he did) :)
The third and final coursework game was a Geometry Wars clone in which the process of Games Development was explained (only took 3 years...I thought that was why I was taking this course). I'd refer to this coursework as an "emalgamation" of all the things we had done previously in order to create a working Game Engine. However, the timescale we had to complete the work was far too small. (8 days) So in 90% of cases the engine couldn't be designed properly and it turned into a basic procedural game.
My dissertation was to create a Multiplayer Real Time Strategy Game. Myself, (specialising in Networking) was to create the distributed database and Network Interface. We had an AI member, Core Engine member, Graphics member and Physics Simulation member. Unfortunately, they all chose to leave the project at the beginning of the year as it was "far too difficult" for them. Leaving myself and the AI designer.
I don't like putting the work I do down, but it was a complete shambles. We now had twice the workload to do in 2/3rds of the time. (Deadline changes due to University semester changes)
It turned into a 2D "Colour Block" RTS which doesn't work 60% of the time (due to "Incorrect Application Configuration" never found out what caused this).
I have several problems with the way the other person conducted his behaviour in regard to programming, but I won't bring my personal problems to the forum. Needless to say, not only was I programming my own section, but all of the peoples who left and about 20% of the AI aswell.
Anyway, what was I saying? Oh yeah, going onto the MEng course next year. (1 year industrial placement financed by the "state".)
The reason I'm not doing the MSc is simply because I can't afford to do so. From the things I've heard about the MEng, it doesn't matter which course you do it's all the same and quite often the Games Dev. students will be working on systems not relating in anypart to Games.
Wish I had the cash for the MSc, but that's life right? :)
The best way is to use a game engine. There are some free ones on the net,
like Irrlicht, Chrystal Space and Ogre (google them) , and for professionals too, which are expensive. To use them you only need to know C++.
Of course it is good if you know the basics of a renderer, such as OpenGL or DirectX.
like Irrlicht, Chrystal Space and Ogre (google them) , and for professionals too, which are expensive. To use them you only need to know C++.
Of course it is good if you know the basics of a renderer, such as OpenGL or DirectX.
Can I humby suggest the University of Teesside - it has a very good games programming degree and a masters for people who have completed game programming degrees. From what I have seen only Abertay is at the same level - a lot of Universities have just jumped on the band wagon as is clearly shown by some comments here. They really annoy me as they devalue the courses. We have many lecturers who used to work in the industry and bring valuable experience of real life. Our students write many games in their time with us and some work in industry on a placement and many get jobs in local companies. One medium sized company (60-80) has half of all its programmers sourced from us :)
Sorry if this sounds like an advert but I just wanted to say that not all games programming degrees are as bad as some described here.
[Edited by - Trip99 on May 23, 2007 4:16:02 PM]
Sorry if this sounds like an advert but I just wanted to say that not all games programming degrees are as bad as some described here.
[Edited by - Trip99 on May 23, 2007 4:16:02 PM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
