By the time Wednesday had come this week, I was ahead of schedule for the first time in this self-imposed ten-week pre-beta crunch process. I only had two main items left on a five-item checklist, and I could see my way clear to actually reaching the weekly stretch goals I had set for myself. I blew it, kind of, by spending Thursday on an unrelated but still important part of the game, the Livery page where you choose your team colours, jumper design etc. I have poured weeks into that page, and one more day wasn’t going to get it finished. Bit of an L by me in terms of short-term time management, though it will all be worthwhile by the time the release comes around.
Monday was the long-awaited (by me) commencement of the Property scene, and it went about as quickly and smoothly as I expected. This is where you merge, split or sell items; you need six of an item to merge it to form the same item with one higher star rating, plus a few credits. Items are mostly dropped in Campaign mode, with frequency based on ye olde 4D6 rolls modified by the match result.
The design takes Star Trek Timelines as a starting point and then iterates in different directions, which is true of a lot of features of Mr Football. STT also has star-rated items with varying levels of rarity earned mostly in missions, drawing deeply on the near-limitless geeky lore of Star Trek, but you can’t upgrade or downgrade them. STT’s system enables their developers to hide certain high-demand items behind paywalls, restrict their availability as rewards for high-level missions and/or requiring interminable grinds. This is part and parcel of the design of a hero collector game, to be fair, but I think it’s less stressful and off-putting for the coach if they can see that every item is reachable for those staying in the free-to-play zones.
Similarly, the Procurement scene uses STT’s Faction Centers as a template for an item/card shop, with plans to extend the concept to take into account newer trends in popular mobile games. Building this scene also required the creation of a live.json file, an asset which will be updated daily as part of the post-release Live Ops weekly content pipeline. More on that later.
This is where my concept of sequences (mentioned in the original beta post) makes a lot of sense in context. The Property and Procurement scenes are intended as a support feature for the List scene, so it is natural to code them from Phaser wireframe stage to Firebase-supported beta level in the same order that coaches travel through them. Items are mostly used as part of the player levelling process, though they will also come in handy for certain event modes like the Drive. This means that completing the item-related features across several scenes will finally enable the ability to take a player card to Complete status, so that you can store it in the Scrapbook for the rest of the Season and work on newer cards.
I might have gotten all the way to the Scrapbook and thus to the end of my weekly sequence list, had I not “wasted” that Thursday. It will have to wait for week 9.
There was also some time spent on Thursday moving some functions out of single scenes and into the BaseScene to enable cross-scene usage. It is possible to import functions from other scenes as in this example, as scenes are just classes, but I choose to use the BaseScene approach to keep things cleaner and better organised in my head. The naming convention I am using for these cross-scene functions, for which I pass an object in and then return it out again, is draw for adding display elements to a scene and then paint for setting different styles to those elements. I use this convention now for the team shield, team jumper and item elements, with a multiplier passed through as well to set the size.
There is a pleasingly large amount of single-underlined items in my colour-coded spreadsheet this week, denoting those that were iterated during the period, and only two double-underlined which indicates I didn’t get to them in time.
It may seem a bit late in the piece at week 9 of 10 to still have the Match Modes and Journey Modes lines mostly coloured in green and blue, but the vast majority of the work went into the wireframes and the match code itself, which has already been done. This pre-beta period has been mostly about cleaning up Phaser bugs and implementing Firebase integration, the latter of which for an old LAMP Web developer like me is one of the easier parts of game development. The front end is very challenging for me; the back end of database and server function design less so, though maybe that’s false confidence before I have to actually test my systems with (hopefully thousands of ) live users!
On that last point, one of the more ambitious parts of the Mr Football project is my plans to run a live ops game by myself. I don’t really know of anyone else who has done this solo… though I don’t know of anybody else who made a Web site like FanFooty by themselves either, so that doesn’t mean it can’t be done, and if it can be done then I am the sort of person who can do it.
My wife asked me what my expectations are for revenue in the first year, and the simple answer is that I just don’t know. It could be a very long grind, like FanFooty was, where it took five years to grow into a fully-fledged business earning enough regular money to sustain my lifestyle. It could be an overnight hit, which I hope is more likely given how many years I have been cooking it. My plan has always been that the grind is actually in the past now… that grinding is what I have been doing all these years pre-launch, using every spare moment to advance the project. Perhaps it will prove to be folly, but my intention was that Mr Football will get to break-even in terms of my time and effort much more quickly after launch than the bleeding-edge early-released FanFooty did.