Need UDK to mature to a Game Engine...

[Blade[UG]]

Comparing UDK to Unity is like comparing a Ferrari to a Focus. Sure, ok, maybe you can figure it out because you're not a programmer. Now, try to get a programmer to figure something out. Your favorite toolset was written on Macs, by Mac users, for Mac Users.

[Solid Snake]

The problem is that writing a project management program that you'd probably only use once per project simply isn't worth the time effort involved for the benefit you get out of it.

In this case, having to alter the ini files is a trivial task for a human to do. Opening up an ini file, look for the appropriate variable line you need to alter and then adding the changes.

While an application can exist to do this task for you, the time it takes to write an application is probably going to be much more than you'd expect. Also the actual gain from it so minimal that there is little point.

About the UTGame directory; this is also another trivial matter. Borderlands has "WillowGame" and a few other Unreal based games often have "project nameGame". Does this actually matter at all? Do users even care? There is quite a bit of change involved with changing that directory name actually, and the changes involve a recompile of the engine. It may seem trivial to you, but like most things ... the devil is in the details.

What Epic doing now is more sane and beneficial to developers in that they are patching the engine for stability, usability and extending its feature set. After all, what would you rather have? A neat program you'd use only once to start up a new project or a new feature?

[UnspoiledWalnut]

The GameCreators.com... full game development tools for ten year olds. What do you expect for fifty dollars? I've used some of their stuff that wasn't too bad given how cheap it is, the X-Quad editor is kinda fun to use.

[MasonThird]

I don't know how to say this, but I think current versions of UDK is more like a Mod Kit than a full fledged Game Engine. Because,

1. It has no Project Manager. We have to manually edit ini strings to get our things running. Which looks & feels more of a Mod Kit than a Professional Game Engine.

2. Why do we have a use UTGame Folder in our Games? If Epic is charging 25% for the released Games, it should make UDK to have more features of a Professional Game Engine than that of a Mod Kit for UT3.

etc etc..

There are a lot of features currently in UDK which dictates that we are using a Mod Kit. I & many of us here in the forums would like Epic to transform UDK into a more mature Game Engine in the coming days.

At least that's what i am looking forward to.

I believe that you should start playing with 3D Game Maker and FPS Creator...

[NothAU]

I'm not suggesting the UDK doesn't get improved, infact earlier on in the thread I said I'd be all for a Project Manager.

It's been stated that it's not a necessity, no reason for a Developer vs Designer war to start up

[BigDaz]

That wasn't said, merely that you shouldn't expect everything to be handed to you on a diamond-encrusted 24 carat gold platter.

Well that's the point, noone's demanding anything on a gold platter. It's really odd the way any suggestion for improvement is met with such hostility as if they've demanded the moon on a stick. There seems to be a lot of confusion between plain speaking and a demanding attitude. I'm sure a lot of it is because English isn't a first language for quite a few people.

[NothAU]

I'm sorry... I guess UDK is fine as it is now and needs no changes or improvement.

That wasn't said, merely that you shouldn't expect everything to be handed to you on a diamond-encrusted 24 carat gold platter.

[XFunc_CaRteR]

I'm sorry... I guess UDK is fine as it is now and needs no changes or improvement.

[ambershee]

This is arrogant. Game design is not programming. Don't confuse game design with a production skill. Programming is just a means to it. In fact the less need to do it, the more non-programmer types (they are involved in game development) will be invited in, and the more diversity there will be in games that are made in the future.

No, this is arrogant; game design is not game development, it is only one aspect of it. UDK is a platform for the latter and the tools are catering towards development as a whole, not as a tool for 'designers' to build upon and ignore the other important aspects of the development process.

More to the point, editing a few ini files has nothing to do with programmers in particular, anyone can do it and it's not difficult - especially as (and has been mentioned before) the process of setting up a project is well documented and takes less than ten minutes to achieve.

There are, by the way, game designers who aren't programmers. They are researchers, mechanics and balance designers. I designed a pretty big serious game about disaster response and the programmers were just f*cking lost without me doing the subject-matter research with the client and writing the design doc so they (the programmers) could then interpret it in code.

Whilst that may often be the case, historically the majority of employed game designers and often producers come from either a programming or otherwise similarily technical background (other instances sometimes coming from the art side of games, but this is less common). Even without that background, I'd be worried if the designer I am relying on to relay the details of implementation to me as a programmer lacked the competance to deal with a small part of the technical side of things.

But this evades the central issue, which is that fundamentally an application handles stuff like this. This is exactly what Unity does. It arranges this stuff in a front-end interface. Making a "point" that we "should" be able to handle this stuff is lack of attention to detail. It's making excuses.

The application in question is called notepad. It's not a lack of attention to detail, it's an unwillingness to 'fix' something that was never an issue in the first place (except for you it seems). The ini files exist as they are because it provides individual users with more flexibility about how they manage their installs. Case in example, most developers here would use a single installation for each individual project, especially where they may have specific unusual needs within the configuration management; whereas in my own case I manage multiple projects within a single installation in order to share libraries and assets between them more easily. Having some sort of magic front end cater for everyone's differing needs is not easy.

[marcus]

One thing you seem to miss: Beta Beta is Beta.

i agree with [this]

[XFunc_CaRteR]

Or more bluntly, any group that is unable to deal with ini files without some sort of integrated tool has no hope of programming anything and thus lack the ability to make a game in the first place.

Game design is not programming. Don't confuse game design with a production skill. Programming is just a means to it. In fact the less need to do it, the more non-programmer types (they are involved in game development) will be invited in, and the more diversity there will be in games that are made in the future.

There are, by the way, game designers who aren't programmers. They are researchers, mechanics and balance designers. I designed a pretty big serious game about disaster response and the programmers were just f*cking lost without me doing the subject-matter research with the client and writing the design doc so they (the programmers) could then interpret it in code.

But this evades the central issue, which is that fundamentally an application handles stuff like this. This is exactly what Unity does. It arranges this stuff in a front-end interface. Making a "point" that we "should" be able to handle this stuff is lack of attention to detail. It's making excuses.

[ambershee]

^ This. Ini editing is trivial and involves little more than opening up a file in a text editor. Writing an application to put the ini data into ordered pages isn't impossible, in fact it's quite easy. It is also however extremely time consuming, and needs to be updated every time UDK is updated, so there's also a lot of potentially time consuming maintainance to be dealt with on top of that.

Finally, when you start creating a large number of config files with custom settings for yourself, and you more than likely will, it is also not possible for this editor to magically pick up on them; how is it supposed to know what ranges of values your config might take? You're back to editing the ini files by hand again anyway.

In all reality, it's very easy (and well documented) on how to start a new project in UDK, it takes less than ten minutes. Compared to some other "professional" game engines with five and six digit price tags, it can be a walk in the park, without having to have a programmer doss about with project files and manifests.

[immortius]

That's a dumb attitude toward product improvement.

Basically the original poster is saying why are you making us futz around with these stupid minor files instead of integrating them into a full app-like solution that handles this stuff in the background. We are here to design games, not mess around with configurations.

An application should be designed for the user. If this was Photoshop and it required artists to futz about with ini files then you would have a point. But this is UDK, and it has to be acknowledged that any development group needs to have at least some programming ability in it. A little ini file configuration is something that any half-decent programmer should be able to deal with easily.

Or more bluntly, any group that is unable to deal with ini files without some sort of integrated tool has no hope of programming anything and thus lack the ability to make a game in the first place.

While some sort of ini management tool may be nice, it is neither necessary or even highly desirable. It is a trivial nice-to-have.

[Solid Snake]

For a 25% slice of whatever a developer's game makes, Epic - not the community - better be doing the work to improve their platform.

Yet, they're giving you a 850k (probably more) engine and toolset.

[Blade[UG]]

I suppose while we're doing this, I will point out that there are many things that, imo, need to be changed, to really be able to do some more things with this setup.

The position of where audio is being listened from needs to be able to be seperated from the camera position.

The point where things are determined "relevant" to a client needs to be seperated from the position of the player's .. pawn? controller? not sure which one is used there... but there definitely needs to be a way (other than setting everything in your game to bAlwaysRelevant) to deal with relevancy for non-fps games

Need a lot better control over positional audio.