2.7 KiB
| title | date | draft |
|---|---|---|
| Esports Post | 0000-00-00 | true |
Esports Post
So for the past week or so I've been deliberating progress over an e-sports related project of mine: scuffed-league. The whole idea here is that I like tournaments I still believe that proper long-running leagues are the preferable choice for keeping spectators and competitors around for long periods of time.
The plan for building
Let's go through the process of building from start to current.
- I wanted to replicate the experience of using sites like cevo or esea from my own competitive history but, those have had years to build and mature.
Something which to be honest never really struck until I had built a few bare pages. I say bare because quite frankly, every page I made had nearly no content to show for. It was also unlikely that I was going to be able to fill them with content for a long time.
Issue: cevo/esea/faceit all support multiple leagues, with multiple divisions in multiple games with multiple tournaments and prizes, news, drama, editors, etc. There was no way I could fill all these things like a full team of content creators could.
Solution: Start with one game, Diabotical with one league with one division, and a second game mode.
This meant that I could make a memeone-page webapp thing.
As the name implies its literally one page which makes it really easy to fill the page with content.
At my scale the amount of content I have to serve up is so small that things shouldn't feel cluttered but will still feel like there's a lot going on.
- I have some data to store and some of it is really strange do I go with SQL, Redis, Firebase, what?
Some data fits really easily into a table: like user data. Every user can be part of 1 team-league 1 duel-league and then has some basic info about them username/password. Jam that into a table and its easy to query, update, and remove users.
Even the team data isn't too bad: captain|member2|member3|teamname|?. The only issue is the match data.
The problem is how we store match history.
- I have to store match history for each team and it has to relate to other teams as entries could be related to one another.
If that prompt makes it seem like each team requires a structure to hold previous matches then you would be right. If I had gone with this question to answer it I would have ended up with a really weird system where I would have to cross reference things in multiple databases and then worry about huge latency.
Reframing the question to "What data does 1 match really have". To actually get to this point however I had to go through a few iterations of holding match data.
