Discussion: What does SL need to be a decent platform for gaming?

Well with 1.2 on its way it becomes more and more obvious that the Lindens are trying to make SL a great entertainment medium for creators and consumers alike. So I wanted to get some discussion going on exactly what it would take to make SL a good gaming platform. Now I know that you can already play games within SL but what I am really talking about is attracting users that would sign up for SL specifically for gaming and really no other reason. Personally I feel that SL as a gaming platform leaves a lot to be desired. And I don’t want anyone to think that by saying that I am in any way belittling SL, it is quite an amazing accomplishment. However in terms of a gaming consumer we are a bit too constrained in terms of our ability to produce viable content.

SL wasn’t designed for any specific gametype and truth be told it really wasn’t designed to be a gaming platform, so to expect it to perform as silky smooth as unreal or to allow creations as complex as civilization, is I think unreasonable. But it can do much better I believe. So I wanted to gather opinions about what people think is absolutely essential before SL can cross the line and become a decent (not great) gaming platform.

Here is my list (in no particular order) of what I think SL needs to achieve this goal:

1. HUD control/2D function library – We need some way to make decent non 3d graphical representations of in-game mechanisms. Yes a lot of this can be done intelligently in 3D but to really shine in terms of user interface an updating HUD is absolutely essential I think.

2. Programmable User Interface – This goes along with HUD control, but we really need the ability to launch and control our own 2d windows that contain game specific data. The 1.2 update includes a popup window which I think is a great first step. Being able to launch 2d windows with variable and dynamically updateable graphics and text (hypertext??)Would open up an incredible amount of content options for us creators.

3. Key binding – This may be an area that I just haven’t played enough with but I think the ability to bind any key to in-game functions is essential. Currently I know that you can bind the movement control keys to certain actions but if I wanted a player to hit ‘I’ to open his/her inventory there really is no way to do that (that I know of).

4. Avatar Primitives/Mesh Imports – The ability to use an avatar as a primitive (maybe it would count as 50 primitives in terms of prim usage) I think is essential to get to the next level in terms of graphics. An alternative might be to allow the upload of meshes and to scale the primitive cost for them based on the number of triangles they consume. But mesh imports would very limited use if you couldn’t also import some sort of bone based animation. Unfortunatly allowing meshes, thier associated texture maps and keyframe animation uploads would probably horriably complicate the fairly simple system that currently exists.

5. Persistent Database Storage – The ability to load and save game state I think is essential for modern gamming. In a multiplayer environment access to indexed data would allow creators to construct more complicated gametypes.

6. Client-Side advance Caching – In games where graphical representation can be critical to success or failure (within the game) dynamic loading of image content may not be acceptable. Allowing game consumers to preload (and possibly set aside some of their home computer resources for it) the graphical content will allow content creators to be unconstrained in terms of their games artwork.

Well that’s my opinion of what I think we need. And that’s not saying that we couldn’t create very entertaining gaming content without these things. But I think to attract the true gaming content consumer (and I would guess that most of SL’s current residents are more concerned with game producing than consuming if they are interested in gaming at all) you will need at least a few of these.

I am curious what others think.

Ves

A big one for me that you haven't mentioned: seamless handoffs between sims. Right now, you either need to limit your game to a single sim, or risk problems every time you cross a sim border. This is a major difficulty with races: of the five race heats I've been in, I've experienced failed handoffs twice.

1. UI features, largely as described above. Controllable through the ingame scripting features.

2. Object -> Object instant messages that are as reliable and fast as llMessageLinked only for non linked objects and accross sim boundaries.

3. More script memory, better handling of existing script memory. Large scripts (lots of code) will have stack heap collisions with 6k+ free memory reported. Either the reporter is broken or the system is.

4. User created and maintained databases. Perhaps accessable via a key (like objects), able to create fields and add entries, retrieve entries, perform basic queries. Doesn't need to be "advanced" - a flat table would be more than sufficient. And using the dataserver() event would be expected.

- key llCreateTable(list columHeaders)
Returns the key for the dataserver event to be triggered whent the table is created, the key of the table is passed in as the string data in the dataserver event.

etc. Slightly cumbersome yes, but extremely powerful if done right. Even if you can only get a row of comma seperated values at a time.

I'm not sure SL is supposed to be a gaming platform... every way its been designed just screams 'social sim' rather than 'game engine'.

If you really wanna make games, I suggest using a game engine, rather than a social sim - they will work better, for every reason.

Vesuvias,

Great thread!

And I agree lots with your suggestions!!!

Only yesterday I sent an email to a Linden representative asking for a HUD and the ability to capture any key in the control event!

I didnt add the bit about avatar primitives, but I was thinking it!!

Ama, I agree totally with the object to object direct communication at llMessageLinked speeds! This is really important for security, and performance is a nice side-effect.

I'd add to this a whole load of anti-exploitation stuff:

- ability to limit pushobject on your land, eg totally disable it, or limit it so you can only pushobject your own objects
- ability to prevent people dragging objects around on your property: both from outside your land, and dragging their own objects within your land
- ability to limit which scripts are allowed to run on your land
- ability to limit which objects are allowed on your land

Concretely, some examples of why this is important:

1. Imagine I have a Donkey Kong game (hypothetically like). I set it up on my land, and lets say it gets really serious, everyone wants to get the best time to the top, or just get to the top.

The game is: barrels roll down a ramp, and you have to get to the top of the ramp without touching a barrel.

Someone comes along in the dead of night, and here's all the ways they can exploit:

- create an objectpusher object that pushes all the barrels into the next sim, no more barrels -> easy life
- rez an object right in front of the barrel spawn point. No more barrels -> ...
- drag an object into your no-rez land, and place it right in front of the barrel spawn point. No more barrels -> ...

(Note: this game actually exists, and it was exploited in exactly these ways).

2. Reconnaisance game

I set up something like a maze, you have to move around the maze and, lets say, find the gold without falling into a pit.

Exploit: run a sensor script. No longer much fun...

3. Dungeon game

I set up a dungeon, with monsters and stuff

Now, there are tons of possible exploits:

- pushobject to spin the monster around to face away from you, to isolate single monsters, to deflect projectiles, to make your projectiles homing...
- scripts to run sensor scans...
- objects rezed to block monsters...
- objects dragged in to block monsters...
- objects rezed/dragged in to make hard-to-get-to places suddenly trivial

Azelda
CombatSystems and Gaming Consultant, SL

Hierarchical link trees... This would make SO many things in game move/look a ton better and would make scripting them infinately easier.

But yeah, a 2D hud feature set would rock.

SL will never be a good platform for gaming because a good platform for gaming is client-heavy and SL is based around a "3D streaming" paradigm.
Network latency, unpredictable timing, crippled scripting language, this all makes it next to impossible to do any complex or fast-paced game in SL.
Oh... and the new v1.2 prim limits are NOT HELPING.

Eggy!!!

Well, I think SL is potentially a great platform for MMOGs.

You'll never run CounterStrike on it, but then if you want to run CounterStrike... run CounterStrike.

However, what it has in comparison to standard MMORPGs is:

- decent physics engine (no more just walking up to monsters and hitting "attack"
- the ability to mod the world

What is critical to the success of MMOGs within SL is what Mezzanine was hinting at, which is:

to what extent to MMORPGs, such as those created with the MMOG Toolkit, fit in with the vision of Linden Labs for the future of SecondLife?

If there's a Linden reading this, I'd be interested in knowing what you think?

Azelda

Az, if I wanted a MMORPG, I would have gone to EverQuest
If I wanted a racing game I would get Gran Turismo or whatever is the current trend in racers.
If I wanted an FPS I would play HL2 or Doom 3.
I've tried (and many others have) to port several different games to LSL. While they work as a geek tool or a cute parlor trick, they will never be able to compare with their real world counterparts

I believe at this time that you, Eggy, are entirely incorrect. I believe that SL has the potential to be a great development platform. LSL needs an overhaul (interface control, data structures, communication, perhaps an API for client side control of in world items/actions) but given the history of SL updates that is entirely not out of the question.

Also I am interested in MMOGs, I did play EQ and I still play SL. Why? Because I am as interested or more in making games as playing them and SL does offer that. Just because you don't want MMORPG components in SL doesn't mean others don't or that they aren't possible or can't be popular.

Just because you or others havn't been able to port a game in the past doesn't mean it won't be possible in the future. Or that other creative games, unique to SL, aren't also possible.

If it is within Linden Lab's vision of SL then it is more than possible.

While I support this thread in principle, I think we would be better served in the short term by making games that suit the unique conditions of SL rather than trying to port games from other environments. There are sure to be innovative and original games that can only be developed here and which would not work as well elsewhere, the opposite of the problem most people seem to have bringing in game ideas.

Hey all, good thread, a couple of comments, but I'd like to see you guys brainstorm without to much of our intervention.

First of all, I think it should be pretty clear that Second Life has been designed as a platform for games. The physics engine should be a pretty big clue that its not just for socializing. So we do want to see great games made, and we realize that we have some responsibility to provide you with the tools needed to make them.

Our content team has been discussing these questions, and trying to come up with a list of all the features we think we need in order to create good games, so we can put them on our xmas list to the developers. Some of the features you have discussed are already on that list, some will be added (moral of the story is to keep thinking about these things, 1000 minds might be better than 4!).

And in closing, I will echo Julian that you should keep pushing the current feature set to see what it can do. Back in the day, when I was just a liaison with a head full of dreams, I started making SLB, JetBall, and Lastertag. I wasn't very good at scripting back then, but every time I finished a game, someone would say "wow, I didn't know you could do that here!" and we played, and they were fun. (Jetball eventually got an art makeover.) When is the last time you played a massively multiplayer action sports game... with a real audience? Of course, back then, I also tried to make a hovercar racing game that didn't turn out to well - but hey, look what we got now - the featureset grows.

Oh yeah, and to all you who say "SL will never be able to compete with [insert specialized game here]." I personally will disagree with you. I say, give it some time...

Ben

don't forget each sim is a separate server, so while i'm not a techie, its been explained to me before that this is very hard to do.

JV

But even though I don't belive SL can ever be a good platform for real time games, here are the things that would make it a good platform for real time games:

1) Reduce the lag / latency to that of a regular real time game (not gunna happen)

2) Increase Framerates to responsiveness (unlikely except in maybe dedicated gaming zones)

3) Add client side prediction for movement code (a lot of trouble, unlikely for a 'sim game')

4) Increase the speed of script parsing by at least tenfold (maybe)

1 and 2 seem almost impossible in the current system.
3 seems doubley so because its a sim game, but thats the truly vital one... we need that kind of responseiveness in order to get a sim game to be an action game.
4 could eventually happen just by brute force computing power

Assuming the above occurs, it can almost become possible for actual real time action games to work

NOW as for the 'nice things' the following would be pretty useful.

1) Hud Element access via scripts. Design health bars, meters, values, tie them to variables in a script. (Warcraft3 script allows this in a limited way , but thats another world entirely).

Example: Health and armor in FPS. Gold and lumber in war3 clone... various stats in MMOPG.

2) Properly (key-frame) Animatable objects. I know I have a keyframer, but due to LSL limitations, it can only animate once every 0.2 seconds.
- Without this, there is NO WAY that SL can even remotely compete with even the most crappy MMORPG. Even the crappiest user-run mmorpg doesnt have spiders which just sort of drift across the terrain without moving their legs, or enemies in an FPS which trundle around without any kind of animation.

3) Custom avatar animations.
- goes without saying. Either that or a huge library of AV animations that could fit many roles

4) Full control over avatar capabilities. (This is probably the final nail in the coffin, since its absolutely unlikely). What I mean by this is... when you start to play a game of serious soldier warfare, debug mode becomes disabled, you aren't -allowed- to drop your stuff and pull out a Sumo gun and mess with people. Or when you're playing a RTS, you arent allowed to hop onto the RTS field and create toruses all over the enemy base.

-This final one is just another reason why SL is not, and is unlikely to ever really be a proper realtime game platform. There is too MUCH freedom for it.

But for simple parlor games, board games, perhaps chess, all the really simple things, turn based games ... it works great.

But it won't be a viable platform for action realtime games -anytime soon-

One thing that would be very useful (and not just for games), is a way to display text on the side of a prim (as opposed to creating one prim per letter, which is very wasteful). Please allow us to select fonts, sizes, etc etc. =)

Also, let us write to a notecard! Besides being an easy way to save games, its just something we've been needing for a long time for many applications.

Xylor

My ideal setup for this feature:
The scripts would be different, have a different set of available calls, marked with a different starting chars (cl for client library or something instead of linden library). There is a check box or set of radio buttons on the script window to select normal or client side script.

A client side script could require player approval before running, allow a limited number to run at a time, and have a built in UI element to view client side scripts running, their resource usage and to cancel them as wanted/needed. Client side scripts would not download from muted residents.

Client Side Scripts would be space limited, although maybe a different set of limitations than current scripts. They would persist (keep state and keep running) through client logouts and logins.

The abilities of a client side script would be the following:

1) Data handling. integers, floats, lists, strings, rotations, vectors and all the functions for manipulating them.

2) Communication. say/whisper/shout should be disabled for channel 0, but some way for these scripts to communicate with other objects in world would be needed. It could be as chat on other channels from the avatar.

3) UI. I would recommend that this be the only way to control the UI. With the features above it should be easy to disable it if needed and to see what ones are running. It would also get rid of UI lag which could be a real problem with UIs controlled from server side scripts.

4) Keyboard inputs. These scripts should be able to catch keys, any keys, and perform the needed data manipulation, UI control and communication to in-world scripts.

A client side script can not interact with the world beyond communication. No sensors, collisions, touches, physics, moveTo etc.

Such a system would really go an extremely long way to making SL a true gaming platform.

I'm very excited about the possibility of all types of games for SL in the future. Chat is nice, but games is what will attract and keep new people.

LSL is definitely limited, but there are workarounds.

All of these fast action games will eventually come, but they will take time.

Now though, we do have the tools in place for lots of types of games. I have made several board games so far, and have plans for many more. These are straightforward and basic and work really well within SL.

The thing I am most excited about though are social games. These combine the great chat functionality of SL with the fact that you are actually playing with Real people.

Spectacular.

I've been workiing on designing a long term game similar to TV's The Mole. I think this will be fantastic.

A couple of features I could really use though in the development of this type of game:

- Ability to limit someone's view "Oneironaut Escher would like to take control of your view". Force someone into mouseview. This is key for things like mazes and group puzzle challenges.

- Ability to limit someone's ability to send and receive IM's "Oneironaut Escher would like to take control of your IM's". This is key, not only for what I am working on, but for all kinds of things within SL. Most importantly, things like trivia events and contests of that nature.

- Ability to limit someone's ability to teleport. Obvious applications.


There are actually several more things I have thought of in the past, but am drawing a blank on (it's late, sue me).

The three I list above are the three that I keep coming back to, so I think the most important. These would be easy to implement. I imagine it would be just like any other permissions or whatnot, and people could Reset these permissions easily by logging and coming back in game.

I need to reiterate that these things are simple, yet Crucial for pretty much every little gaming idea that pops into my head

Mezanine wrote:

"4) Full control over avatar capabilities. (This is probably the final nail in the coffin, since its absolutely unlikely). What I mean by this is... when you start to play a game of serious soldier warfare, debug mode becomes disabled, you aren't -allowed- to drop your stuff and pull out a Sumo gun and mess with people. Or when you're playing a RTS, you arent allowed to hop onto the RTS field and create toruses all over the enemy base.

"-This final one is just another reason why SL is not, and is unlikely to ever really be a proper realtime game platform. There is too MUCH freedom for it. "

Yes, I agree this should be a number one priority right now: not adding new functionality, but locking down what we have right now.

Two possible strategies:

- lock down individually SetForce, MoveToTarget, etc... possible, but seems like a lot of work, and there will always be loopholes..., or
- have a way of excluding all scripts, objects, vehicles and attachments from one's land except those that you've explicitly approved

One possible way of implementing the second strategy is:

- provide for the creation of some kind of a Marker, that one can add to scripts and objects from the Edit window
- For each piece of land, you can choose to allow only certain Marked items. All other scripts and objects are automatically banned.

In addition:

- ability to detect or disable Debug Mode, either for an avatar (eg GetAgentInfo) or on one's land,
- ability to prevent people dragging stuff around on one's land,
- ability to prevent scripts from outside one's land from using PushObject against stuff within

Taken together, this should ensure reasonably exploit-free game.

Ben, thank-you for your reply. It is very encouraging!

Azelda

You guys keep going for it!

When I first joined SL back in Jan 03 I built a model of a 1932 Indian motorbike. Back then - it was pretty near impossible to script it so you could ride it. Actually. you couldn't even sit on it in a rider's pose.

But I always thought - someday I will be able to ride this thing.

Last night three guys were having a blast racing each other on that same bike built so long ago.
Zipping around the motorbike track out in the vehicle sim.

It was actually quite competitive - good speed - no lag and fun!

Thanks to all the great coders and Lindens for an ever improving world where dreams do come true.

Sinatra

p.s. if anybody ever wants to race me - bring it on!

Ama, I wholeheartedly agree with your second post. It should be possible to run stuff on the client, even if it meant that games would be single player and no data was ever sent to the server from our "LSL plugins". It would still allow us to run scripts at a decent speed, comparable to modern programming languages. I've proposed it myself on another forum here.
With regards to your first post, I acknowledge that I am not the best scripter in SL, but if you truly believe that any sort of interesting game can ever be made with the current feature set, then you're either easily amused or have absolutely no idea how much data needs to be stored and processed in even a simple DOS-era game from... 10 years ago.
Back when I tried to do Civilization in LSL, I did some quick math and came to the conclusion that in a busy game it would take over AN HOUR to compute the data for all players and all cities... PER TURN.
When I started cutting down on the data to make a crappy underpowered port of it, I came to the conclusion that while it was possible, it would be more of a proof of concept than a real game. So thats why I am currently attempting to code the very first popular games from the early 80s - and failing even at that. Ask Tiger Crossing (who codes real games for a living) about his Tetris game and why he couldnt get it to run smoothly. The keyboard controls were horribly unresponsive.
Me and a couple of friends are trying to work around it... lets hope we can figure out a solution that doesnt involve waiting for new features from LL.

Remember the first rule of MMORPGs: everything on the client WILL be hacked.

You dont say
I've coded my fair share of client-server and three-tier architectures. That is why we usually run checks on the validity of inputs, store data on the server etc.
I know you're paranoid about ppl using pushobject on your games and stuff. As a general rule of thumb you should assume that your system WILL be hacked, regardless of how perfect your code is. But my question is, should that prevent you from making a game that the 99.9% of people who will NOT spend their time hacking it but rather enjoying it?
Make the game first, worry about it later.

Faith eggy, faith! We got a boost to frames per second and to prim counts in 1.2. Perhaps 1.3 or 1.4 or 1.5 will include a tripling of script run speed, twice the available memory (with accurate reporting of available memory) and better data structures (arrays and structs). Before 1.1 you couldn't make a decent enough vehicle to race. Now it is quite possible to make a vehicle that is excellent for racing.

Besides this thread isn't titled 'Why will SL never be a game platform'. We are discussing what it would take to make it a game platform. I think its possible and I don't think it would take much.

A client side script would be cached like a texture but should also have some additional features. Perhaps a quick hash of the cashed script is compared to a hash of the one on the server. That doesn't help for stored variables I suppose, but if its really important then store it on the server. Chances are data needed for more than one person will be faster if stored on the server, while individual data only used rarely on the server is what will be stored in the script. Part of the idea is to pass off some of the calculations to the client so they are faster for that player. Extremely important for a non-laggy custom UI.

Hacking may be possible but that shouldn't prevent it from being a possibility.

No kidding on writing to a notecard or other persistant medium.

I'd personally be happy to pay a reasonable amount of real money ($) for say a meg or so of readable/writable plain text, which would be stored on the server's HD. Heck I'd be happy with 16, 32, 64, kbytes. Just some way to have persistant saving of data so we can design things that utilize *data*.

Notecards would be great, they already exist, and already are readable. We just need to be able to write to um, delete lines, count lines (ok we can do this, but a quick function to return the line count vs loops would be nicer).

This sort of feature is way past due and certainly would open up vast possibilities.

Bos

Edit
Apparently I've posted this and it's in the wrong forum. I hate html based anything.

** deleted **