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
Here is an update to ForecouseUI and changes go the CLIK classes that I have done to make the current version of ForecourseUI to work. This currently works for the July build as I have not migrated to August but I will migrate to September once its out so expect a new ForecourseUI update then as well.
The unreal code is not in this file so you must download the original ForecourseUI files to install the unreal side of things.
This video is of me posting the update, because I realized after I started recording that I was too tired to do a how-to implementation. Sorry.
So I’ve learned some more about Class Attributes, before I was just using [Serialization()] but in order to customize the way the WinForm PropertyGrid control works, there are some nifty attributes you can tie your code to.
Can now change how the texture previews are rendered through the use of a property grid. Not much of a feat, but, I’m proud of it.
Over the past month or so I haven’t really had time to update my blog due to lots of stuff that went down that I had to deal with and that I haven’t had time to develop anything regarding Forecourse… but now I’m back. Once again, I will try to remain constant with my updates.
Right now I am focusing on the Forecourse Content Creation Tool, named ForeCreation. It is (will be) a XNA-In-WinForms IDE, allowing the creation of assets that will follow Forecourse standardizations so that they can be used with any Forecourse driven application with ease.
I know its not much of a milestone, but this is my first time really dealing with WinForms, first time dealing with XNA outside of the XNA Game class, and the first time I had to deal with handling the reading/writing of custom data formats for use with an editor, and well, a lot of firsts. It is quite the learning experience and is going quite slow but I am getting there. My little ‘yay I did it’ milestone at the moment (which is pretty inferior code that could be done by a real programmer with utmost ease…) is the ability to programatically create tab pages that contain XNA renderers within. My first implementation of this is a ‘texture preview’ of textures inside the GameDataTextures folder of your project. It is more detailed in this video:
I will post all the info I can about Project Forecourse as soon as this is done.
Currently I am in the process of refactoring my Project Forecourse’s code so that, well, a bunch of things could happen.
The first and main reason is so that all my code is more readable and programmer-friendly. Also, I have decided to break down main components into C# .NET .DLL’s, which will allow me or anyone to use a certain component of Forecourse without having to disable/modify a lot of code, and so that anyone who just wants to start making stuff with XNA can have all the base grunt work already done for them. My main focus on Forecourse at the moment is all code dealing with UI, as it is really hard to make a functionable game without some UI present. I am making this code (ForeGUI.dll) not dependent on XNA at all, so that the UI logic can be used with other projects without rewritting. To use this .DLL though, you must shell out basic functions to wrap a few of my GUI functions, but that is it. I will also be providing working example wrapper code so that you may rewrap the dll to best fit with your project. And the last major reason is so that I can get people working with me in XNA sooner and easier than before, as my previous code was pretty daunting.
