Moving a TC from ut3 to UDK

[TOP-Proto]

Hi guys, i just wanted to check the correct way to do this.

Previously i was using the -mod= switch which kept my code/configs/assets separate from UTGame.

From what im looking at now, do we get our own folder structure still or do we now replace the contents of UTGame with our mod code?

obviously before the UDK replacing anything in UTGame was a big huge no-no for a total conversion.

sorry if this is vague, i followed the samples on the UDN site and got the example gametype to build great, and wanted to make sure that the action i take on porting my UT3 Total Conversion mod into the UDK is correct.

[parkar]

Yea, the -mod stuff shouldn't be needed (if it even works in UDK). The final game you cook and build will install as it's own game with it's own folders.

[Havoc89]

Anyone have a clue as to how to set this up? I was looking through The Ball, and it seem to be just like UT3's installation folder.

[elmuerte]

It can be a lot of work. You'll get it quite some trouble if you rely a lot on UT3 content. A while ago I was trying to port Jailbreak to the UDK (as a test) and it was quite some work because Jailbreak relies a lot on the UT3 content. So the less content you use, the better off you are. Most of the missing UT3 script stuff can be recreated.
One thing that will require quite some attention is AI code that relies a lot of path nodes. This has changed a lot in UDK, if you do special path node processing you will have to rewrite/update most of it.
Other things you will need to take care off are config variables and localization, you can no longer use the mod method by specifying it in the defaultproperties, you have to create the files for that.

And another very important thing, make sure you have all the source art assets, or at least uncooked content. You can not reuse cooked packages.

[Havoc89]

But how does one setup their own sort of game folder where you can have an editor with the custom TC loaded content and what not? I'm searching on UDN however I cant find anything about that.

[Soldier of Light]

I've been looking for the exact same thing. I've been able to get UDK to compile (and I'm assuming it would run as well) using the -DEFENGINEINI=..\..\YourGame\Config\DefaultGame.ini or something along those lines.

But I am looking for a way to actually CHANGE the default ini that UDK uses. I want my project in a different folder from UTGame.

[Sir_Brizz]

I would imagine most people do, however it appears that UDK is tightly bound to the UTGame folder presently. Hopefully this changes soon.

[erwilly]

As far as I kwon the folder name is inside of the exe file. Anyway the name of the folder is trivial.

[Soldier of Light]

Game Name

The default game name is "Example" which means by default the engine will look for its configuration files in the ExampleGame\Config folder. You can either change the global =GGameName= variable in Core.cpp or use the new -game=MyGame command line option to explicitly specify the game name and hence the path the engine uses to look for .inis.

D:\Development\UnrealEngine3\Binaries> unreal -game=MyGame

The above tells the engine to set GGameName to MyGame and use MyGameGame\Config as the configuration folder. Please keep in mind that this option also applies to "UnrealEd" and "ucc" so in order to compile MyGame's script files you will need to invoke "ucc" with "ucc make -game=MyGame".

It is suggested that updating Core.cpp's GGameName with your game name or codename and use -game=demo to invoke the sample content after you are far enough along to not rely on Epic's content.

According to the UDN, the GGameName variable hardcoded into the engine determines the directory the engine uses. Additionally... the -game= flag doesn't work, it still is overwritten by the -DEFENGINEINI flag which is also hardcoded into the engine. So it appears the only way to change the game name is to supply a commandline -defengineini= flag that points to your game's directory.

[lcizzle]

Steve Polge

Rename your map files to have udk instead of ut3 extensions. You can put all un-cooked content in the utgame\content directory, or add a new paths entry in the [Core.System] of UTEngine.ini (in utgame\config) to point to the directory containing your content. Since your packaged mod will include only the content cooked into your maps and compiled scripts, it isn't necessary to keep them separated during development from UT content except for your own organizational purposes.


This should answer your question.

Just use \UTGame and when you cook your project whatever assets aren't used will not be included.

[Havoc89]

So we are just putting all our mod files in the UTGame folder? What if we have more then one projects?

[Angel_Mapper]

Separate installs would be best for that. You can make your own subfolders inside UTGame, but you'd have to change your ini files for each of your games.

[Havoc89]

Can someone explain how to actually go about setting up the engine so that you can work with it? By that I mean what is the exact folder structure, and where exactly does everything go, and what exactly needs to be done with the ini files and what not. Is there a detailed tutorial on this by any chance?

So far from my experimenting, it seems to be very different from how you go about setting up a TC mod for UT3.

[Soldier of Light]

The whole point of the UDK is to be able to make your own games... UTGame is Unreal Tournament. Yeah you can erase all the starting files and put your own content in there, but it would seem silly to ship a game that's labeled as Unreal Tournament.

[Mangopork]

Hmm, seems interesting.

From what I Understand the scripts ought to port over just fine, at the very least.

[LennardF1989]

The whole point of the UDK is to be able to make your own games... UTGame is Unreal Tournament. Yeah you can erase all the starting files and put your own content in there, but it would seem silly to ship a game that's labeled as Unreal Tournament.
Digging up an old thread here, but it is possible by changing only 6 bytes in the UDK.exe, too bad it counts as reverse engineering, which is against the EULA.

Perhaps Epic can supply us a repacker for UDK.exe to have its own icon and patch the 6 bytes for us ;)

I also made a launcher for UT3 once which did this without physically patching the file, but I'm unsure if it counts as reverse engineering. Can someone give me an official statement on this? I tried getting it on the mod mailing list numerous of times, but no-one ever replied.

@Epic: I'm always reachable for help on this.

[Gr33nN1nj4]

I know this isn't the same, but you can make a batch file that is stored in the top level folder (the one with the Binaries, Development, UTGame, etc in it) that calls UDK.exe with the proper command line switches and just use http://download.cnet.com/Bat-To-Exe-Converter/3000-2069_4-10555897.html to convert it to a exe file.

[Jade-Phoenix]

Separate installs would be best for that. You can make your own subfolders inside UTGame, but you'd have to change your ini files for each of your games.

(leonardo)*HUGS* you're here! Good info/advice as always btw. Thank you for that.

[twoflyingpigs]

I'm also using batch file for multiple projects setup.
Here's one my simple bat file:


cd UTGame\Config
del ut*.ini
del DefaultGame.ini
del DefaultEngineUDK.ini
copy DefaultGame-MyGame1.ini DefaultGame.ini
copy DefaultEngineUDK-MyGame1.ini DefaultEngineUDK.ini
C:\UDK\UDK-2009-11-BETA\Binaries\UDK.exe editor -log


DefaultGame/Engine-xxx.ini will be project-specified.

[lordofduct]

I'm sorry, but that all seems bizarely asinine.

Why is it hard tagged to the UTGame directory. The way UDK is portrayed is being an Unreal Engine modifier, not a UT mod. Bloating up and sorting around all the UT stuff, that's a pain in the butt, and any dev'r who isn't disgruntled by it must already be one cluttered individual.

I'm sorry, but I like organization, everything has its place. I mean, OOP follows that same organizational concept!

I guess I have to keep digging around and playing with this, there has got to me more to this or something. I just don't get how 'Rein' says this isn't "watered down", ummm, that right screams watered down.

[Angel_Mapper]

I really, REALLY don't understand people's problem with it. The developer is going to be the ONLY ONE THAT NOTICES OR CARES that things have a UT prefix, do you really think it's going to matter to the end user at all? Honestly? As the project lead of Prometheus, this "problem" never even entered my mind, and Hourences would probably say the same thing about The Ball.

[lordofduct]

why?

because it puts you in the position of building off of Unreal Tournament, not building from the engine up.

This is supposed to be a "Unreal Development Kit" not an "Unreal Tournament Mod Kit".




Speaking of, does anyone know of a where I can figure out how to strip out the DefaultConfig files and everything. Essentially how to I set up these config files so that when you run the game it doesn't jump into the UT menu and instead into my own thing, instead of having to do the whole command prompt thing.

[Angel_Mapper]

You can turn the UDK into an RPG, an RTS, side scroller, racing game, puzzle game, point and click adventure... tell me again how you're "building off of Unreal Tournament"? Change the map references in the [URL] section of DefaultEngine.ini to your own front end map and viola, you've just bypassed the entire UT demo.

I swear you people would complain about having to decorate a free house because you wanted to build it from the foundation up. :p

[immortius]

I think semantics is perhaps the worst reason to make a whole bunch of work for yourself.

[freshcut]

never a truer word spoken immortius

[photex]

But what about versioning?

The current way UDK is distributed and the way we are required to create projects is a bit backwards from the way you'd typically want to manage a software project where someone could be updating the foundation.
I'd really like my customizations to be better insulated from Epics releases. Because UTGame is a great reference and I don't want to muck around in there but instead pull out what I want/need and aside from that I generally really want to easily take advantage of the updates they are making available.

How are you guys handling this?

[immortius]

SVN Vendor branches (http://svnbook.red-bean.com/en/1.1/ch07s05.html) is one technique for managing this sort of thing. At the very least it lets you keep track of what is being changed with each version.

Also avoid changing any supplied packages if possible.

[Angel_Mapper]

But what about versioning?

The current way UDK is distributed and the way we are required to create projects is a bit backwards from the way you'd typically want to manage a software project where someone could be updating the foundation.
I'd really like my customizations to be better insulated from Epics releases. Because UTGame is a great reference and I don't want to muck around in there but instead pull out what I want/need and aside from that I generally really want to easily take advantage of the updates they are making available.

How are you guys handling this?I keep all of my script files in their own SRC folder, as well as keeping my content in its own folder, in UTGame\Content\Prometheus. For ini files I use ConTEXT's file compare feature to transfer my changes. The whole process takes maybe five minutes to get up and running with a new UDK release.

[Shelke]

Hello :) if what you want is to have your folder outside UTGame, you should be able to do that by editing the default engine ini.

this is inside the default engine ini.
+Paths=..\..\UTGame\Content
+Paths=..\..\UTGame\__Trashcan
+LocalizationPaths=..\..\UTGame\Localization
+SeekFreePCPaths=..\..\UTGame\CookedPC
+SeekFreePCPaths=..\..\UTGame\Content

you should be able to add a path outside like this:
+Paths=..\..\MyGame

this will point outside the UTGame folder.

I currently add this line for my folder for editing and don't use the mod version:
+EditPackages=UTGame
+EditPackages=TestGame <- this line
;ModEditPackages=MyMod

The folder is outside UTGame, in UDK\TestGame.

I havent created any new content for the january beta so i cant fully confirm this. but I have used the folder outside UTGame with past betas just fine. though, I have not cooked the game.

[TOP-Proto]

But what about versioning?

The current way UDK is distributed and the way we are required to create projects is a bit backwards from the way you'd typically want to manage a software project where someone could be updating the foundation.
I'd really like my customizations to be better insulated from Epics releases. Because UTGame is a great reference and I don't want to muck around in there but instead pull out what I want/need and aside from that I generally really want to easily take advantage of the updates they are making available.

How are you guys handling this?

i would recommend you dont rely on any of the example code, just in case it gets changed. If you use anything from UTGame itself, it might be best to keep that in your source, as UTGame is an example game built on top of the game engine source. Theirs nothing to stop epic updating the example game to show off newer technologies in the future.

[TOP-Proto]

Hello :) if what you want is to have your folder outside UTGame, you should be able to do that by editing the default engine ini.

this is inside the default engine ini.
+Paths=..\..\UTGame\Content
+Paths=..\..\UTGame\__Trashcan
+LocalizationPaths=..\..\UTGame\Localization
+SeekFreePCPaths=..\..\UTGame\CookedPC
+SeekFreePCPaths=..\..\UTGame\Content

you should be able to add a path outside like this:
+Paths=..\..\MyGame

this will point outside the UTGame folder.

I currently add this line for my folder for editing and don't use the mod version:
+EditPackages=UTGame
+EditPackages=TestGame <- this line
;ModEditPackages=MyMod

The folder is outside UTGame, in UDK\TestGame.

I havent created any new content for the january beta so i cant fully confirm this. but I have used the folder outside UTGame with past betas just fine. though, I have not cooked the game.

currently we keep our own folderstructure under UTGame\Content\MyModContent\...subfolders

Any content we add goes under that folder, but the config directory still look a mess! :P

Gonna look at the above that i quoted though.

[immortius]

i would recommend you dont rely on any of the example code, just in case it gets changed. If you use anything from UTGame itself, it might be best to keep that in your source, as UTGame is an example game built on top of the game engine source. Theirs nothing to stop epic updating the example game to show off newer technologies in the future.

UTGame isn't just an example game though, at least at this stage. Some engine features are only accessible though it. In the future what you say may be true, but at this stage people have to use UTGame for those features.

UTGame is just as much a part of the development kit as anything and the sooner people get over the fact it starts with the letters UT the better.

[Shelke]

UTGame isn't just an example game though, at least at this stage. Some engine features are only accessible though it. In the future what you say may be true, but at this stage people have to use UTGame for those features.

UTGame is just as much a part of the development kit as anything and the sooner people get over the fact it starts with the letters UT the better.

I read the january beta release notes, and it seems Epic is moving native UT code back to script code and re-generalising the engine interfaces. and this, however, seem to be breaking things people where relaying on.

From the release notes:


ongoing UTGame de-nativization

* Moving UTGame specific C++ functionality that didn't need to be in C++ back into UnrealScript
* This makes it easier for UDK developers to see how we implemented this functionality, and has also resulted in new engine functionality being exposed to script.
o Notable examples include the new SVehicle physics interface functions and making it possible to tick skeletal controllers and UTUIScenes in script.

This process will most likely continue to break a thing here and there for the coming betas. but eventualy allow more control over the engine from script :)

In the Epic coding examples I have seen, they always used non UT specific classes. this was probably planned.

[Blade[UG]]

Be nice if the changelogs were a lot more specific.. there were a whole bunch of class deletes/adds this time.

[photex]

Ok, so given what I've read. I'm taking the entire install and checking it into perforce:
//UDK/2010-01/...

Then I branch to my game depot:
//MYGAME/...

When there is another update I'll pop it into the //UDK depot and merge if needed/wanted into the //MYGAME.

In //MYGAME/.. I'm modifying UTGame/Config/Default*.ini to make sure that where ever possible content is picked up from MYGame/Content first, scripts are compiled into MYGame/Scripts and so on. This way anything that I do will take place in MYGame. Under Development/Src I have a MYGame module where my code is going.
Now, ideally, when there is an update it can be branched without any effort beyond merging the config files in UTGame/Config and updating the script modules in Development/Src.

Sound about right?