roncli.com blog
The blog of roncli
roncli.com blog
roncli.com
blog
Profile
roncli
Houston, Texas, United States
Labels
Coding
CTG Music
Editorials
Games
Miscellaneous
Music
Servers
Silliness
Software
Sports
Trax in Space Beta
Weather
Recent Posts
A Low Bang to Buck Ratio
win-acme
Overload has truth; next it needs balance
I Thought I Wasn't Going to Ever Blog about Trax i...
The Big Picture
Uhhh...
OTL's player disconnection issue
The Overload Teams League
Steak Burrito Recipe
The Descent DXX-Retro 1.4 Roadmap
Archives
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
June 2008
July 2008
September 2008
December 2008
February 2009
July 2009
August 2009
September 2009
October 2009
November 2009
February 2010
March 2010
April 2010
June 2010
July 2010
August 2010
September 2010
October 2010
November 2010
December 2010
March 2011
June 2011
July 2011
August 2011
September 2011
October 2011
December 2011
January 2012
February 2012
April 2012
July 2012
November 2012
July 2013
April 2014
July 2014
August 2014
November 2014
December 2014
March 2015
April 2015
May 2015
June 2015
July 2015
September 2015
January 2016
February 2016
May 2016
July 2016
November 2016
March 2017
January 2018
May 2018
June 2018
January 2019
January 2021
February 2021
March 2021
August 2021
Sunday, August 29, 2021
A Low Bang to Buck Ratio
Posted: 2:08:00 AM 0 comments
The story behind Six Gaming is long, complex, and probably can't be covered in a single post. If I were to sum up what Six Gaming is today, the answer would be "probably should be dead, but stubbornly isn't". I knew this going into redesigning the Six Gaming website, yet I did it anyway. Why?

There's a number of personal reasons involved. My outside hope that some day everyone stops being super busy with life and commits to a podcast again, which is what the original community was built around after our WoW guild died. The only reason I decided to stop streaming it is because no one could commit to the schedule except for me. The website also has a Discord and Twitch bot that promotes streamers, hosting them on our Twitch page, which would be a great tool if the community was still active. However, it's not active, so the main reason I used to justify upgrading Six Gaming? Knowledge building.

Six Gaming is the first website that I've built that runs with a MongoDB back end. It's the second site I've built that uses Docker containers. It's also the second site I've built on my current generation of node.js website architecture, but the first time I've done it within Docker. The website uses Discord.js, Express, FullCalendar, the node.js wrapper for IGDB, the node.js wrapper for MongoDB, and the Twitch.js library that is being rebranded as the ridiculously-named Twurple. However, when I talk about my website architecture, I don't mean the libraries I'm using, but rather the way the website is put together.

I drew some inspiration from the now-defunct Rendr library. It was a node.js library that worked with Backbone.js to let you code a web site just once to render web pages on both the client and server side, making it easy to create single page applications. I was turned on to this library while working for the startup Sift back in 2013, and ultimately used it for my personal site roncli.com. Of course, as soon as I released that site, Rendr stopped getting updated, so I stopped using Rendr and started rolling my own.

The first website I used this new architecture with was the Overload Teams League. I didn't go too far with it, only making it so that there are views that can be rendered either client or server side. I didn't go as far as making it a single page application, that wouldn't come until I version 2.0 of roncli.com. The back end architecture is your run of the mill MVC application, nothing too exciting going on. What made everything tick, however, was a custom-built router that I would eventually release to NPM called Hot Router. It's called that, because it has an option that lets you hot-swap controller files while the site is live while the application is running. That was super useful for debugging the first few sites created with it, but the hot swapping has become less useful now that I've gotten better at using Docker.

All of the above is setup for one of the more amusing issues I encountered while working on Six Gaming's website, and there were plenty. Being only my second Docker project, I won't talk about what I can only describe as "newbie mistakes". However, the biggest thing I found was what I term the memory leak from hell.

I discovered it when I was working on the Hot Router project. The gist of the problem is that for weeks after the launch of six.gg, I had a very slow memory leak that would break down the server after about a week. It drove me insane that I couldn't find it. The lengths I went to in order to find the leak were insane. First, I wrote my own calls to the docker.sock API, logging the metrics to Application Insights. That alone instantly doubled the cost of the server while I had the metrics active. The price you pay.

This led me to learn the memory leak was happening in the node.js Docker container. In order to find the memory leak, I had to connect the node.js instance inside Docker to Google Chrome's dev tools. Once I did that, I spent hours pouring over memory logs, slowly narrowing the problem to my shiny new router. Did making the router a module cause the memory leak? Did I screw something up porting the code over from being inline in the project to its own module?

No, the memory leak was there all along. I tried comparing Date objects to see if they were different. While you can compare to see if they are greater than or less than each other, trying to compare that they are equal or not equal actually doesn't work. This was causing Hot Router to always treat the controllers as if they were just hot swapped. It would delete the cache of the controller and re-require it. As it turns out, the act of deleting the cache and re-requiring it caused the memory leak. That, combined with the date comparison bug, resulted in a slow memory leak.

As I was fixing that bug, it dawned on me. I run the Overload Game Tracker, and that site had been suffering from a memory leak for over a year. It runs an early version of the routing code that Hot Router uses. Turns out I solved a very old memory leak by finding the leak in an entirely different application.

Anyway, Six Gaming's website has been humming along for a while. It was a lot of effort for not a lot of reward. However, this project taught me a ton about Docker, MongoDB, and more. And everything I learned from this is going into my most ambitious project yet... my own website! More on that in a future post.

Labels: , , , ,

win-acme
Posted: 2:05:00 AM 0 comments
Here's a great piece of free software for IIS administrators who want to easily manage their SSL certificates from Let's Encrypt.

win-acme is a self-guided command line utility that allows you to quickly and easily take an IIS website and get an SSL certificate on it. After struggling with utilities like ACMESharpCore, ZeroSSL's Crypt-LE, and Posh-ACME, I realized that all of these tools, while powerful, didn't have any ease of use whatsoever. When I first looked at the text interface for win-acme, I didn't think it was going to be as easy as selecting options from a menu.

It's as easy as selecting optinos from a menu.

Within 5 minutes, I had 7 websites with shiny new SSL certs, and I had gotten them scheduled them for a regular renewal. I didn't have to do any configuration or any PowerShell scripting, it just worked. Give it a try if you're running websites on IIS!

Labels: , , , ,

Thursday, March 25, 2021
Overload has truth; next it needs balance
Posted: 6:31:00 PM 0 comments
Overload multiplayer was put together in around a month, went through another month of testing, and ended up being rather underwhelming to play. Ranked multiplayer queues died out after the first couple weeks, those that remained were either gaming the system or late to the party. Mercifully, ranked multiplayer did not survive very long.

However, multiplayer soon began to thrive in the form of the Overload Teams League. I founded the OTL in 2019 for pilots who wanted to play team games. It caught on pretty quick with 6 teams by its second month. At first, we dealt with the frustrating limitations of poor server choices, shoddy networking, and always demanding to Bammer "RESTART YOUR SERVERS!!!". But shortly after Revival Productions folded in February of 2019, a glimmer of hope appeared in the form of olproxy, a piece of software that allowed Overload LAN servers to act as Internet servers. For the first time, Internet games were playable without official servers.

Over time, this expanded to olproxy being incorporated into olmod, a collection of mods for Overload with the aim to improve multiplayer game play. A large number of improvements have been included in olmod since then, including larger game sizes, reporting to a tracker, sniper packets, lag compensation, and more. What hasn't been addressed is weapon balance.

Multiplayer weapon balance has not been great since Overload launched. Ammo weapons have been shown to dominate, and the energy weapons are a mixed bag with cyclone being dominant and reflex being weak. Hunters used to be super strong until an early nerf was added to olmod. Creepers and time bombs used to be excessively out of sync between client and server. Despite this, people still played, but bigger issues existed because people couldn't understand what they were seeing. Ship positions were not consistent. People were saying that 50ms in Overload felt worse than 100ms in Descent 3. (While seemingly unbelievable, this was learned to be a true statement since Overload intentally adds a minimum of 83ms of lag to game play; 33ms for processing controls smoothly and 50ms to be able to interpolate ships smoothly.) Slowly over time, the net code was deciphered and unravelled, and we learned some shocking things about how the net code was implemented. In addition to the intentionally added lag, your entire controls are sent to the server every frame for processing server-side. Every button press, mouse movement, or swing of the joystick would be part of that send. But because client and server frames don't match up one to one, this would cause errors in position and rotation, and weapon firing that was often out of phase, meaning what you saw on your screen wasn't what was happening on the server.

First, we fixed the weapons. Sniper packets made it so that every time you fire something client-side, that is what was seen server-side. This also eliminated some super bad parts of the game, such as disagreements as to how many missiles you have, what weapon you're using, what side of the ship you're firing a missile out of, and more.

Second, we fixed most of the intentional lag and made it so that it would try to compensate for lag, predicting where ships will be in the future, making them easy to hit. Then we revisited weapons, also compensating them for lag so that they'd be easier to dodge.

I say "we" because this is a team of developers doing this. Arne de Brujin created olproxy and olmod and showed us what is possible. I've contributed a bunch of code, and Tobias, Whollycow, and derhass have been instrumental in keeping things on track. We even have occasional contributors like terminal, luponix, and D.Cent provide extra quality of life for both players and developers.

And now we're ready to tackle balance.

Players are now seeing the game closer to the truth than ever before, and as a result they have honed in their skills better than ever, showing us that, yeah, there are serious balance problems with the game. It's not like we didn't already know this. However, now that we are seeing closer to the truth, we can begin to understand exactly what these balance problems are, and hopefully start finding common ground in regards to what needs to be balanced.

Labels: , , ,

Thursday, February 25, 2021
I Thought I Wasn't Going to Ever Blog about Trax in Space again...
Posted: 2:08:00 AM 0 comments
Well, I hope at least a couple people get a good chuckle out of the title. Fortunately for them, this post is about something else entirely: the Trax in Space 1 file repository.

I've maintained this site, with some interruptions, since around the time TiS1 shut down, which I believe was some time in 2003 or 2004. It was a simple site written in Classic ASP that had one purpose - serve files. When I lived in Houston, I maintained this site on my own server that was literally right next to my desk. I had unlimited bandwidth, great Internet speeds for the day, and was able to let people download what they wanted.

Fast forward to October 2015, when I moved from Houston to Belmont. The site was unceremoniously removed from the Internet, and I really had no idea how I wanted to get it back up. I had roncli.com up in Azure for quite a while by that point, but didn't really know what the cost was going to be for me to put the whole 14 GB repository online, so I just... didn't.

It didn't take long for people to notice it was gone, either. In December 2015, I received my first email regarding someone willing to host the site. As a man of technological pride, I silently declined, promising to myself to put it up soon. It took me 2 1/2 years to do so. This was the birth of the Github repository for tis.roncli.com, rewritten entirely in Node.js. However, there was a twist. Because I wasn't sure what kind of cost bandwidth would have, I limited downloads to 50 per 24 hours, a limit that still exists to this day. People have been generally happy that it's back, but have been asking for the 50 download limit to be removed. I've largely been unwilling to do that, simply because I'm not sure what the cost of doing so would be. However, it's a question that I will be willing to revisit after this current project is complete.

Last year, I started learning Docker, and figured TiS1 would be a great first project. I learned how to set up Azure Storage, where all the files now live. I learned how to run certbot properly, got nginx as the web server, and log failures to Azure so that I can monitor what's going on. It's been awesome. The server is a Linux VM that's super small compared to the one I'm running, and is all open source, so no fees for it being a Windows VM with SQL Server on it. It's pretty cheap to run, too: about $10/month.

TiS1's transition has been a success, and kick started me on my next project... moving Six Gaming into Docker, a project that was full of... let's say "learning experiences". I'll talk about Six's challenges in my next post.

Labels: , , ,

Monday, February 08, 2021
The Big Picture
Posted: 4:16:00 PM 0 comments
Sometimes, it's a good idea to take a step back and look at what you're doing and what you've done, and ask, "Can this be better?"

I recently did this with my Azure Windows VM. For a while, I've been just loading up any new website or venture I've created onto my VM. This, however, has proven to be problematic when it comes to some of my more recent projects, including the OTL and the corresponding Overload Game Browser. These two projects are by far my most used websites on the server, and they continually push the limits of what this VM can do. Timeouts have become more and more frequent, and as more and more data piles into the database, the problem is just going to keep getting worse.

So I asked the question, "Do I need to be on a Windows VM?"

Some years ago, the answer would have been "yes". I was running .NET Framework 4-point-something, and had a lot of Microsoft-specific things on the system, including a Microsoft SQL Server. Now, however, every site I host is written in Node.js. The only thing remaining that requires anything Microsoft is the SQL Server.

So I asked the question, "Do I even need SQL Server?" I don't think I do. MongoDB exists, and I have been figuring out how to work with that for some time.

As such, I've begun a massive project to try to move away from this Windows VM and retire it permanently. For a while, I wasn't sure how I was going to do it, but as part of a learning course pilot at work I picked up Docker. My goal is to move every project that I have on that server into a group of Docker containers and run them on their own Linux VMs. Linux VMs are much cheaper than Windows VMs, and if something starts running out of resources I can just up the VM size accordingly.

So what is going to move?
This is, of course, a multi-part project that has taken on a life of its own in recent months, and it's one I am enjoying greatly so far. It's really expanded the boundaries by which I am able to operate websites and related online services. In coming posts, I will talk about each project separately, and what each site's status and future is.

Labels: , , , , ,

Sunday, January 24, 2021
Uhhh...
Posted: 2:17:00 AM 0 comments
Hi. I'm roncli. You may remember me from some of my greatest hits, such as Got nasty VB.Net ListView flicker? Double Buffer it, Of tigers and clowns, and most likely OTL's player disconnection issue because I haven't written anything on this blog in two years. Needless to say, I haven't done much here lately.

I don't know if that's going to change. This blog used to be where I wrote things that I wanted to talk about. Over time, that moved to Twitter as my musings turned more short form. As a result, I'm quite active there, and I've had no motivation to keep this blog up to date. At all.

That makes it quite unfortunate that I chose to make my blog the main feature of my home page. When I was putting this version of the website together, I had grand plans to start getting creative again in music, keep writing on subject I enjoyed, and maybe even build a small community around the website. None of that happened.

What has happened? My interests have changed dramatically. Instead of being creative in the music space, I'm creative with my streams to Twitch. Instead of writing about what's going on, I've increased activity on Twitter and Discord.

But one interest that hasn't changed is coding. I've done so much over the past 2 1/2 years with various coding projects that 2005 me would be super jealous of how much I've been able to accomplish, and that kinda feels good. I have a lot to write about on this subject, and hopefully will find the time to do so over the coming weeks, but the project that I'm currently working on is a complete rewrite on roncli.com. While the content will largely remain the same, the amount of real estate I give on the front page to this blog is going to be reduced dramatically. The truth is the content of this blog isn't all that great, and I don't really want to give a ton of space to something that I don't update often. I certainly will keep it around for archival purposes - mostly to remind myself of how unfiltered I was in my younger days - and make an attempt to make it a bit easier to browse.

Here's to hoping that this post won't burn another image into the site's front page for the next couple years.

Labels: ,

Wednesday, January 30, 2019
OTL's player disconnection issue
Posted: 5:40:00 PM 0 comments
The Overload Teams League has started off fairly well. We've played 26 games in the first month, completed a small one-day tournament, and have had five teams play each other at least once. But there's one issue that's come up that's been really tough to call. There was a player disconnection issue that recently came up where a player BSOD'd and there was some confusion on what to do. I wanted to put something in writing before this happens again.

First, some background.

In Descent 3, Heat aside, all servers were private. Players could come and go as they pleased, and you could always rejoin a game after crashing out. Game parameters were also much more open. Kill goals and time goals were text entries, not selections from a menu.

Revival confusingly bucked this trend in Overload, removing server browsers and opting for monolithic servers that can run multiple games at once. However, the only way to access these games is if you have the password AND you join before the game starts. There's no way to see what games are running, and even if you had the password you can't join a game in progress.

The Descent 3 Teams League pretty much ignored any issues with disconnections. DCs could simply be met with a substitution (subs were common in D3TL matches!), or by playing shorthanded until the disconnected player returned. Only a full server crash would suspend a match (in the D3TL Tournament, this only happend once ever, but was in the semifinals!), but players would pretty much just restart from the prior score and amount of time left with little fuss.

Disconnections in the OTL cause bigger problems.

  • Players can't reconnect to a game in progress, leaving their team short-handed.
  • If you wish to suspend the match, you have limited options to select time parameters in game.
  • Because of the above, disconnections can be seen as gaming the system, depending on many factors.

In short, in Overload, we as a league have to deal with a situation that's less than ideal. We are aware of the fact that games online are not nearly as flexible as they were with Descent 3, and we have to adjust as a result.

In the OMG/PTMC Terminal match, PuDLeZ BSOD'd and disconnected with approximately 2:30 remaining in the match while his team led by 5. Teams immediately stopped playing and agreed on starting a new game from the current score and time remaining (they had suggested 5 minutes, until I stepped in and asked for 3 to more match the time remaining). The stats from both games were combined for the final match score.

From my standpoint, that was awesome. Both teams came together to finish out the match despite the circumstances. And, this is the kind of model I want to encourage... work out a solution that both teams can agree on. However, teams will have different ideas on how to do this, so I think it's good to have a set of guidelines available along with what to do should teams NOT agree on a way to go forward. Here's what I came up with:

Should a player disconnect or a game end prematurely due to a crash or network outage, every effort should be made to get the current stats from the game up to that point in the match. Teams should then agree on what to do next, within the following guidelines:

- Teams can agree to restart a Challenge if 10 minutes or more remained on the clock at the time of the issue, or if multiple issues happen within a single match.
- Teams can agree to end a game with the score as is if less than 3 minutes remained on the clock at the time of the issue.
- Teams can agree to play a 2nd game, combining the scores of both games for the final score of a single match. The second game's time limit should be as close to one of the time options available in game as possible to the amount of time remaining when the issue occurred. For instance, if there was 6:23 on the clock, teams could agree to play the 2nd game with either a 5 minute or 7 minute time limit.

In all cases where a match is suspended and resumed, the same pilots must fly for both teams, as substitutions are not normally supported in Overload games.

If teams cannot agree on what to do, an administrator can be asked to decide how to proceed, and they will make the decision. The administrator may also opt to adjudicate the match accordingly in extreme cases.

If one player is repeatedly having these kind of issues, they may be suspended from the league until their issues are resolved. If it is deemed that the player is acting maliciously, they may be banned from the league.

I don't want it to feel like I'm ignoring the momentum argument, so I'll address it here. Momentum is a very real thing, and it sucks to have it taken away by an extraordinary circumstance. However, examples of leagues or competitions that put extra time on the clock because of such an issue is exceedingly rare. In fact, more often than not, you end up LOSING time. Here are some examples of what other leagues do, where, surprisingly, many take place in the sport's biggest games of the year.


I'm sure there are plenty more examples to put forth, but overwhelmingly the concept of momentum is not given much thought in any of these cases. Either they drop the rest of the game, pick up where they left off later, or they start over. Nowhere is something arbitrary like 5 extra minutes given just to facilitate a possible comeback or to restore momentum. And I think this makes sense, especially in an environment like the OTL where we have individual stats and want them to mean something instead of having them skewed by stats where matches were far too short or too long.

In an extraordinary circumstance, you need to make a judgement call that someone somewhere is not going to like. As long as we deal with these circumstances with consistency and with good intentions, that should be all anyone can ask of the league. I also strongly like giving teams options, and them letting them agree on which option to take, only calling in help when they can't agree.

Hopefully this will address the situation, but leave it open to discussion for now over on the OTL Discord. Apologies for not thinking of this sooner... I had a lot of situations planned out, and this was definitely not one of them!

Labels: , ,

Friday, June 08, 2018
The Overload Teams League
Posted: 6:37:00 PM 0 comments
I wanted to put together a bunch of my thoughts regarding the possibility of creating the Overload Teams League.

Those who played Descent 3 might remember that I took over something called the Descent 3 Teams League from bash and Sirian, and ran it for a number of years. I kept it going until well into the second half of the aughts, with help from Matrix and IceHammer to keep things running smoothly. Eventually the game dried out, and with it the league was retired.

With Overload, the potential for Six Degrees of Freedom competitive team action returns. I've recruited Chilly Bus and MobMessenjah to bounce some ideas off of, and wanted to list out what we've come up with so far.

The Spirit of the OTL


The OTL "spirit" borrows a lot from from the D3TL. Essentially, teams get together to play competitive games against each other, and the system is there to facilitate the games with as little interference from administration as possible. However, we are planning on having a few notable differences for the OTL.

First, seasons are being planned. While there will be lifetime standings, we want to rotate out the standings every 6 months to keep the leaderboards fresh.

Second, we're going to want to keep big rosters down. The D3TL team NT was a unique idea, but we really don't need to have teams with 50+ players on it. This means that large clans would have to enter multiple teams on the D3TL, which means more people will be able to play, and even allow for intra-clan matches. Right now, we're looking at rosters being between 5 and 8 players, although we're leaning towards the higher end of that list.

Third, we're looking to keep the game time down. D3TL games averaged an hour in length. Overload right now only allows a MAXIMUM of 20 minutes, and that's the standard we're looking at adopting. If Revival raises that maximum, I don't think we're going to want to follow suit.

Fourth, we think map, opponent, and mode diversification is unnecessary in 2018. To keep teams from playing the same map over and over, we're likely going to borrow the "home map" concept from The Observatory. To keep teams from not wanting to play other opponents, we want to implement a ranking system that's more than just wins and losses. And, there's only 2 real modes in Overload right now, and both are team anarchy... one with friendly fire off, and one with friendly fire on.

Finally, we want to do frequent events. Three kinds of events we're thinking of:

  • Regular events, perhaps monthly, that are at different days and times, where people can get together and play a small Swiss tournament for a few hours. Similar to The Observatory's tournaments.
  • Mid-season events, a top 6-team invitational knockout tournament, perhaps with something on the line like a guaranteed spot in the knockout tournament of the end-of-season tournament.
  • End-of-season events where we pull out all the stops... qualifiers for people to get into groups, a group stage round robin, and concluding with a knockout tournament. You win this, you're the season champion!

Choosing Maps, Servers, and Colors


I mentioned using The Observatory as a way to determine what map to play, but I wanted to go into more detail on map selection, and other selections that may give advantages to one team and not the other.

First, here's what we're thinking for maps. Teams will have a pool of "home" maps, and when they are the "home" team, their opponent will choose one of those maps. Who gets to be home? That'll alternate every game between the two teams, with the first game being random. What if both teams want to play a map that's not their home map? Teams will be able to agree to play any map available, overriding the home team concept for one game.

Servers will work the same way. One team will be assigned to start the game, which allows them to pick the server of their choice, and the next game between the teams your opponent gets the choice. Every 2 games this resets. However, you can agree to play on a particular server (provided you have access to it) to override this behavior for one game.

Finally, colors will just be assigned in a similar way to servers. Unlike the servers, though, your team color shouldn't be something to agree upon. Sometimes you'll be orange, sometimes you'll be blue.

Game Rules


Overload has a lot of ways to play team games, but we obviously want to standardize them for fair competition. This is what we're thinking:

  • Time limit: 20 Minutes
  • Show Enemy Names: Team Only
  • Respawn Time: 2 to 4 Seconds
  • Respawn Shield: 2 Seconds
  • Powerup Overall Frequency: High
  • Powerup Initial Secondaries: Low
  • Powerup Super Frequency: Low

All powerups are allowed, largely because we can't disable anything non-weapon.

As for Friendly Fire, we're actually thinking of making that a separate "mode". If you recall, the D3TL had separate rankings for each mode, but there was an overall ranking as well. We'd probably do something similar for this.

The Ranking System


Let me come out and say NO ONE is going to like the ranking system. Regardless of what system we use, nothing's perfect. I am hoping that by using a combination of a ranking system and regular events, any decent ranking system will be accepted as long as it's not the final authority on "who is the best". With that said, I'm going say that naughty word: Elo.

Long story short, I want to have score ratio be a factor in Elo score changes, and have the rankings be somewhat volatile given that these are not lifetime ratings.

First, we have an idea to have the score ratio factor in the Elo "result" calculation. Normally, a win would give you a 1.0 result and a loss would give you a 0.0 result. In our version of the Elo formula, you'd only get 1.0 if you doubled your opponent's score, and 0.0 if your opponent doubled your score, with a logarithmic curve filling in the points in between. I came up with the "double" by examining the history of Team Anarchy scores in the D3TL Tournament. It maxed out at a ratio of 3.27 to 1. If you're beating your opponents 45 to 15, the team with 15 is going to need to improve dramatically to ever have a chance of winning. 45 to 30 feels more like that the team with 30 could eventually win. There's no real solid statistics on what exactly to use, but this feels like a good starting point.

Because we want a decent level volatility, K will need to be high. On top of this, because we're going to be using score ratio as the result, this requires us to have a higher K to keep things a bit volatile. I'm looking at experimenting with a K=50 for the first season.

Finally, we want to use a provisional rating so teams can't play 1 game and be ranked among the top teams. Teams that have 10 games in a season will have their full Elo as their rating. Outside of that, every game a team plays will give them access to 10% of their Elo. So, a team with an Elo of 1500 but has only played 2 games will have 20% of their Elo applied to their rating, so their rating will be 300.

We'll also have individual player stats, like total points, points per game, deaths per game, and efficiency.

Things We Want Revival To Do To Help


Revival has done a great job at making a game people want to play, but there's more that can be done to make this game really shine, as well as help out the OTL with doing what we want to do. To this end, we currently have a small list of ideas we'd like to pass on to them.

  • Overload NEEDS an observer mode. In 2018, it almost feels like an oversight to not have some kind of observer mode. Even Descent 3 had observing!
  • To keep games fair, all players need to be able to confirm the selected settings for a private match. Without this, the person starting the match could sneak in some setting that the other team won't be aware of.
  • Game stats from private games should be output to a text file. No funny key combination required, no UI element, just a way to always output private match results. It should include each players' score line (kills, deaths, assists, suicides), and each players' kills and deaths against each other. Again, something to take away from Descent 3.
  • Allow the player hosting to pick which region to start their game in. Right now it just defaults as the closest to them, but what if a bunch of US players want to play Germany players on a UK server?
  • Right now you can select which weapons to allow or disallow. Extend this to other powerups: Ammo, Energy, Armor, Invulnerability, Cloak, Overdrive... everything.
  • Make an option to disallow players from delaying their spawn in a private game. This would prevent cases where a team is in the lead, but the other team is making a comeback, except the team in the lead just stops spawning.

League Interface


The primary interface for the OTL will most likely be a Discord bot. I have a lot of experience with Discord bots as I've made 3 now, and having a bot to help out with managing things like rosters, game reports, and more will really make it easy to keep the league running without anyone getting involved unless there's a dispute that needs to be resolved.

We'd still have a website, but its primary focus would be to show standings, results, and more. All other communication would take place on Discord.

What's Next?


Discussion, of course! I am posting this on a Friday to give everyone some time to read it over and form their own opinions as to what might be fun in an Overload Team League. On Monday, I'm going to do an Overload stream at http://twitch.tv/roncli and hold an AMA regarding the league. I'm looking for your questions and suggestions, so be sure to add your questions on the Reddit OTL AMA comments thread so that I don't miss them.

Summary


Overload is pretty well-suited for a teams league like this, and I think that having an organized teams league will get people playing multiplayer, and especially team games. Additional support from Revival will allow the league to do more, drawing even more interest from players who would not otherwise play multiplayer.

Labels: , ,

Tuesday, May 08, 2018
Steak Burrito Recipe
Posted: 1:06:00 AM 0 comments
Presented with only this comment... if AI is going to take over the world, it ain't coming from New Zealand.

Labels:

Tuesday, January 02, 2018
The Descent DXX-Retro 1.4 Roadmap
Posted: 5:46:00 PM 0 comments
For some time now, I've been a Collaborator on the DXX-Retro project. Originally I just started helping out on various odds and ends, but lately my focus has been on the observer mode of the game.

Over the past two years, I've essentially been waiting on the project owner, Drakona, to work up the networking code to send client ship status to the observers. It's one thing to see the ships flying around in observer mode, but another entirely to know everything about those ships. That is, shields, weapon loadout, what weapons you're about to fire, etc. Unfortunately, her last commit to the project was February. Of 2016.

I get that priorities in life change, especially when you become a two-time parent. :) The Descent community, however, hungers for more, and as a result I've decided to finish off observer mode in Drakona's absence. There's actually quite a lot to make that happen, so I've created the v1.4 Roadmap. In this post, I discuss the rationale behind the roadmap, and what to expect from Retro in the future.

DXX-Retro has largely served its purpose to the competitive community, but two outstanding features remain to be added. Both of these were promised by Drakona to the late JinX. One of these features, observer mode, was even kind of named after him, "JinX Mode". The other feature was specific for Descent 2, and that is Capture the Flag Classic, which brings D3-style CTF play to D2.

In February of 2016, Drakona and I released an early version of DXX-Retro v1.4X5, which gave us a taste of observer mode. This only gave us the visuals. While we could see ships flying around, we didn't know anything about those ships other than what their opponents knew. This was always wanted, but we never really came up with a plan to do it. And, in the past 2 years, nothing has been worked on to support this. Unfortunately, Drakona just hasn't had time to work on it, and my work has therefore stalled.

While it hasn't been a great situation, the community has gotten a lot of mileage out of observer mode. So much so that a Twitch show was made out of it which continues to enjoy success among the community. However, there's a lot that we miss on the broadcasts because we don't have those shield numbers, the weapon loadouts, and whatnot. And after two years, the time has come to just get it done.

So, I'm getting it done. The roadmap includes 5 future releases along the 1.4 line. The first will be v1.4X6, which I'm hoping to finish this week. This will include the shield numbers appended to the pilot names under the ship. I want to also include a way to indicate damage, and will be working on ideas for that.

The second release will be v1.4X7, which will get the rest of the ship status in the game and make any necessary upgrades to the observer mode UI that we want to change from previous versions. I'm *considering* adding my custom-made Observatory UI to Retro, but am not sure that's needed.

The third release will also be v1.4X7, but this time for Descent 2! Once I know what I'm doing in D1, I can apply that to D2, and we can have an observer mode for both games.

The fourth release will be v1.4X8, also only for Descent 2. This will include Capture the Flag Classic, where instead of the "egghunt" style game where flags are worth 5 and kills are worth 1, we'll instead make the flags spawn in the base, only have teams be able to score if their flag is in their base, and have team points be based on flag captures only.

And finally v1.4 will be the final release for the 1.4 line, which will include any bug fixes, documentation updates, and any other housecleaning duties we need to do for a proper release.

After that, the future for Retro is murky at best. There are no less than 50 open issues on GitHub for Retro right now which vary from essential to nice-to-have to outright silly. Also to keep in mind, the DXX-Rebirth is nearing a v0.60 release that is essentially a codebase refactoring in addition to a ton of other updates. I would love to see a Retro v2.0 not only based on Rebirth v0.60 but something that can also follow that version as well, instead of being a complete fork that forgets where it came from. This in and of itself would be a monumental task.

Until then, however, we'll keep Retro focused on what we need to release v1.4, and if I can keep it going without the need for added help, perhaps that will be much sooner on the horizon than expected. Here's to some better Descent in the near future!

Labels: , , ,