Feh: +1/-2

Took a step back today… Little chance to apply some of my stockpiled JSP/Ajax tools to some pre-existing management pages and solve a few recurring (and really annoying) problems, I also picked the TOE implementation apart and mini-dumped it into a sort of pseduo-design document, a chance to go over the more intricate elements and see if I’d got any dumb stray pointers or references lying around. None I could see.

The new (old) infantry smoother (it extrapolates, it doesn’t predict) was getting some heavy criticism from the folks who’d open-tested it. Guess what, its worse than the new (new) smoother. I think in part this is because our update system is very crude and it resends stale updates when it doesn’t have anything else to send.

I spent most of my evening trying one last time to fathom how our freaking update system actually works. There are way too many casts, voids and aliasing and too many cases of fake structures using some quirk  or assumption about field alignments. *Sigh*

So I took the old “Chat Grid” that I wrote and spent a quarter hour refitting a version for the cell hosts. Another half an hour throwing together an Observer based system for tracking who is seeing who.

The current system has the advantage that the vehicles you get updates for are hand-picked from the best possible viewing candidates at the time of the update. That makes generating each individual update expensive and limits how many vehicles we can support per server and/or updates per second we can send per player.

The mechanism I’m looking at will update your vis list less frequently – say once per second. That allows me to expend a little more effort in the list management. At the same time, it allows me to annotate some of the data so that I can actually avoid a certain amount of uneccessary list revision. (Single player standing in an unoccupied area, lone aircraft flying across the channel, 3 AT guns sitting at an FB without moving)

Tomorrow I’m going to go through and re-create the skeleton of the TOE code and then re-integrate the existing code back into itself to see if I can find whats causing the bug.

All that aside, I did get a chance to spend some time trying out the Open Beta. I usually hate trying to play the game on my work machine, but my frame rate was up, stutters were non-existant, and the world was just much brighter.

There was an FFA battle at Spontin, with people using the “/msp” command to drop spawners wherever they could hold. We all figured out pretty quickly that corpses were sticking around a LOT longer. It could just be because there were less people around. I think corpses actually go away as your vis list fills up.


The venerable /msp command!. Open Betas are always a source of interesting information, not only for bugs, but also for gameplay sometimes.

Too bad that is too much complex to spend time building alternative gameplay features for open beta, to choose between drop them or getting them into the live release. But the /msp command is a beta feature that it’s usefull for the beta purposes and it’s the only exception with potential impact on gameplay results.

The /msp command, with some kind of small persistent unit (platoon of players), and some ranging rules about the deployment of a STO spawn (platoon command post), can give an alternative to the UMS in gameplay that it’s very interesting.

And i know that i’m not the only one who fantasizes around here :)

In addition, we want to take the STO/MSP concept a step further for infantry play and allow the mission leader to slowly advance the point at which his group can mobile spawn. This would involve something akin to “area capture” – to secure an area for his group – and the placement of an STO object that can be seen & destroyed. Ranging-rules would apply, but in such a way as to make it a process rather than simply running up to a spot and birthing a quick army.

Lately, when i check the playschool forums, it’s frequent to find some threads speaking of developing that kind of gameplay feature. I can smell in the air that the players realized the importance of some changes in gameplay for the small group of players.

In your design of TOEs surely you will be forced to see the big picture of brigades and divisions. But may be someday, a new need will be opened for the game: the small unit TOEs to fit with small persistent units of players. Who knows?. :)

In FONTOY, I believe, in the Open Beta, both the Axis and Allies had an MSP dropping in the AB bunker, right by the radio table. THAT is a fight to the death with everyone trying to camp that area. Very exciting, especially if there were a 5 second delay where the spawner was invulnerable *and* could not fire, but could manuever by turning or laying down. That would make camping a 50/50 event and not such a good pay-off for the camper.

Well maybe something as simple as having the ML-based MS be based off of the ML himself – ML dies, MS dies. I recall having that problem with the .ms command on the training server, so I know it can be done. :p

Eh, someday. The biggest problem would be that there are areas that it could really hurt gameplay without some other changes (.ms in an attic or bunker, the small exit gets camped, supply disappears in five minutes flat), but it would still be nice.
It always ends up being a “good for, bad for the game” thing though – it speeds up the action, but it discourages teamwork; inadvertently, of course, but you don’t have the same amount of communication with the other players compared to when you drive out there with them.
Of course, once you get out there it would be nice if you didn’t have to repeat that drive to rejoin your team, but there really isn’t a nice, graceful solution that doesn’t erode that communication and, to a degree, the sense of danger you get with having death be, if only for the run out there, the end of the action – nothing empties faster than a camped AB, but one or two paramissions being shot down is going to seriously cripple the turnout for the third run.

Victarius. The range rules can do it…
For UMS we have a minimum range limit and a maximum range limit.
For the deployment of Platoon Command post you can place greater ranges to one of the ranges or to both range limits.

Specially interesting it’s the option of increasing the maximum range limit to open a bit the freedom of placement more close to the origin of the “group” (FB or AB). Since this kind of STO spawn point will be better limited to the organized groups that want to progress in the field together, the number of players that can respawn should be limited. This spawn system it’s intended for one persistent unit of players, players that aren’t on that persistent unit, should use the UMS spawn system.

Well – its great to have an STO with the Mission Leader, but I think you do need to have original people drive out with the MSP or be with the Mission Leader to set a limit of the number of people that can spawn out of that item.

Example: 8 people on a Beddy/Opel drive out and driver places UMS. That UMS has a throttle for 8 people…pause 2 minutes…another 8 infantry items are available out of the MSP. Notice how this makes FB runs require people to drive out with the truck, and may make the UMS unnecessary for destroying the FB.

Mission Leader cant and shouldn’t make a UMS like object with insta-army spawn…so you need the ML to have between 3-10 people in the area he is before you can create the spawn object. Again, this makes team play, and throttles the spawn naturally, but rewards all teamwork that maximizes that Mission Leader. For example, 10 players around the mission leader in the room are going to have to get to know each other a little bit: because the spawn object should take 2 minutes of them staying together in that location to create the spawn object (like a table timer).

Encourages gameplay, and rewards team work by making an important object in the game.

Good luck on this KFS when you get time.

What about this as an alternate thought to try to retain some reality on a MLSpawn?

Instead of just having people come in to existence anywhere, what if the ML had to be in the footprint of certain objects (bunkers, revetments, city buildings, etc) for spawning to be enabled?

I have to say, thats kinda how I’d like to do it but I’m not sure whether its practical. I’ve been doing a little something here and there with the strat host trying to actually give it some spatial awareness, but its still fairly limited.

I guess trusting the client wouldn’t be a go? IE: when the ML is in a valid area (and the client should be able to tell that – it’s drawing the object around him, after all), he can “deploy” himself for spawn?

I’m not talking about UMS type deploy, but a manual setting by the ML saying “OK, spawn in now guys!” So long as he must be stationary for that, then you should be able to use the client’s worldview.

Well, determining a valid area would be expensive – I don’t know that our current engine provides a means of doing a volume check which is what you’re refering to.

This is one of those rare areas where we could trust the client, since the clients role is not massively beneficial – and as you point out, it would require some rules for deployment anyway.

Isn’t “proximity to one of a special class of terrain objects” as a gating condition for field spawnability, serving as a practical stand-in for “not observable by the enemy”?

I think the latter condition is a more fundamental requirement for maintenance of combat immersion.

Given that condition, IMO “proximity to one of a special class of terrain objects” is functionally inferior to “no enemy fire passing within X 3D radius within the past time period Y”.

An ML can be in a building of some state-condition or otherwise satisfying a terrain proximity rule, but visible to the enemy and under enemy fire. In that condition, spawning is an immersion breaker. OTOH, an ML that’s not under fire is very likely to be not visible to the enemy, because the gameplay correlation between observation of the enemy and bringing them under fire is high.

Smoother code .. AAAHAHHHHAHAaaaahahhhhahahahahhhhhHHAHAHHHHHHHHHHH /panic

Trackbacks and Pingbacks

[…] the design(s) I’ve experimented with (remember, the chat grid system was a prototype for such a concept). But it’s categorically not something I’m going to start working on when we’re […]

Leave a Reply

Name and email address are required. Your email address will not be published.

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

You may use these HTML tags and attributes:

<a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <pre> <q cite=""> <s> <strike> <strong> 

%d bloggers like this: