Add to Collection


These are the deleted and unused items of my senior project of the Devry university GSP program . Look at my shattered ties folder for the final … Read More
These are the deleted and unused items of my senior project of the Devry university GSP program . Look at my shattered ties folder for the final completed project. Read Less
What didn't make it into our game
It's kind of funny when I think about it, 4 months went by EXTREMELY quickly yet  at the same time when I look back at all the assets that clutter my desktop and all the progressive versions of files I have it seems like I did more work then i even knew.   Then there are the things we worked on for a bit and either dropped,  heavliy remade , or didn't even get a chance to move forward with. This section is for seeing how we progressed to our Gold version of our game and how everything kind of built up to what we have now , and seeing the things we spent significant time on but ultimately had to scrap .
Our very first menu screen.... the big green button is our start game button. actually the button is originally red but I created a animation where the button turns green if the mouse is over it.......the blue block is the mouse cursor at that time....and isn't even close to it....I clearly needed to readjust the collision box for the play button. Also if you haven't noticed I COMPLETELY butchered our games title here ....even funnier when you consider I came up with the name lol. 

This was good though,  this was the first time I played with Flash, the first time I was exposed to any actionscript at all, and  the first time I really played with keyframes.
Here I began to play with the  Flash CLIK functionality. i was able to put the buttons on the screen but this thing wasn't functional at all . Also notice how clearly I haven't figured out our games' style yet by the green font at the top . still this was important because having Clik buttons was going to make programming the actual menu far easier.
This was the first text I used in the Neverwinter style, at the time the lightning seemed incredible but as the game went on to be developed Red and Black seemed to be a common theme and i kept to it. aside from everything else though  I just felt this picture looked far too busy for my own taste. My teammates allowed me full creative freedom thankfully so I got the chance to work it out myself but this is  where I would say our  current menu was  born at least in terms of ofnt usage and stye.
It took a few weeks but we finally began to resemble what we have now , however I thought maybe having a transparent background would be a good idea. before i knew how loading worked with the UDK I thought this would be fine. I think this also tells a bit about the scope of our game too. we WERE planning on having a load and save game function but time just wouldn't make that feasible. we also were going to have an options menu with various settings.  On each button  ( in the top left corner )  you can see the blocky text that occured when I tried to put labels on the buttons. Instead I made a seperate text layer. This menu was not yet functional  and as you can see it occured on a level we ended up scrapping.

a good tip a friend of mine told me was not to do a white text on a snowy background she was right it did make the title hard to see at times.
Here we began to refine everything , this menu functioned but at the time I didn't realize this menu couldn't open it's own level so to speak. basically once you designate a " menu level" in UDK every time that menu opens it opens a menu so wha happens if you reference the menu level itself oyu get stuck in a loop where your only option is to keep reloading .the main menu level itself.  by this point we all had really liked this Never winter font so we kept it.  We did not have a mouse cursor so the only way to make sure you were hovering over a specific button was to wait for the animation that changes its color to play .
I can't find the Screenshot I took of this one but it is  very similar to the above picture with black text on the button.  I had finally imade it so you could see the PC cursor on screen in UDK but I didn't think it gave the right feel .
and this is our menu in its final version. we gave up on the save game and load game function finally,  the cursor was implemented ( the floating sword ) , I added the credits so that our names would be visible without having to beat the game and I noticed that the consistent theme among our game was the red and back color so having a menu that faded from red to black was perfect and the theme music composed by George Edwards was a perfect compliment in my opinion.
Does this look familiar?  This is actually the very first screenshot I took of pleasantvlle in our first week of developement.  I spent much of the first two weeks really re-learning how to create terrain . and really getitng the process down of importing a texture and creating a material , creating a terrain material that references the material and then placing a material in a terrain layer setup.
This was our updated PleasantVille before our huge Revamp into what it is now, here I have implemented some height maps in order to create lakes and mountains.  the temple I made myself by piecing together a bunch of individual tiles, walls, and  Then placing two big blocks as the roof. You can still see some of the temple if you  turn around and look at what is surrounding the house area you begin the game in our final version of the game
This is the original snow material I made which would later be modified to make george's sandstorm effect in the Forbidden sands level.  As I stated it's based off of moving the textures over a volume, in order to give the effect of looking like actual particles are moving through space. The first two simple PNG files which are literally canvases I just paint bucketed black and created random white dots all over eventually led to this snowfall effect.
The graphic in the top-right corner represents possibly the greatest casualty of the deadlines enforced on our project.  This is our inventory indicator a simple picture displayed in the top right corner that represents the weapon the player is currently holding. this picture is a poor example of that ( lol  bad  angle ) but the other ones demonstrate it a little better. Basically what happened was I got this done and worked out all the kinks and we ran into an issue where while it would function just fine on my laptop when integrated into the main game and my partners laptop it would cause a crash. some testing let us learn it had something to do with our main characters player ID but a valid solution wasn't found in time.

Weapon Featured: Short Sword 
 Weapon Featured: Katana
 Weapon Featured: Razor Sword
 In the case of the short sword and Small axe I had to hand-erase their backgrounds after taking a screenhot of them in the  actor browser within UDK in order to make sure they were represented as cleanly as possible in the corner. the magic eraser tool helped a bit but when using it it typically didn't remove very much of the background or erased the metallic silverish parts of the weapons  as well. So in order to save me time of trying to reconstruct it I just traced my eraser tool as pixel-perfect precise as I could. 
Weapon Featured: Small Axe
 This is the logic behind our inventory indicator which took two days of intense focus by me to fully figure out and get functioning without crashing the UDK k, it may have been slightly easier with the unreal script but I already understood how to organize the logic within kismet so i chose to do it that way.
The concept itself is VERY simple, display a specific graphic when a specific weapon is equipped., However in order to make sure this is a constantly updating sequence  you have to loop the sequence back into itself which means that in the spn of a second you may have 50 instances of that picture placed of the screen which will slow down and crash the UDK.
So i made a control mechanism which is run by a few simple variables established in the beginning of the sequence. basically once the player is spawned 4 variables ( 1 for each weapon ) are initialized to 0 . After testing whether or not the player is alive the game observes which weapon is currently equipped. when a weapon is not equipped that portion of the sequence merely loops itself back to the beginning. For the weapon that is equipped it passes through a conditional statement that tests whether the initial variable is  less than 1. If it is less than 1 the  flash movie that is the weapon graphic is displayed, the variable is given a new value of 1 and cycles back to the function that tests whether or not the player is alive.
Basically on the second loop if the weapon is still selected the conditional statement will detect that the initial variable is 1 and just continue to loop itself until the weapon is changed. at which point the variable will be reset to 0 and the process will occur for a different weapon..
Each weapon has a different initial variable that is ONLY effected when the kismet sequence travels down a specific line for that weapon.
If I were to code this structure I think a simple  case statement featuring a  conditional statement that protected ,multiple instances of the video playing would suffice.