3rd Year University Game Looking for a Programmer Thread

Hello Everyone! ThatDreamGame is made up of 4 Third Year Game Designers. We're making a game as part of our final year and would love the help of a programmer.

The Game

Our game basically revolves around a young girl, who falls into her own dreams and into her own worlds..
During the game we're aiming for alot of use of colour to interpret whether she is in control of the dream or not. (Colour if its 'safe' Greyscale if it's not)
It will be a 3rd person platformer made in UDK, where she can use various abilities to interact and outwit her environment, avoid enemies and traverse her world until she gets to the end.

What we're looking for,

A Programmer/programmers who are interested in our idea and who would like the opportunity to work with us. We need the following:

• A 3rd Person Camera which purely following our main character.
• The ability to traverse on walls/ceilings (Think of Escher) when in our main characters changed form. (Spider) We've been told this is possible as a previous year had a fantastic programmer who used a 'sticky material' that could be applied to certain walls to make it possible. We want this to happen only when our character is a spider, not whenever there's a certain material.
• Being able to program different abilities for our character to use; such as, changing from one model to another, jump, dodge, a Dash attack to stun enemies. (Sonics Jump/Dash & Dante's Trickster Dash) Etc.
• Basic AI paths for enemies.
• Health/Damage System.

We are all Designers and new to UDK and Kismet Scripting, if possible we will do as much of this as we can. We're aiming for a polished little demo to show in GameCity next year in Nottingham like the year previous. Any help given will be appreciated and you will be fully credited.

Here's Some Concepts:

Main Character Progression. Tweaking Model, almost there.

Concepts of Abilites and Actions in Demo.

Please post or get in contact if you're interested! Thanks
TDG.

I think you may be over-estimating how much work a programmer can achieve in a very limited time span. It's not impossible, but it sounds like you have some grand ideas.

ThatDreamGame wrote: The ability to traverse on walls/ceilings (Think of Escher) when in our main characters changed form. (Spider) We've been told this is possible as a previous year had a fantastic programmer who used a 'sticky material' that could be applied to certain walls to make it possible. We want this to happen only when our character is a spider, not whenever there's a certain material.

They probably used PHYS_Spider. It has been deprecated and is no longer functional in current versions of UDK.

It was possible for our graduates to traverse over ceilings/walls using a 'sticky material' I asked them last week and they said a programmer can alter the material, and make it sticky so it was possible to climb it and hang upside-down.
We just want to apply this material to the feet of one of our models not to the terrain itself.

And we would like more than 1 programmer to help if possible. We have a few solid months to go which is why we're asking for help now.

Thank you
If you do know anyone that would be able to help us, could you point them in our direction please? We'd be really grateful and they'd be fully credited

What game design course is this? It would be more than likely there are local programming students in similar situations.

ThatDreamGame wrote: I asked them last week and they said a programmer can alter the material, and make it sticky so it was possible to climb it and hang upside-down.
We just want to apply this material to the feet of one of our models not to the terrain itself.

You don't understand - I am a programmer and have done this before myself with various results, also in UDK. Functionality that was commonly used to make this type of behaviour happen is no longer in UDK. I'm not saying it is impossible, because it isn't, but it is by no means an easy task, which is why I am trying to dissuade it.

The 'sticky material' would have just been a flag (a true or false value) inside the material itself or something very similar and so is trivial - the real code would have been in the player and would have been entirely math and geometry driven; the player just knows that when it is standing on a sticky material that it will need to orientate itself to that surface (this brings a large slew of technical challenges in itself).

The Programmers in our year and University dont use UDK or unreal scripting, they use Unity.
This mechanic is important to our game, we know it wont be easy and dont expect it to be but its not something we can dismiss from the original idea.

For the record, the Unity version probably works in much the same way with the flag and movement setup, but the physics engines driving the two and the level of access you have renders implementation of the actual movement setup very different.

ThatDreamGame wrote: The Programmers in our year and University dont use UDK or unreal scripting, they use Unity.

Then I would suggest that it makes the most practical sense to use Unity; it is probably more in your interests to finish the project than use the alternative engine for whatever reason you have chosen.

ThatDreamGame wrote: This mechanic is important to our game, we know it wont be easy and dont expect it to be but its not something we can dismiss from the original idea.

I'm trying to dissuade you for your own beneft - not because I have anything to gain from this, but because I have strong first hand knowledge of how difficult it is to implement this kind of functionality, and am pretty certain there is a high likelihood that you will not succeed in your goals. I'd rather see a finished prototype using different tools or a different set of game mechanics than a project that has collapsed underneath the difficulty in reaching its goals.

If you still insist on treading this path, I'd advise you do some research: this mechanic has been attempted with varying levels of success since the release of Unreal Tournament 3 back in 2007 (and a lot of the research those authors attempted, including their code is available) - but has never been proved to have been implemented reasonably well. The vast majority of implementations, including all the successful ones, used something called PHYS_Spider - a physics 'mode' for objects that included the background physics math in order to assist you in gluing the player to a surface (more specifically, transitioning between surfaces) - that mode is no longer completely functional in UDK (and may potentially be completely missing in recent builds, builds earlier than September will iniclude it but not the missing functionality). Other implementations that appear to work are actually often abusing the mathematical properties of spheres to simplify their solutions.

Yeah but the programmers arent very willing to help us this year.

We're still going for the main 3rd person platformer feeling, with her jumping, dodging, stunning, traversing within the broken environment to reach the 'end of the level' but during this she will pick up abilities. We have: Glide, temporary Defensive shield, temporary offensive attack to throw back the enemy AI, and a spider-like ability where she would traverse the environment in a different way and even shooting a web to form a temporary block from enemy AI from chasing her (there is no combat, she has to use what she has in the environment or her own abilities to keep them out of her way)

We had to pretty much design a fully realised game but only actually build a very tight, polished section to show off for next year. We'll need at least one ability to show off and assumed that would be the most interesting to see (and since its been possible before to re-create again) Obviously not the case anymore. We still need more than her jumping, dodging, dashing etc in our demo to really sell the idea since we're aiming for GameCity next year. Even if its her shooting webs at them to slow them down..

Colour is another important aspect of the game, as the levels are greyscale if she is being attacked, and turn to colour once its clear. We were told again this was possible to trigger in UDK.

In sad conclusion (since we do want a polished demo) we'll have to drop the traversing walls from our build. But still need the fluid movement, colour trigger, clever platforming, AI, 3rd person camera that actually works, and her basic abilities. Even if we could get that dash attack to work fluidly and successfully it would still be satisfying to play.

Disappointing but Thanks for making us aware. Any ideas?

A large part of your 'fluidity' will come from animation. I recommend looking into moving your character via root motion outside of your basic movement and making use of procedural (partially programmed) skeletal controls where possible. The anim-tree is your friend.

Thanks for the advice. We'll still need a programmer for things like 3rd person cam, health/damage system..etc.. So wish us luck (:

Still no one free to help us out on the basics? ):