Spring Jam: August 2016

[gajop]

Theme: Ingame lobby and infrastructure work
Date: August 27-28, starting from 9AM JST (2AM CEST)
Where: https://gitter.im/Spring-Chobby/Chobby
Summary: Work on Chobby (ingame lobby), Chili, pr-downloader & engine, matchmaking bots, matchmaking server protocol, uberserver, ChiliFX (shaders in UI)
Sign up: If you're interested in joining, please make a post here.

As it was concluded in the crisis thread, this year's August Ludum Dare will not have voting, and this makes me less inclined to participate as both the user feedback and competitive spirit will be scarce. At the same time, I want to spend time on something more productive, hence I'm announcing the very first(?) Spring jam.

Previous work
Some of you may know, but with the help of GoogleFrog, TurBoss and a few others, we've been progressing with Chobby, the ingame lobby, and it's looking good. In hope to get player feedback, we plan to make an alpha release for ZK players sometime at the end of next week. After that's done, we will move move on the next big milestone, and implement all the common lobby functionalities.

Matchmaking
The next step we must finally take is to implement matchmaking in its entirety for uberserver. I already implemented my proposal for matchmaking in Uber, although it'll need some bug fixing and testing, and that's just the server. What's also needed is implementing the matchmaking bot. Nemo did some work on that, but I'm not sure in what state it is. If we have to start from scratch, my suggestion would be to do it in Python, since hopefully that means the majority of Spring community devs can help out.

I'd like it if ZKS and other lobby client devs participated in the queue protocol formation at least. I think it would be good to have a consensus here.

Engine & pr-downloader
If you've ever used the python rapid, you've been quite aware of all the functionalities that the C++ implementation (pr-downloader) has been missing. There's a number of other things I'd like to see a part of the engine and infrastructure, such as validAIs, AI distribution, complete game distribution (where you could specify all the game metadata, such as the required maps, engines and AIs that should be fetched), and much more.

Chili & ChiliFX
Chili is a UI framework of critical importance to Spring, and improving it should be our top priority. We've already introduced a number of commits so far, and I expect to make a pretty big PR (or lots of smaller ones if forced ) upstream so we can all benefit from the changes. That said, it still leaves a lot to be desired, and I'd like to spend some time working on it as well. Another thing I'd like to do is introduce ChiliFX, and create a shader-based library for creating effects. You can see a proof of concept implementation here, but I want it extended so it can be seamlessly used with Chili much like skins are.


There's a lot to do and what gets done will depend on the number and type of participants (e.g. engine, infra, art), but also on the work we do until that time, so if you want to assist beforehand, please check the github repo and join our chat channel.

[Anarchid]

Glorious victory awaits.

[hokomoko]

I'll gladly improve rapid: https://github.com/Spring-Chobby/Chobby/issues/162
Afterwards I'll try to implement my own one-window vision.

[Nemo]

Matchmaking
...
What's also needed is implementing the matchmaking bot. Nemo did some work on that, but I'm not sure in what state it is. If we have to start from scratch, my suggestion would be to do it in Python, since hopefully that means the majority of Spring community devs can help out.

I told you what state it's in: ready for testing, with the exception of group-based matchmaking and more sophisticated matchmaking algorithms than 'randomly 1v1 this group'

Here's a video of it working: https://www.youtube.com/watch?v=3yK7e-82BGA and the repo: https://github.com/kanatohodets/matchbot.

As I recall, the primary objection was to the implementation technology (Perl), not the state of the software.

I started playing around with a replacement (in Elixir) with support for Lua plugins for matchmaking algorithms (since if there's one language we all know, it's Lua, rather than Python), but I parked it fairly soon for more rewarding projects.

Feel free to ping me if anyone wants a hand getting into the code linked above, happy to help.

[gajop]

I'll gladly improve rapid: https://github.com/Spring-Chobby/Chobby/issues/162
Afterwards I'll try to implement my own one-window vision.

Thanks, any help is appreciated. A very important goal of this project is to improve the infrastructure and associated technologies so ideas like "I'll try to implement my own one-window vision" are realistically doable.

As I recall, the primary objection was to the implementation technology (Perl), not the state of the software.
I started playing around with a replacement (in Elixir) with support for Lua plugins for matchmaking algorithms (since if there's one language we all know, it's Lua, rather than Python), but I parked it fairly soon for more rewarding projects.

Hey! I was wondering what happened to you. You're right, the problem was (is) Perl. I also implemented one MM bot in Perl, when the idea was to rely on SPADS for some features. The problem is that without some technology like SPADS (which might not even be that important), it's really not worth for me to be doing Perl, and I feel the need to be able to contribute and not just use.
Elixir sounds nice because of the Lua, but there's also the very important Elixir part, which looks like yet another crazy functional language that I'd explore a bit, do a few tutorials and never really make anything complex with it.
Pure Lua would be nice and perhaps near-impossible without some framework, but Python tends to be like a more powerful Lua that's fairly easy to write, and tends to be readable later. Often when I switch between the two languages I end up mixing the syntax as they're so similar. /languagerant

PS: Think I'll try to use your MM bot to help me develop the lobby client & uberserver stuff first. It's still probably better than my SPADS installation.

[gajop]

We made a new release of Chobby for ZK testing:


While it could technically run on the official Spring server (uber), it wasn't tested that much -> that'll be the goal of the next release (https://github.com/Spring-Chobby/Chobby/milestone/1)

I think it has gone a long way since the last showcase I made on this forum.

[Forboding Angel]

I think it has gone a long way since the last showcase I made on this forum.

Understatement of the decade

[Nemo]

Perhaps foolishly, I found myself writing another matchbot. Third time's the charm! Hopefully Go works for you.

It is still rather messy and WIP (no startscript generation/game starting, or even READYCHECKRESPONSE cycle), but I thought you might have thoughts about the Lua API for the actual matchmaking:

Code: Select all

local players = {}

local function playerList()
	local list = {}
	for playerName, playerData in pairs(players) do
		table.insert(list, playerData)
	end
	return list
end

-- TODO: richer player data structure. perhaps store 'players' outside the lua?
function queue.PlayerJoined(playerName)
	print("I now see a player to match! ", playerName, " ", queue.Title())
	players[playerName] = {
		name = playerName,
		skillLevel = 9001
	}

	local playerList = playerList()
	-- bozo matchmaking: got two players? time for them to 1v1!
	if #playerList == 2 then
		local maps = queue.ListMaps()
		local games = queue.ListGames()

		queue.NewMatch({
			map = maps[1],
			game = games[1],
			engineVersion = "99",
			players = {
				{
					name = playerList[1].name,
					ally = 0,
					team = 0,
				},
				{
					name = playerList[2].name,
					ally = 1,
					team = 1,
				}
			}
		})

		players[playerList[1]] = nil
		players[playerList[2]] = nil
	end
end

function queue.PlayerLeft(playerName)
	players[playerName] = nil
	print("a player LEFT!!!!", playerName, " ", queue.Title())
end

(above is a working prototype, see: https://github.com/kanatohodets/go-matc ... zo_1v1.lua)

queue.PlayerJoined is called each time a player joins the queue; PlayerLeft is the opposite. queue.ListMaps and queue.ListGames should be fairly clear. queue.NewMatch tells the matchbot to go into the READYCHECKRESPONSE state machine for these players, beginning a game if it all works out.

Are there other events that you think merit their own callins in Lua-land? I figured most matchmaking would trigger on a player joining, but I haven't thought deeply about it. Any particular functions that should be available? At the moment it's unrestricted, so the entire Lua standard library is available; the only special things are queue.NewMatch and friends.

The approximate plan is to store these matchmaking lua scripts into a KV database on the box where this bot runs, editable (along with the queues) through some kind of web interface served by the bot.

[gajop]

Hey, I was a bit busy recently and I wanted to read this in detail first, but it still took me too long to reply, sorry!

Perhaps foolishly, I found myself writing another matchbot. Third time's the charm! Hopefully Go works for you.

I don't know Go either, but I already find it readable and being able to write hopefully wouldn't take that much extra effort. So that's a decent choice.

It is still rather messy and WIP (no startscript generation/game starting, or even READYCHECKRESPONSE cycle), but I thought you might have thoughts about the Lua API for the actual matchmaking

A rather simple but general thing I'd change is use .Get* operations for read, e.g. .GetMapList and .GetGameList
As far as actually important thing go, it's probably too hard for me to predict for now, as I have no experience with matchmakers.
It is likely we'll see an evolution of these matchmaking scripts as people start making real examples. I think it's important to be able to write anything so high level of freedom is needed.

There are only a few major things I can see missing so far:
- queue.Update: triggered after a time update. This would allow us to do better (more diverse) matchmaking, especially obvious when there are only a few people. Instead of matching people immediately when there's a minimum number of players, we can wait in order to do get better results.
- queue.TeamJoined: triggered when a team of players joins. It's possible to have only one function, with the .PlayerJoined being a one-man-team case, but teams definitely need to be supported explicitly.
- queue.*Rejoined: a callin used when a readycheck fails, but the player/team still clicked OK. This would place them at the top of the queue (it might be worthwhile having other callins for when readycheck succeeds/fails so the matchmaker can know who played with who).

Another important thing is how elo will be calculated (it'll depend on game and queue type). Should it rely on a third party service, or rather something that the matchmaker supports internally? In either case, we might need the ability to store things, so maybe a very simple API for that?