In my final quarter at my college, I need to have three completed games in my portfolio to graduate. While I am working on a rather large project that takes up most of my time, I decided that to fulfill this requirement I would make two really simple games. I present to you the first of those two games: Jump or Die. Jump Or Die is a very, very simple side-scrolling ‘platformer’ built with the ridiculously robust UDK. Sure, UDK is complete overkill for a game like this but because I’ve spent the majority of my recent time in UnrealScript, I felt it would be fastest for me to make it with UDK. Even for a very simple game like this, I’ve still had my share of problems that I had to work through and learned far more than I intended, as this was supposed to be a 2-day game max. The odd little quirks that had to be overcome to make this is a discussion for another day, and so now here is info about the actual game.
Jump Or Die
You are a blue box racing for your life.
You must jump over everything in your way and reach the end.
Tap the screen to jump, tap and hold in order to jump higher and further.
Available in English, French, German, Italian, and Chinese
So for the past 3-4 months I’ve been working as Lead Programmer for Emotional Robots, Inc on UDK-based game Warm Gun.
Its a post apocalyptic post World War 3 Old Wild West + a bit of steam punk multi-player shooter.
We need you to vote for us for the Indie of the Year 2010 award at IndieDB.com! At the time of this writing we are rank 27 out of 2,661. Just a few more ranks and we can be listed on the front page as one of the popular games!
It only takes one click to vote, however if you’re extra nice you’ll register/login an account as registered account votes weigh more than guest votes. Also, there can only be one guest vote every three minutes so if it is saying you can’t vote, just watch our trailer as someone just voted right before you did! Each person can only vote once though, so tell you’re friends and family! Please!
Yesterday I spent most of my day eating pizza and working on Warm Gun over at Emotional Robots, Inc., but I managed to put a little time in this morning to this side project.
Day 4 (11/21/2010)
9. Setting Up Basic Interaction Logic From Mouse To Towers
While our towers are just shell Pawns that aren’t doing much, before I give them more functionality I wanted to tackle how the player is going to interact with the unbuilt towers so that they can build their own. The first step is getting some sort of simple detection going on that would let the towers know if they were currently the target for the players mouse and then to figure out if the player was within an ‘interaction radius’ with the tower. Doing so, the player will only be able to interact with tower building zones when their Pawn is close enough to the tower, causing the player to have to run to wherever they want to place their towers for a bit of a fun challenge. If this proves to not be fun, I can just either increase the interact range greatly or remove it all together. Also, I wanted this detection logic to be able to be applied to any actor I choose instead of having every actor derive from an interaction actor. To do this, we have to use an interface. Interfaces are kind of like sub classes, but they list a series of functions and delegates (no local variables) that each class using it must implement. To implement an interface, you just use the keyword ‘implements’ in your class declaration. More information about interfaces can be found on the UDN page.
The interface is really simple for now, it has a function that returns what type of interaction it is, functions to show/stop showing the player that the object is interactable, and then finally an actual interact function.
Now that I got the camera set up yesterday and played a lot of Vindictus, its time to get back to work. The next step is to get the player to aim towards where their mouse instead of in the direction the player camera is facing. This way movement and aim will be separated and allow for interaction with the world with the freedom of rotation but locking movement to the camera axis. Basically, the player will be controlled like most top-down shooters. Now for this project I am currently using the September build of UDK even though the October build is out as this project is also meant to help some classmates with their project which is currently September based. The reason I bring this up is that the October build of UDK strips out all UIScene functionality completely and everything related to it and in the past the class UIRoot was my primary way of accessing mouse coordinates. This means that for my project to not need a major reworking in the future I would have to find a new way to grab mouse coordinates. Now I looked all over the UDK development code and I could not find a straightforward way to do so. If there is a easier way than the process that I went to that I will go over, please let me know. The way I did it relies on a SWF to store mouse coordinates which then UnrealScript grabs. Its a little odd but it works flawlessly once set up correctly. I figured that if I used ScaleForm to grab mouse coordinates, Epic won’t be scrapping ScaleForm any time soon.
The first thing we are going to need to do is to replace the UT HUD with our own ScaleForm based HUD. As fancy as the UT HUD is, I’d rather have my own. Also, I need to create mouse coordinate functionality without relying on the old hud’s Canvas to use DeProject, which I’ll get into later. For now, I don’t need anything fancy in my HUD except a mouse cursor which will indicate where the player is aiming and will also serve as a cursor for UI interaction with HUD menus and things. Time to start up Flash and build me a HUD. I am using a trial version of Flash CS5 at the moment.
With Flash CS5, I have already set up my ScaleForm extension and my ActionScript settings. If you have not dealt with ScaleForm and Flash before, I strongly encourage checking out my ScaleForm series here. With my new flash document open, I went ahead and drew myself a cursor with the flash tools, and this is what I came up with:
Parallax Occlusion basically makes shadowy parts where you expect shadowy parts on objects, but with parallax. The wall that you see is a piece of completely flat bsp.
Alright, my fellow student game development team “Team Forecourse” just mailed our submission off to the Indie Game Challenge! Heres hoping we get somewhere…
But as per submission, we were required to do a 60 second ‘pitch’ video. Its amazing how short 60 seconds really is, the video was hastely done to get it sent in time so there is a bit of an aburpt ending but hopefully later we’ll be able to smooth that out in the future. Watch it, and enjoy!
First media update for Plastic Warfare, a student game project under development by Team Forecourse! Whoooo! Here is a rough cut of a fly through of our Gold Mine level by Alex Merz.
The first rough fly through of Gold Mine, a level designed and built by Team Forecourse’s Lead Level Designer Alex Merz, with Creative Director Cordell Felix and Producer Michael Allar and the rest of Team Forecourse. Built in UDK for the game Plastic Warfare.
Camera picked up some weird post process interpolation times, will be revised in the next cut. Also in need of some basic video editing.
Two fellow classmates of mine, Greg Canada and Sean Moallem at The Art Institute of Orange County have produced a cool tribute to Day of Defeat’s Avalanche created with UDK, thought you guys should check them out and hopefully drop them both an e-mail inspiring to do more awesome work!
