Tuesday, May 7, 2013

Perforce

As I stated in my last post I am currently starting to work on a 3d game with the Unreal Development Kit. Obviously when working with such a system version control is a must. They recommend to use perforce, which I thought was a pain to setup, so I thought I'd write down how I did it in case others need some help.

First of all, the reason why they suggest to use perforce instead of svn, git, etc is because UDK files are binary. That means there is no such thing as merging, rebasing, branching, etc. With perforce, when you check out a file, you lock it. This means no one else can work on it while you have it checked out which obviously prevents any possibility of having to merge, which in the case of a binary file doesn't exist.

For my repository, I found assembla which offers free, private perforce repositories. This was perfect for me so I created one according to the directions and it was up in a matter of minutes.

Then, I installed both the perforce command line and visual clients from the perforce clients page. You only really need the command line client but I'm a visual person so I prefer to use the visual client when I check-out and check-in my files.

Once you have the command line client installed, you need to make a config file. The instructions on this page were adequate enough to get me going. This config files makes perforce recognize what files you would like to be candidates for version control. Though, where you put the p4config.txt and your workspace names are very important and that's what was messing me up. For example, my install of UDK is C:\UDK\UDK-2013-02\... What this means is that if I want all of UDK to be available to perforce, I needed to put my p4config.txt in C:\ and my workspace name is UDK. It then put two and two together to say, aha, you want to be able to use files from C:\UDK for perforce huh? Gotcha.

Once that was finally setup correctly, the next few things I did were trivial. I had my simple level that I wanted to added so I navigated to it on my Workspace tab in p4v. Then right-click, Mark For Add. Then when I wanted to put it online, in the Files tab I right-click, Submit with my commit message.

Now that this file is in perforce, before you start to edit it you need to check it out. So again I found the file, right-click, Checkout. Do my edits, and then re-submit it.

Again, this actually isn't too bad it's just the fact of where to put the p4config.txt file and the name of the workspace you input are very sensitive.

I hope this helps anyone else that has troubles setting up perforce.

Shift of Focus

So I haven't had a post in a while and there's some reason to that. These past few weeks instead of messing around with side programming projects I have been dabbling in trying to create my own 3d video game. A video game you say? Yes. The reason is because last summer I worked on a simple 2d shooter that had good intentions but was not followed through properly. Though this time I am determined to make this playable in a 3d world. I would love to post more about the game other than it's a 3d fps, but that's all I can say for now. Anyways, the list of technologies I'm now using has taken quite a long time to figure out and use properly which is the real reason for such a long break between posts.

Originally I was planning on sticking with java for this 3d game and using jMonkeyEngine, but that just didn't seem right. I've been following the development of that open source project on and off for a couple of years and even though it has made great strides, I still feel that some of the other tools out there will just be easier for me to pick up and learn right away. The major problem I didn't like versus some of the other candidates was just the fact everything was still programmed. An example of getting a simple textured box to appear in the screen can be done in the following form:

 Box b = new Box(Vector3f.ZERO, 1, 1, 1); // create cube shape at the origin  
 Geometry geom = new Geometry("Box", b); // create cube geometry from the shape  
 Material mat = new Material(assetManager, "Common/MatDefs/Misc/Unshaded.j3md"); // create a simple material  
 mat.setColor("Color", ColorRGBA.Blue);  // set color of material to blue  
 geom.setMaterial(mat);          // set the cube's material  
 rootNode.attachChild(geom);       // make the cube appear in the scene  
I really wanted to just draw a box on the screen and apply a texture which is why I chose not to go with jMonkeyEngine.

So, I started to look commercially for products and found the following 3 that I did some investigation on:

After some evaluation, I have decided to work with UDK. The main reason was just the options of the free vs paid versions. With UDK, you get all the features to design a full game, minus the source code. Then, if you want to commercialize your game, you have two options:
  • Pay $99 and you get 100% of first $50k and then 75% thereafter
  • Buy full commercial license to get source code and 100% of revenue (price not listed)
The reason why I felt this was a better option was due to the fact that with both CryENGINE and Unity 3d seemed to remove some features on the free versions. This meant that even if I never sold the game and wanted to use all of the features, I would have to buy a license.

Though enough about my investigations, on to UDK. This software is pretty damn impressive. Right now I have been following the 3D Buzz tutorials and with each video I finish my impression of the software just gets better and better. Some of the more notable features I've stumbled upon are:
  • Light Lag Information - It can show you where you have too many lights on a surface and potential graphics lag.
  • Apply Materials - Applying materials to various surfaces is as easy as drag-and-drop. And on top of that, if something is off, you can just tell it to auto-correct the layout of the materials and they re-adjust to properly align with one another.
  • Kismet - I've only just begun with the Kismet scripting language but it's really cool. I used it to slide a gate back and forth based on a player's proximity to it. I just told Kismet where the gate will start/stop, how long the animation should go, and if I want any sounds. All of this was drag-and-drop as well. No manual programming to get a moving gate, how cool is that?
So, that's what I've been up to lately. I have completed my first simple level and would like to post a video walk-through of it. Actually, I can setup UDK to record a video walk-through but I haven't gotten that far in the tutorials yet so hopefully I figure it out soon and post a video.