So I finished my degree a year ago having succesfully completed a project about Artificial Neural Networks (controversial here I know). It was the only thing I could think of at the time that met the criteria of the project. I really wanted to do something with GFX but unfortunately because it's not conclusive to say "this looks good" I had to abandon that idea. This year a friend of mine failed for the second time because for the second time he done a gfx based project- both of which looked fantastic i must add. The first interpolated between animations mathematically and the second was a fluid dynamics project handled by the GFX card.

What is your view on the Game Dev education system and do you think it's fair that my friend failed and I passed?

I do think its bs that a project displaying fluid dynamics on a graphics card wouldn't pass... however... i wouldnt be surprised if his paper sucked or something like that prevented him from passing both times.

If it really was because of the chosen topic, then that is sad imo. it should be a lot about execution, and little about topic (within reason of course). If the guy did graphics projects twice it shows his passion and dedication for the subject (still, assuming his execution was there).

First, not really a 'game programming' topic so I'm moving it to the Lounge.

Secondly I doubt the project itself had anything todo with if he passed or not.

My final year project (submitted in May 2007) was a GPGPU project which demostrated a known algorithm trivally adapted to work on the GPU, visualised using a simple surface to show the deformations the algorithm produced and compared to the original CPU version (and some hybrid CPU/GPUs systems).

I got a First for this project.

The reason?
A final year degree project has NOTHING todo with what you do but HOW you do it and how you show that you did it. The vast majority of the marks are in the write up; you could produce a project which doesn't work but as long as you explain why it didn't work and suggest how it could be solved you can get high marks.

Therefore, I would guess that if your friend keeps failing its not because of what he does as a project but the write up and the way he goes about doing it which is killing him.

It's hard to say anything without details.

A fluid demo can be copy-pasted from the net. That's my problem with graphical demos, they can be copy pasted from the net. No wonder there are so many "blablabla technique wont work" threads, because the poster probably copies stuff together.

But again, it's pretty much impossible to judge with no details.

I wanted to add (before reading Phantom's post), that the documentation is more important, than the thing you "develop".
Everything have to be backed up. You can't just throw around details/ideas/anything without proper background. Be it an explanation, or just a citation.
And it's good to have an answer to this: "why did you choose this topic?" (and the answer has to be backed up of course).

EDIT: "to back up" term is fishy... "to support" is better. (I think...)

Quote: Original post by AverageJoeSSU
it should be a lot about execution, and little about topic (within reason of course). If the guy did graphics projects twice it shows his passion and dedication for the subject (still, assuming his execution was there).

Thats the thing, as I said above, if you look at the marking for a final year project it is pretty much (in my experiance) weighted to the write up.

The project doesn't have to be great.
It doesn't even have to fully work.
But the write up has to shine.

The thing is, you know all this going in (hell, if you go in twice you really should know) so even if you think its rubbish that this is the setup its not hidden away somewhere.

The final year project is, to a degree (haha!), about playing the system a bit.

Quote: Original post by LionMX

but unfortunately because it's not conclusive to say "this looks good" I had to abandon that idea.

If only there were a way to *conclusively* say what looks good. Perhaps this could be performed in some, for lack of better word, academic environment. If only there were a way to classify such experiments. Maybe using something absurd, like social experiments and statistical classification.

If only there were an institution that would deal with such topics. In the old days, there used to exist undergraduate university courses, who would provide means and teach methods on how to do all of that. Then there would be conferences where conclusive results could be compared.

Someone should really come up with something like that.



PS: That's BS. University course in science or engineering *must* teach means of how to conclusively determine the outcome.

Otherwise the degree is worth less than something in humanities or a trade school. At least those degrees prove that one can either bullshit or perform a useful skill respectively.


The above project is proven conclusively by using a double-blind experiment using human subject. The results are then classified and tested for statistical significance. This is how entire pharma industry works, how Google and most any user-facing service works as well as all of engineering. It's the foundation of scientific method, and Bayesian, Chi-squared or any other such classification should be Statistics 101 taught in first year. It applies to everything, heck, kids hacking web apps today need to know those to optimize conversions.


But I digress - for past few years, I've seen Master's degrees in Computer Science being issued in "Developing a stock symbol browser application using Struts and J2EE". Fuck that. And people wonder degrees are worthless.

In a couple of years, PhD will be the norm for entry-level jobs.

The point of a degree isn't to prove that you can get pretty results. The point of a degree is to prove that you understand your field. To that end, it is far more important than one can clearly communicate how and why a project does (or fails to do) what it does, than to actually get the results. After all, writing the instruction manual is orders of magnitude more difficult than just following the instructions; that is to say, it's far more difficult to deeply understand the material and be able to articulate that knowledge than to just hit some arbitrary standard of "good looking result."

This is much more apparent a philosophy in the graduate school level, but it still colours undergrad work as well.

And another thing: people (programmers) tend to think that fluid dynamics is just like some -I don't know- rigid body simulation thing: you look it up, copy the formulas, and you implement it. Sure it looks like fluid.

BUT: is the simulation/model really valid? Why/when is it valid? What can this be used for?
Is it good enough for engineering utilization? If not: what else is it good for? "looks good" is not a reason. If you can make it realtime, and plug in in a game: that's a good reason.

Making a VEM-demo is the same: if it's not good for engineering utilization: is it good for games? (most likely not: too slow). Then it's pointless.

If you want to make a really usable (even if it's only a thesis) program with fluid dynamics: be prepared to take 2-3 semester of pretty advanced mathematics, 2 semesters of fluid dynamics (preferably with some mechanics background). Otherwise (not really usable program, that just "looks cool") the choosing of the topic itself is fishy/unexplained.

VEM: same for maths+ 2-3 semesters of statics.

So long story short: IMHO the choose of the topic wasn't "lucky".

Something doesn't seem right with the OP's conclusions, so I will pitch in with my observations from when I did my dissertation.

The problem here is you should write your dissertation as you would any other paper, with one eye on the expectations of the examiner. I could, for example, pitch up with a 3d renderer full of bells and whistles, but if I don't correctly present my write-up, demonstrating certain concepts, I'm going to fail. These include but are not exclusively:

(1) Evidence and discussion of relevant research in the area
(2) A chosen methodology (preferably one that's well known)
(3) A design (again, preferably one that's well known)
(4) Code that implements the design
(5) Some conclusions.

Your dissertation is 10% actually writing code and 90% writing a paper. That is why you can still pass your dissertation with an A grade even if you don't write any code whatsoever. So I think in this case that something has gone wrong with the paper, rather than the subject choice or implementation. The interesting thing though is that your friend has done 2 and failed both. I get the impression he didn't go and ask his tutor why he failed the first before he started on the second!

Edit: Ah, I see phantom has anticipated my reply :p.

Keeping and knowing the intended audience in mind, when writing is key.
Just to add my own experience I had a similar thing happen with one of my presentations in one of my software design courses. I felt my project blew away the rest of the class and they all seemed to agree but apparently the grader didn't feel the same. They felt I left out too many details of my implementation unexplained, parts that I felt were self-evident ,so I didn't bother to go into any depth to explain them :(

[Edited by - daviangel on July 6, 2010 8:48:31 PM]