It seems to me that you're conflating the tool chain and the engine. A game engine isn't really used to make assets. if you're tasked with the graphics system, all you should be concerned with (IMHO) is using existing assets (meshes, textures, sharers, maybe text) and game object data (position, orientation, whatever) to draw the world and HUD. Models can be created in existing midelling software and exported into a standard data format, which can then be read by your engine using a library such as assimp. If you're already able to draw hardcoded models, it shouldn't be too difficult to leverage your code to drawing arbitrary models.

I've recently been asked (in a team of 3) to create a small game engine, generic as possible. I've recently grabbed a copy of the book "Design Patterns Elements of Reuseable Object-Oriented Software". So far I'm learning alot of new design patterns, although I've NEVER used a design pattern before, or created an engine.

It's a wrong question, a bit like asking what new bricolage tools you should buy because a large hardware store just opened. The proper approach to design patterns (and design in general) is starting from a specific problem and finding a specific solution; the GoF book clearly states that the design patterns they describe have consequences that can only be evaluated in a concrete context (often it's the trade-off of making something easier to change, efficient, robust, etc. by making something else harder to change, complex, etc.: only you can tell if it's what you need).

It's unfortunately less explicit about OO design principles (one of the main ones in the book is being very careful with concrete classes and leveraging interfaces to do something fancy with multiple implementations thereof, but it's mostly implicit in the treatment of Adapter, Proxy, Decorator, Composite, most cretional pattern, etc.) and about how one should apply those principles in a concrete, real-world design.
The design patterns are pure and simplified abstractions of what many different problems and solutions have in common (often mere C++ or Smalltalk tricks and idioms that might not occur to everybody, most infamously how to write a Singleton), not directly applicable advice; you'll have to combine design patterns you have read about, advice and code about your specific problems, good ideas of your own and endless details to write your game engine.

So my question is, could somebody point out the best design patterns to use, I was leaning on going with the factory method. Also wheres a good starting point for creating an engine, UML diagrams would help me alot if anyone knows of any that could apply to said design pattern method that could help me!
[/quote]
Maybe factory methods are going to be a valuable ingredient of your design; maybe not, and the point is learning enough about your game engine to know what you need. Think of other approaches and how each approach fits your needs (maybe with experimental prototypes), and you'll be able to make informed decisions.

You should start from a high level "shopping list" of requirements (e.g. storing certain asset types in archives so that they can be updated from the network) and use cases (e.g. when does an update take place, and what happens in case of error) and think of how each requirement could be met; it's the only way to put your design decisions in context.

A game engine isn't really used to make assets. if you're tasked with the graphics system, all you should be concerned with (IMHO) is using existing assets (meshes, textures, sharers, maybe text) and game object data (position, orientation, whatever) to draw the world and HUD

I'm quoting this for emphasis.

If the task is to make something genre-agnostic (although graphics are somewhat genre-agnostic already) then just create a graphics component that can consume data files to render a game scene. Data-driven is as wide-use as you can get. Especially when you start thinking about engines that provide a robust scripting interface (script files being just another data file to consume).

To the extent that 'design patterns' are useful at all, they are useful generally when talking about code that already exists because they give you a common vocabulary that you can expect other programmers to know covering many technical abstactions that had no "official" names before the notion of design patterns came in to prominence.

You shouldn't go out looking to use any particular pattern; but sometime in the future you may find yourself using one if you practice good design. At that point, if you need to explain the architecture of something to someone you can refer to its usage of the decorator pattern or whatever.

The requirements are quite vague, they just want us to show that we are able to create an engine which can develop multiply different games, so I'm looking for a design pattern which is as abstract as possible.

We gain more more points for having a decent working design pattern, also software functionality and technical quality

This game engine will be used to develop three game prototypes of different genres. The computer game
prototypes will be used as a vehicle to demonstrate the versatility of the game engine. Groups may create
any game type they wish, including but not limited to Role Playing Games, Motor sport racing, simulation,
first person shooter or platform. It is your responsibility to ensure that your prototype runs on your chosen
target execution platform

If you guys still require more information to assist me with my problem, I can link pretty much the entire documention
[/quote]

It seems to me that Design Patterns aren't the issue. But the flexibility of the game is. For instance, if your game should support: FPS, RPG, and Racing, then that tells me that your camera [class] should be flexible enough to handle those different views. From the start or even on the fly.

Something like (note - this is just pseudocode, pure pseudocode):
public void View (enum ViewType, int? distance, int? rotateAngle)
{
// ....stuff
}

enum ViewType
{
FPS = 0,
TPS, // third person
RPG, // above the world
}

[quote name='Xuchilbara' timestamp='1354301934' post='5005782']
I've recently been asked (in a team of 3) to create a small game engine, generic as possible. I've recently grabbed a copy of the book "Design Patterns Elements of Reuseable Object-Oriented Software". So far I'm learning alot of new design patterns, although I've NEVER used a design pattern before, or created an engine.

It's a wrong question, a bit like asking what new bricolage tools you should buy because a large hardware store just opened. The proper approach to design patterns (and design in general) is starting from a specific problem and finding a specific solution;
[/quote]

Bingo. Any time in programming when you find yourself asking the question:

What [effect] should I make with [cause]?

You're putting the cart before the horse. The best way to learn a design pattern is to read about it, implement a small (100 lines?) example, read about it again, and then leave it alone. Later when you're working on coding something you'll suddenly go, "Oh, hey! I can use [X] here!"

I've recently grabbed a copy of the book "Design Patterns Elements of Reuseable Object-Oriented Software".

I'd say a MUCH better book for learning design patterns is Head First Design Patterns. The GoF book is more of a design patterns reference. The Head First book not only teaches the patterns, but provides some guidelines for when to use them. In particular, it establishes that design patterns are not an end goal themselves, but merely a means to an end. That end being good OO principles. Understanding those principles is a prerequisite to understanding when and where to use design patterns.

So your question really should be What OO principles should I be adhering to when designing/developing my game engine?
Once you understand what those principles are, and how they influence the design of your engine, you can start thinking about what design patterns can be used to apply those principles to the development of your game engine.

Small-team + generic-as-possible = dumb.
Back to the drawing-board.

Design patterns are not even an "in sight" problem.

You shouldn't go out looking to use any particular pattern; but sometime in the future you may find yourself using one if you practice good design. At that point, if you need to explain the architecture of something to someone you can refer to its usage of the decorator pattern or whatever.

I wish I could +1 this harder, and beat lazy interviewers over the head with it.

Another +1 I guess...
As others have said, you look at it backwards. You don't force your problem into any particular design pattern.
You use whatever design pattern models your problem best.
And if you have done any programming, you have used some design pattern, you just didn't know it had a name.