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!
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.