The engine we're using is commercial middleware, used in current and next-generation games by big-name studios such as Bethseda (sry about the namedrop, just wanted to clarify that this is Closed Source stuff).
The college only has an educational license, which means I can use the engine for non-commercial projects which meet the terms of the NDA, it also means I don't have access to the full sourcecode - just the headers and binaries (the school actually does have access to the full source, but the students do not).
The NDA precludes us from disseminating their sourcecode and binaries, but not from discussing techniques (or reimplementing them from the ground up).

At the end of the year, I will get what I give - if I just do the bare minimum I will have learned to use an engine that I am no longer licensed to use in any way... but if I take the time to implement my own versions of any relevant / interesting techniques then I will have the makings of a commercially viable and up to date engine which I could in theory license in competition to theirs, or use to create next-gen games in competition with their customers.
Also I'll have learned the intricacies and nuances of some of these techniques, and which pitfalls to avoid in my own implementations, all of which I am free to discuss :)



Posted on 2011-03-04 18:41:33 by Homer
It's not exactly rocket science though.
In most cases, nVidia or AMD (well no, mostly nVidia, lol) will already have discussed the techniques and provided working examples with sourcecode long before they show up in any commercial engine.
The last time a game developer did something 'new', was with Doom 3's shadowvolumes, I suppose. The algorithm commonly referred to as Carmack's Reverse. Ironically enough, Carmack disclosed this technique years before Doom 3 finally was released. By that time, most competitors were already using his idea, and stencil shadow techniques were already on their way out, since newer hardware made shadowmapping feasible. Far Cry, although it was released before Doom 3, already used a combination of shadowvolumes and shadowmapping.

The industry just has changed a lot. It's no longer a few bright young minds working 'out of their garage', so to speak. It's a big commercial game now. Most game developers have never written an engine in their lives. They just license other people's stuff. The few companies that still write their own engines (most notably ID, CryTek and Epic), focus on consoles more and more, so cutting-edge graphics techniques aren't really their focus.
Engine-wise, nothing has really happened since Crysis was released in 2007. Most competitors are still trying to catch up to that landmark.

Even so, you'd be surprised at how much stuff was already invented in the 70s and early 80s, but didn't make it into games until decades later. Shadowmapping, shadow volumes, environment mapping... that sort of stuff has been around for ages. It just wasn't suitable for realtime in games use until hardware accelerators became a commodity.
Posted on 2011-03-05 03:15:33 by Scali
Homer: ah, OK, the engine-related stuff is NDA - that's fair enough. I thought that it covered the stuff you've been taught, the shaders and other code you've written, etc.
Posted on 2011-03-08 04:26:01 by f0dder
Fluid dynamics was interesting, I'd never thought about using 'heatmaps' for guiding AI behaviors.
Now we're covering some 'boring' stuff like culling techniques - nothing new here.
Last friday was the deadline for our first group-oriented project: I helped to build an 'alien temple' themed tech demo consisting of three connected rooms and a bunch of special effects (procedural lightning was my contribution here). We ran out of time to get physics completely implemented and ended up attaching the camera to a spline which carried you around the scenery (forced translation), with a 'free mouselook' (6DOF camera orientation).
I'll post a few screen shots when I get home tonight :)

Posted on 2011-03-17 20:49:49 by Homer
Screenshots kthx?
Posted on 2011-03-20 05:14:32 by Scali
hum, bad file limits
Posted on 2011-04-01 07:51:15 by Homer
The second project is underway as of today.
It will be loosely based on street fighter, except with 'more 3d feel', there will be uber animated gladiators, there will be AI, there will be pathfinding, there will be networking. We've now covered physics and bone animation, and the artists are creating models based on the theme 'god of' - :D:D
Posted on 2011-04-01 08:01:02 by Homer
Here is a dodgy closeup of my procedural lightning , you can see clues as to how it was constructed.
It was a rush job, and anyway, at some distance, and updating once every (other) frame, and especially had it had the bloom shader applied that was written for it ... oh well.



Posted on 2011-04-01 09:03:37 by Homer

by giving lectures to those who are having higher qualifications u are unknowingly formalizing your skills if im not wrong :-p

Posted on 2011-04-01 10:02:14 by nmm00
I have no formal qualifications in programming for desktops and game consoles.
My qualifications are for dead/dying arts :)
Experience is something I have.
Posted on 2011-04-01 10:10:24 by Homer
looks like a very thrilling game
Posted on 2011-04-04 06:02:33 by nmm00
Sneak peek at a character from the upcoming Group Project #2 - Heathen Wars
Attachments:
Posted on 2011-05-13 03:19:21 by Homer
"Heathen Wars" is a great title at any rate :)
Posted on 2011-05-13 04:55:22 by Scali
Haha, possibly because I had no say in the name :P

The artists were given an assignment: create your own "god of X" themed character, rig it, animate it with a specific set of animations.
The programmers were randomly grouped with artists, and told to create a tech demo that implements AI pathfinding (obstacle avoidance) and features some kind of animated battle.

I loudly declared that it was obviously going to be a street fighter clone, in 3D, then I pushed hard to convince the team that we should make a full blown game, with networking. It can be lame, it can have no sound, but I wanted to be among the first students to actually create a working game this year, and as it stands, well, the submission date is Tomorrow.
We only just got the models moving around yesterday lol!

The project will be delivered on time :)
Networking is provided by RakNet using Reliable UDP.
Game is built on Gamebryo (you probably noticed the gamebryo asset viewer app title bar) - its using a DX11/10/9 rendering scheme, however its completely portable to linux, xbox, playstation 2&3, and wii.
I'll post a few screen shots once I get the final art tomorrow (talk about last minute huh) .
Posted on 2011-05-19 03:36:25 by Homer
Networking is provided by RakNet using Reliable UDP.
I know an oxymoron when I see one :P

How much of TCP does that end up re-implementing?
Posted on 2011-05-19 11:50:42 by f0dder

How much of TCP does that end up re-implementing?


200%... it is twice as reliable!
Posted on 2011-05-19 12:14:08 by SpooK
Actually, there are different levels of reliability, this is not the RUDP thing.. you can specify, per packet, your desired level of reliability, which is lovely. RakNet also supports a packet-dropping and out-of-order simulation where you can specify how crap the virtual network is during testing, sweet!

What is not so sweet is the price, at 15k for a humble indie license.
I mean, I have full source, why would I pay for features I don't use? Thanks, I will roll my own.

My own current engine's networking component is based on the one I wrote with Biterider for ObjAsm... except this one is made on top of BOOST, which means I can take it away from the Windows platform ;) In fact, it also provides my game engine with multitasking courtesy of its worker thread pool and the posting of arbitrary tasks to a work queue.
I'm happy to admit that I will take what can from RakNet and run with it, because I have no intention of entering into commercial competition with that product, it will always do more than my stuff does, and you know what? I am ok with that :)

I am actually convinced that it's worth rolling your own reliability layer on top of UDP, I have seen enough timing diagrams to know that it can be just as reliable, involves less data transfer due to lower overheads, and can infact take advantage of TCP's collision avoidance mechanism, by squeezing into smaller 'holes' in the packet stream, not just of the local network, but at every hop along the way.
Literally, TCP users will be forced to re-transmit, while the UDP packets will be given priority at each router.

I believe the typical router logic is something along the lines of:
if its a tcp packet, and the tcp buffer is full,  drop it, else, buffer it.
if its a udp packet, and the tcp buffer is full, drop it, else, process it.
if theres any time left, process a packet from the tcp buffer

:D

Unless its one of those two dollar PLC's, in which case, the UDP probably gets dumped.

Routers recognize that tcp can be buffered without harm (the stream is not time-critical), and that tcp has a mechanism for requesting retransmissions, and unless pressed, will let udp have the wire.

Posted on 2011-05-20 04:44:30 by Homer

Have now covered all kinds of AI related stuff, including a quite interesting thing called a Behavior Tree.
These contain nodes that implement the kinds of logical operations we would find in most programming languages: loops, conditional execution, etc.
We can construct a tree which produces the same output that a hardcoded software behavior would, but ours is a lot more flexible: since its based on a data tree, we can create more complex behaviors by using simpler ones as building blocks.

I find these things to be extremely interesting since they represent a real-world implementation of the kind of point and click programming that I've always secretly dreaded and longed for.

Posted on 2011-06-07 20:00:32 by Homer
I almost feel like I've stopped learning, the technical stuff is all behind me.
Now it's all industry-specific tools, asset pipelines, design documents and pitches.
The rest of the year will be spent developing games :)

I checked out a local gathering known as IGDAM, turned out to be a bit of an industry and fringe dweller beer gathering, a monthly event. A local game company spilled the beans on its finances. Interesting :) Nice decor (100 years of different peeling paint colors), I'll be back.

Thursday I'll be pitching a game for real, to industry guys.
It involves a medieval castle occupied by human defenders, and under siege by an army of bipedal bovines armed with siege weapons including 'cattlepults', and with an artistic style based on 1950s Disney.
Posted on 2011-06-24 04:16:02 by Homer
I'm working on a medieval Jousting game lol.
Really not my thing.
At least I get to do the physics :)
Posted on 2011-08-18 04:43:13 by Homer