im new to UDK(steam question)

[adminatron]

hello, im new to UDK and really havent tried working on any sort of game creation(besides rpg maker when i was like 12) and abusing the **** outta starcrafts mapedit. that aside, I'm still relatively familiar with the concepts behind programming - it all just comes down to knowing commands and syntax and ofcourse the proper application.(and often most resource efficient application)

while I dont know any languages to date(heck i probably cant even whip together an html these days) I have started the buzz3d tutorials and have already had a little fun with kismet... on the simple level tutorial he shows you how to make the door open on the trigger zone and close when you leave it and I've instead began experimenting with platform elements(as that is the game I'll be making) so i instead took a pillar and made it .3 scaled on the Z axis(fatty mwuahaha) and moved both the trigger zone AND the interp in matinee, and set it so that it goes back and forth while you are ontop of it - but it pauses when you jump off(or just jump up) which is pretty sweet cause i havent had to learn an ounce of unreal script yet... WOO



now the two questions I've got right now are in the vein of networking... in the game I'd like to create I need to know 2 things, one related to steam and the other related more or less to UDK(though might concern steam aswell)

the non steam question:

how many concurrent users can I have in the same enviroment? or rather - how many are supported natively by the engine, without calling in middleware or the likes... I'm going to be making a very unique take on an MMORPG - which luckily is alot easier to make than your typical MMOrpg, but it begs to question can I actually make it an MMO;

basically what I'm wondering - is wether it is feasible to have "world
zones with up to 50-100 players running around in it? I wouldnt be ashamed if I had to create instanced "channels" of each zone to limit players to maybe a max of 25 players in a small map if i had to - but wether I keep zones extremely small or large and open really depends on wether Unreal is capable of handling that many users on a map without exploding - or handling client/server communications in an external app(i.e. middleware)





2nd question.

whats with the steamworks integration... It seems like it would be cool - but does this mean if i were to make an MMO you would have to login via a steam account... and if so - is there a particular way I need to write my expressions? i.e. local variables vs global - or does unreal's engine assume when you say player that it's client side local for the triggered event, wereas the event itself is 'server side'?

aside from that, I've been diving deep into these tutorials and I'm excited to make my game...

p.s. inb4zomgucantmakeandmmoragequitnow.

seriously though, I'm not interested in a "before you make an mmo, you should make x game and be prepared to spend x amount of time for x result" because I've been around the subject on numerous occasions due to my friends always wanted to make one - and I was always stuck doing the art + modelling, so between that and the research I know what it WOULD take to make your standard "MMORPG" but I havent set out to create that anyways... I'd prefer keeping the actual nature of the game seperate from your typical assumptions of what makes an MMORPG(besides the key components of having a large persistant world in a role playing enviroment)

RAAAEG. <--- that was my future response to anyone who doesnt read the "inb4"



all and all - this is a pretty ridiculous introduction, but alas, hellow UDK community... I am Kyle.

[musilowski]

Welcome to the community Kyle.

Well the MMO concept is as efficient as you make it. Out of the box UDK supports maximally 64 players per level/server. So you could make the world instanced with channeling of players to different zones. 64 players in this situation means 64 clients connected to a game server, and a single server runs a single game level (unless I have understood the system horribly wrong).

It doesn't matter how many AI controlled objects you have in your level, but they too can clog up the network.

Steamworks integration is not the only solution. You can craft your own back-end for managing server lists and such. You could ask some more about the Steam system at Steam's community. For technical UDK+Steam things you can head over to the programming section here. Can't remember if any good documentation regarding Steamworks is available yet at UDN (documentation link at the top of the page).

[Blade[UG]]

Steam provides server listing capabilities as well as achievements and other fun stuff like that. You don't have to use it.

[adminatron]

so i suppose

so i suppose it's not exactly important to worry about steam's connectivity, as i dont want player hosted servers - only dungeons...(world maps, towns, and pvp grounds would need official hosting) one of the more important parts is going to be wether or not i can spawn cameras for each player that logs in/loads in a level and it can point towards him... and wether i need to use specific targets/variables to handle local vs global stats

[Blade[UG]]

Not sure exactly what you're asking, but you should be able to do just about anything you can imagine.

[musilowski]

Have you read the UDN documentation on Unrealscript and network coding (replication, client-server management, etc.)?

[orgevo]

Seriously though, I'm not interested in a "before you make an mmo, you should make x game and be prepared to spend x amount of time for x result" because I've been around the subject on numerous occasions due to my friends always wanted to make one - and I was always stuck doing the art + modelling, so between that and the research I know what it WOULD take to make your standard "MMORPG" but I havent set out to create that anyways... I'd prefer keeping the actual nature of the game seperate from your typical assumptions of what makes an MMORPG(besides the key components of having a large persistant world in a role playing enviroment)

RAAAEG. <--- that was my future response to anyone who doesnt read the "inb4"

Well, not trying to flame or troll or anything here, but there's a pretty good reason why that's the response you were expecting. I don't know if you got this response yourself when asking others, or if you've just read enough forums to know that it would be, but as the old adage goes, you have to crawl before you can walk.

You don't know jack about replication in Unreal, right now. Of course, that will change as you practice and learn, so not really a big deal in and of itself, provided you are reasonably intelligent. Programming gameplay for an environment where (even if we stick to your low estimate) 25 players are able to interact, would require mastery of Unreal replication - even if they're all just walking around buying stuff or dancing naked on top of mailboxes. (No, really.)

If you do really want to make that game, start with a less ambitious replication challenge. Not saying give it up; I'm saying if you're serious about it, then the most efficient way to get there is accept that you are not a replication ninja yet, and write a new weapon class from scratch. This can be almost an impossible task for someone unfamiliar with Unreal replication, by itself....but it sounds like you're not afraid to get your hands dirty.

Make sure that the weapon works correctly (and working correctly means that it actually hits where it's being aimed, sound effects are being played, firing animations are performed, firing effects are being creating, hit impact effects are appearing, and physics is correct) in each of the following situations:
- when used by you in an instant action match
- when you observe a bot using it in an instant action match.
- when used by you while hosting a listen server
- when used by you while the client in a listen server
- when you observe the host of a listen server use it
- when you observe the other clients in the listen server's match use the weapon
- when you are a client on a dedicated server
- when you observe other clients of a dedicated server use it.
- when you observe a bot using it on a listen server
- when you observe a bot using it on a dedicated server
- I could keep going, there are easily 6 more permutations to go, before we even get into relevancy and how that will affect your weapon in this persistent world state.


Hope that helps