Need UDK to mature to a Game Engine...

[ambershee]

At the end of the day however, I'd personally like to see manpower being thrown at more important tasks. An application that can read in and modify those ini files could be written by any one of the people demanding it with very little difficulty.

[XFunc_CaRteR]

At the end of the day however, I'd personally like to see manpower being thrown at more important tasks. An application that can read in and modify those ini files could be written by any one of the people demanding it with very little difficulty.

Attention to detail is the mark of the professional. If it's a small task, as you say, then there is even less excuse for it not being dealt with.

[Solid Snake]

I'd say it's a bit insulting to say that Epic don't have a professional development kit here.

However, these smaller details can be fixed up by us, the community. However, Epic may have to open up a few entry points for us to use. Unsure if and when that will happen however.

[NothAU]

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

[XFunc_CaRteR]

I'd say it's a bit insulting to say that Epic don't have a professional development kit here.

However, these smaller details can be fixed up by us, the community. However, Epic may have to open up a few entry points for us to use. Unsure if and when that will happen however.

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

Also, not sure anyone was saying they don't have a good platform - they're just pointing out issues.

Finally, yes beta is beta. But beta only becomes a truly effective gold master by people giving tough feedback such as this.

[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.

[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.

[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.

[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.

[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.

[marcus]

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

i agree with [this]

[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.

[XFunc_CaRteR]

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

[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.

[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.