Team Arguments

I think the skills of the programmer might make or break the project if you wanna go the procedural way.

I'm also not aware how you're going to proceduarally make a level in UDK... (It's built and baked, can't move BSP around can you? Unless you export them as a mesh?)

So then you might as well go with static meshes made in an external 3D package and at this point it doesn't matter what engine you use. Personally I'd advise using Unity... And perhaps use some tools for BSP like features like probuilder if you really need it.

UDK seems user friendly at first but it's immensively more complex under the hood for a project like this (students?) Unity would likely create less headaches if you have decent coder support, you can just focus on building what you want.

So I'll repeat, go with what the programmer wants. As a LD you'll just have to work around it but knowing that the coder can support the tools to make things work from a technical standpoint should make you go a long way.

Maybe Nexus Pericolos0 is able to give further advice, given that he is working on a procedural FPS in Unity and knows both middlewares.

Yeh Unity sounds like the best option here. Though I can understand the Level Designer. Unity doesn't have a SDK like any other engine which makes it a lot harder to get into. But in the end you have a lot more freedom to do whatever you want. Also creating tools for Unity is fairly easy for a coder. Aand the best of all V for vertex snapping is just epic

When the dungeons are randomly created what exactly is the point of a level designer on the project? Sounds more like the job for an artist to create the rooms. So for an artists it shouldn't really matter which engine to use. He will spent most his time in other tools. I would go with what the programmer feels more comfortable with.

Phoenixx157 you should see the bright side that you get experience in two different engines/toolsets. It will help your CV when you apply for a job.

Quote from Steppenwolf

When the dungeons are randomly created what exactly is the point of a level designer on the project? Sounds more like the job for an artist to create the rooms. So for an artists it shouldn't really matter which engine to use. He will spent most his time in other tools. I would go with what the programmer feels more comfortable with.

Phoenixx157 you should see the bright side that you get experience in two different engines/toolsets. It will help your CV when you apply for a job.

Not necessarily, they can split the tasks : artist modeling only items, props, walls, etc, and LD making prefabs with those meshes to create several portion of rooms.

I also think that unity, seing the features, would fit better for a small team like you have. Unity is easier to use and do not request a lot of knowledge of the software : importing objects, settings project, materials, etc is way easier to accomplish.

And just to say : i did my last year project under UDK with 17 guys, that was fun, but it was also painful for our programers to learn Uscript instead of using C++.

modular sections would still have to be created in a way that yield the best gameplay possible.

This thread came at an opportune time for me, as I've been struggling with the same choice for a bit. Unity seems the most flexible, and I'm learning C# anyway so that's convenient. I'm also going for a procedurally generated game, if I manage to get this thing off the ground.

Then again, I'm just an armchair game designer at this point. A 3D game might be a bit ambitious for my first project. What do you guys think?

personally i think 3d games are easier to do than 2d unless you have an engine optimized for 2d (such as flixel or similar). i'd much rather just have 3d environments then make the camera just avoid one dimension entirely. it creates a few problems along the way (such as players not being visible at all times), but these are neglible compared to how fast you can get this up and running.

there are also some 2d frameworks for unity out there that look good and simple, though i can't say i've ever tried them out.

like i said before, unity is very good for scripting and prototyping in C#, probably the best one can ask for - especially as a designer. however, without tools like probuilder you'll be hard pressed to get 3d environments working in a manageable way. if you choose UDK you'd have to do the entire scripting in kismet, but the editor would be built in and everything would be workable out of the box. unity is completely barebone out of the box, by contrast.

Haxe doesn't interface with UDK or Unity. It's C++ export is more for dealing with desktop apps made in NME. I suppose you could try to mesh it with the c++ UDK that will come eventually but that seems more difficult than just programming in c++ in the first place.

For a small project that students are going to create, then go for the engine that the programmer feels the most comfortable working with. Its way easier to create something in c# than it is in c++, so I can understand your programmer. And if you compare the two as level design tools then udk is more advanced out of the box, but theres so many 3rd party solutions for unity that you'd be silly to discount it on that basis alone.

i agree with making the programmer happy.

yea make me the programmer j/k, but seriously they are so cute and cuddly why wouldn't you want to make them happy

One thing hasn't been said: all the great stuff that UDK provides is gonna be stuff that a small indie team new to the tools are not even going to use. Subtract Unity features from UDK features and you are left with heaps of wiz-bang that you don't need and don't understand.

Quote from Sentura

i recognize this discussion. it's not one i've had with anyone, but it's definitely one i've had in my head lining out the pros and cons. i've used both engines professionally. i'll flat out say that scripting in unity may be the best thing ever, provided you don't need someone to hold your hand (as in kismet)

Please explain to me, what is wrong with Kismet, or why you think it is a hand-holder? I think it is intended for one-time or level-specific stuff, prototypes, and linking together different systems quickly like in a set-piece. Scripts that take trivial memory/cycles. Then there's UnrealScript (proprietary is sad) which is meant for highly complex stuff, game wide scripts, scripts that get called often. More complicated stuff that's compiled and more optimized.

I really like node editors because you can see everything all at once, organize, and they are easier to learn for everyone.

Because if you want to do e.g. logical puzzles kismet and its wiring will make extremely complex what would otherwise be a simple nested if statement. its presentation leaves much to be desired, and i much prefer using C# to using kismet (i'd do it everywhere if i could). the hand holding part is that it is set up so that pretty much everyone can use it from the get go. there's a ton of premade options that make it easy for anyone without previous programming experience to just go in and rig up a simple system. on the other hand, if you need something more complex to happen out of your code, kismet will obstruct this since it will not always have the necessary components exposed. So if you at some point need something specific that kismet won't be able to do, you need to ask a programmer to expose it in the underlying layer. C# trumps this entirely by letting you control what you need exposed and what not.

And don't even get me started on UnrealScript. So glad they got rid of it for UE4

Yea I understand you. Those webs can get really tangled. On the other extreme something like a button to open a door I'd find needing to write code obtuse. That's one thing that's better to have than not I think, and for many types of games having it simplifies the making process. For many types of games I can't see why you would use zero kismet if it's available. I look at it like materials, I prefer nodal materials/shaders to parm lists any day. So for you do you ever miss it in Unity?

i disagree. a button for opening a door could be done in a few lines of code, and it would omit matinee as well (which i personally think is a hassle to work with for entities that are prefabbed - such as doors, buttons etc.). pretty much all gameplay related scripting would be so much better if there at least was the code alternative to kismet that wouldn't crap out memory leaks or give programmers additional hassle.

the material editor is kismet just for materials, and it creates the exact same pro/con dynamic. HLSL trumps it, but for those not experienced with shader languages, it is clearly an easier choice to work with. there might be a little less options in general when working shaders, which is why it would probably fare better in the grand scheme of all things presentable.

i don't work in Unity currently, but I would probably not miss it as I'm neither a technical artist nor a 3D modeler. I do level design.

My problem with scripting levels with a text script is it quickly becomes very abstract and hard to follow when you’re doing a lot of very-similar-but-not-enough-to-encapsulate activities like unit spawning. Part of the elegance of Kismet is the way you can switch between the editor entities and the script itself.

Kismet’s problems are largely due to people trying to do too much with it. I’ve been on projects where half the game logic sits in Kismet as this Lovecraftian sprawl of boxes and lines that causes insanity if you gaze upon it for too long. Or where the attitude is “we don’t need a those coders for this! Scripter power! We can combine matinee and vectors and maths and oh god what have we done.” On projects where coders and scripters are working together, and sprawl is eliminated with custom nodes, what you get is very streamlined and readable.

text scripting is hard to follow, just like genuine programming is. the point is, much like kismet attempts to do, to make it presentable enough that everyone understands it. there's a variety of tools out there created explicitly for this purpose, and there is a reason for why text editors haven't been taken over by flow chart box scripting... yet.

kismet wouldn't be so bad if the underlying layer would be exposed in a simple language that you could work, so that you could charge classes and variables on a whim. buuuuuut still, i prefer text editors =)

I agree 100% with Taylor, with flexibility comes responsibility. Complex kismets are fine for prototyping but that's where it should end - otherwise you end up with 10 people doing exactly the same thing 10 different ways. Many will break over time, the experience becomes inconsistent and solutions become exponentially more expensive to solve.

Back in my day, this used to do the trick.

This->C_SetStateMachine( mobstercombat );

This->C_SetStateMachine( delay1s );

This->C_SetIdle(1, false);

This->A_Play3DSound(enemy, mobster_alert,head);

Quote from Sentura

personally i think 3d games are easier to do than 2d unless you have an engine optimized for 2d (such as flixel or similar). i'd much rather just have 3d environments then make the camera just avoid one dimension entirely. it creates a few problems along the way (such as players not being visible at all times), but these are neglible compared to how fast you can get this up and running.

there are also some 2d frameworks for unity out there that look good and simple, though i can't say i've ever tried them out.

like i said before, unity is very good for scripting and prototyping in C#, probably the best one can ask for - especially as a designer. however, without tools like probuilder you'll be hard pressed to get 3d environments working in a manageable way. if you choose UDK you'd have to do the entire scripting in kismet, but the editor would be built in and everything would be workable out of the box. unity is completely barebone out of the box, by contrast.

Actually, I've got the 2D engine thing covered, Construct 2 is currently "collecting dust" on my harddrive. Probably wouldn't use a 3D engine like Unity for 2D unless I was making a 2.5D game.

I might need a reality check, my head is in the clouds. Better start simple before I go for the 3D "dream game". Too bad Construct doesn't support traditional programming to the same extent, at least Unity would let me exercise my C# outside a schooling environment.

Sorry for the hijack