Hello everyone! Happy spring! What a month… One of ‘those’ months. So many disparate things cropped up, changed plans, tugging in all directions. Even in review, I find myself thinking: “How was this a whole month of work?”
It wasn’t nothing! But I’ll let you decide.
Started the month with 1000 papercuts, ouch.
In the O3DE community, we brought together a task list around what we’ve been calling the “Death by A Thousand Papercuts“. It’s a list of all these little annoying bugs that create pain points, but are mostly avoidable and otherwise manageable. These are those sinister ones that you start to not notice because you’ve worked around them so many times, they basically become invisible to you.
Great for not hindering development progress, but it costs a little each time, and becomes glaring to new adopters. Enough to make them report it, only to get the response of: “Yeah, we know about it. We just need someone to initiate fixing it… buuutt…..”
Not good. Truly, not good.
So in the wake of all the empowering side work I did last month that showed I could definitely just get into random things I was daunted to solve and then actually knock something out, I got the strange motivation to just start trying to see what issues were low-hanging fruit I could knock off the list. Certainly, a lot of them are things that annoy me endlessly, so going after them is not completely selfless.
Well, as I already alluded to. I was surprised that I could actually get to the bottom of these issues and attempt to root them out.
As a start, I just did a flack shot at a bunch of them all at once. Rewarding to be weeding the things out, but it ended up causing a LOT of confusion and conflict when actually trying to handle them in git versioning.
The work ended up clustering in some key places:
I tackled a handful of issues in the “Asset Browser”: Making file navigation nicer, restoring the favourites section, and fixing an issue with the file search that was preventing half the found files from actually displaying.
Next was the “Asset Editor”, the files you could create with the [New] menu were all just one massive list. There was no measure to give them subcategories or nested menus. That was a very good one for me to knock out, because with adding all the GS_Play assets the menu was starting to get very full, and furthermore, I had to add “GS” as a prefix to EVERY asset so you could find them together, and discern which were built in and which were GS_Play assets. We now have our own lovely section for all the GS assets.
Otherwise, I got some file loading and resume things working. All very nice. And working so much with editor assets, a nice gain for my own workflows.
Next was a big chunk of things for the Entity Inspector. It had the frustrating issue of capturing the mouse in a spinner-box field (one of those ones you can slide the [<|>] arrows left and right, and they rapidly slide the number from it), preventing the user from scroll-wheeling up and down in long component lists on the inspector.
Additionally, there were a bunch of annoying Tabbing inconsistencies. There was always one blank ‘tab’ step at the end of a variable row that would make it so you always needed to click one additional time to move to the next variable down. There were some variable fields that were not moving to the next element, instead, just moving back and forth between its first field and second field. All very annoying, and it comes off as half-baked; a poor image for the engine.
Lastly, a bit of a compromise regarding the actual feature request, but I introduced the ability to edit a field, and either [Esc] or [Ctrl-Z] out of it to have it exit the field and reverse the edit to what the value was before entering. It’s not quite, step-per-step undo, where you can make an edit, a second, third, and then undo back through them. But better than total value loss. Definitely feels a lot more concrete when you accidentally mess something up and click ESC, and it undoes what you did.
Tackled some others, but those were some nice big chunks.
Now the versioning grief…
Well. For software development, you’re supposed to make your additions (your pull requests) precise and capture one feature/fix at a time. In this case, I had like 10 different fixes. This meant I needed to make a new branch, bring EVERYTHING over to it. Select only the exact files that pertain to the same fix, and then commit them. New branch, pull everything remaining over, select the specifics.
Fine enough… But these fixes were NICE! So, of course, if I put the work in, I wanted to actually USE the fixes. Especially when I IMMEDIATELY started doing the things I fixed using the old version of our engine and kept getting confused why it wasn’t working.
So now, I had to bring back all the features, now scattered to the wind. Straightforward enough, you just take your working branch, the one you’re definitely not committing to anything, and you go fix branch by fix branch and merge them back to your working state. Easy.
But then, you find issues… and corrections are requested in the PRs. NOW. You have one of two choices: You can edit the fix on your working branch, intermixed with everything else. Then, ideally, step over to the branch and commit it alone. OR, you step over to the actual fix branch, abandoning your entire working environment, and do the work there, ensuring you are working explicitly with the files in that branch.
So many hour-long rebuilds, accidentally committing to the working branch and not the fix branch, file conflicts from things in your working branch that have nothing to do with anything you’ve been working on… It started getting so dubious.
I ASSURE YOU EVERYTHING WAS FINE.
Yes, so far… I haven’t done anything devastating. It definitely revealed to me the value of doing one thing all the way done, then moving on to the next thing. While it’s satisfying to go scorched earth, you then need to deal with the scorching earth…
Perfect. Now that I made a disastrous mess, it’s time to table it and get back to work!
Since breaking into the Graph System last month I’ve been the hammer that sees everything as nails. EVERYTHING CAN BE A GRAPH!
Inspiration took me, and I broke into something I’ve wanted SOOOO bad.
An FMOD killer.
I mean… not so severe, but an audio system for GS_Play that breaks the necessity for using either FMOD or WWise. Sure, those are magnificently complex tools built through years of polish and revision, but for countless projects, you use like… the 3 main things everyone uses them for. Beyond that, there are super niche and specific functions and features that are definitely powerful, but only particularly relevant to more advanced applications, with actual trained audio engineers.
Enter, the Audio Event Graph!
Hammer, meet Graph.
On a roll from the Audio Event Graph, and wanting to capture more general logic behind our GS_GraphCanvas subsystem, I started working out a Hierarchical Finite State Machine.
HFSM’s are graphs, which are not about just executing in a line to the end. Instead, through state conditions, they jump between nodes performing an exit (of the past node), entry, loop, and eventual exit of the current node.
The hierarchical part is that, instead of purely custom-coded nodes, you can also make a state be another HFSM inside. This allows for nested, upon nested, upon nested state machine graphs to run targeted functionality when needed by the parented state machine.
It’s a system that has its uses, and is a very commonly used type of graph, as there are many things that simply need to do their targeted thing, albeit through a dozen complex states, on demand every time.
For us? It’s a much needed upgrade to Movers.
A VERY common use of HFSM’s is for the character movement and action. Running, jumping, landing, rolling, knocking back… All are action states that, mostly, can’t be done simultaneously. In regards to “falling and knocking back” states, you’d do “Falling Knock Back” state, instead of “falling” or “knockback” individually.
This form of character action control is scalable to major games. It is likely used in some of your favourite action combat games. It becomes a massive web of behaviour for countless states of action, really only restricted by the performance of the graph, the number of units with a running graph, and your technical imagination.
We haven’t gotten into the guts of it yet, simply trying to get the “non-execution” mode of its functionality down. But I am very excited for this implementation. It will extend the scope of our character systems to the already implemented small-scale character things necessary for a simpler game like Del Lago Layover, but will enable a far greater breadth of capability to extend into more medium and high tiers of gameplay. Definitely the kind of work I want us to develop hard and fast.
Back to the scorched earth that will not burn out…
Feedback around the first run of papercuts came due, and I found some issues in my own usage that set off alarms… Time to rip the bandaid and un-table the open and raw fix work I had undertaken.
Worse so, I am the one who initiated the effort and got it underway. I am now responsible for actually working out the details… Bleh.
BUT! I also got some merged in!
Boom, Nested [New] Menu Elements: https://github.com/o3de/o3de/pull/19678
Boom, Asset Browser fixes: https://github.com/o3de/o3de/pull/19684
Boom, Entity Outliner Selection: https://github.com/o3de/o3de/pull/19685
Boom, Asset Editor fixes: https://github.com/o3de/o3de/pull/19689
Yusss… Can’t wait, like many of my fixes and additions, for these things to drift off into the past and become completely invisible in the future use of the engine. Never to cause problems ever again.
Speaking of horrible terrifying versioning!
Next on the docket was some versioning work I, 1, shouldn’t have started in the first place, and 2, now have to deal with as we nudge our way closer to a GS_Play Alpha version.
While I was working on our first pass of documentation, I was seeing some features that were already looking dated and needed to be upgraded to the new sensibilities I’ve gathered from growing understanding of the engine. Because of that, besides the stabilization I was doing to actually finalize the documentation, I additionally worked on feature expansion. My justification being that I needed to be able to take fresh screenshots of the new standardized functionality, and didn’t want to rewrite things…
Well, that finally all came due. Now that I have all this stabilization, all this refactoring, all this feature upon a feature, upon a feature; I had GS_Play systems in scattered states of branches of branches of branches, and need to finally consolidate them and return to “main”. That these changes and refactorings are now official and should not continue to scatter into the wind.
Merging SO MUCH critical work was terrifying. It’s a straightforward process, but when your work depends on the previous branch, which depends on the previous branch, and then there are some disparate branches that are kinda abandoned or went in the wrong direction, it starts to get muddy real quick.
So slowly, one feature, one branch at a time, I would go to the most recent branch, and merge it into its dependent branch, then that one into the next, until I hit main. Again, so simple, but the information around: “THIS BRANCH IS DEPENDENT ON THIS BRANCH. YOU BRANCHED OFF THIS BRANCH TO MAKE THIS BRANCH.” is brutally obscure for some reason. So I had to check and double-check that one was, IN FACT, dependent on the particular target branch.
Over the entire like… 8 feature sets I had worked on, my heart was sinking every 10 minutes as I made the final executive decisions to apply the mergers.
Versioning is scary.
All that for?
Well, I mean.. I said it. To prepare for Alpha. But also to bring together the next update for the documentation: Introducing the new graph feature sets I had worked on earlier.
I don’t want to ever be caught again with a month of continuous documentation updating to do, so it’s best to have a policy of making features and then updating the documentation right after to stay ahead of that.
So I got those started. Nothing too exciting there. But good work to tackle.
Now for my favourite part of Month in Reviews!
Alongside the documentation, I ended up chipping at doing some Windows-side QA for our super secret project! It’s still going, still getting more and more refined.
As I talked about last month, getting into the 90% of the 90% of something, to truly polish it for final release, is so hard. Like a hydra, every QA pass reveals one more bug that needs fixing. Every day working on it, a feature we forgot about pops up, then bugs around that start popping up. It’s just whack-a-mole with no measure of when it’ll end. This stuff is why a project ends up double over time. Truly, it’s not even that it’s over time. It’s that it was never actually that close to finishing as one anticipated. Because especially when you have all these revelations back to back, those didn’t magically appear, they were blind spots in the work that eventually needed to be done, no excuses.
Did someone say fear and doubt?
With all this work and hustle this year, trying to prop up Genome Studios as a professional operational company, working out tools, documentation, secret projects… Trying to identify every contact point for opportunities and places we can try to get some traction and, hopefully, make these things actually provide us a living, it starts to get exhausting and overwhelming. Sure, there’s all this opportunity, but there’s no certainty of it… There’s only so much time and effort you can give… You could be completely mistaken…
So I started finding myself losing track. What are we doing, what are our priorities… What do we mobilize around so I can actually start paying people? We’re no longer in the luxury of living off the fumes of passion and creativity. We actually have to perform, create real fuel.
So, as a desperate attempt to grasp on and make sense of my dizzying world of work, I called up a sync meeting with Shauna. We’re both on this sinking ship, we gotta prioritize SOMETHING.
Well, I probably freaked her out with how scattered and uncertain I was entering the meeting… Doesn’t come off great. We took stock, talked about what she wants out of her work with Genome Studios, looked at what we have, what we can aim to do. I didn’t know what I wanted out of the meeting, but we eventually sussed out some solid ground to stand on.
We want to make games. We are building the tech for games. I sincerely believe my tooling, and its growing functionality, is fully capable of building games, starting simple now and only getting more robust and scalable by the day.
There are lots of tangential, parallel, and otherwise available targets to us. Things that we also believe are opportune and could give us a chance at standing up completely. But really, we identified that they are just OTHER efforts that would simply pull us away from that core goal.
It becomes easy to start just chasing a dozen leads, even if pulling away from the core mission, in hopes that it can enable a return to that core mission.
But no.
GS_Play is here; it exists. We are wrapping up the side project, which is definitely complementary to our goals with GS_Play, but definitely due to finish. It is about game dev, it’s about enabling us to be able to make games all we want.
So after some back and forth, me yammering in a cloudy amble looking for some grounding, we really dialled in on what we want to work on and accomplish NOW.
I share this because I think it’s really significant to trust that, as someone responsible for leadership, you don’t necessarily have everything together all the time. Managing the high level, trying to steer the ship, can start to make you lose a grip on the granular; that’s clearer within the cloister inside the ship.
While you may not want to do this all the time, it is okay to rely on your team to help straighten you out and get you back into the clear. I really needed it, and greatly appreciate being able to totally spin out in my grasp of what we’re doing, and be able to find new ground to right the ship through my colleagues.
It’s very important to realign with your goals and direction. Don’t find yourself kilometres off track just because you don’t want to appear weak, or out of touch with the immediate direction you’re going. It’s still strong as a leader to show weakness.
And right off that realignment? Complete Derailment!
A month ago I was invited to speak at the NAIT Level Up! Student Game Dev Conference. I had done so in previous years and was happy to participate this year.
Said so, and never got a reply.
As event day started to edge closer, a few emails in, I reached out on their Discord and found out that they were never getting my emails, which were being sent to junk. Thanks, Gmail.
So to my surprise, I was responsible for tackling a presentation for the conference. So much for working towards our core mission…
I chose a topic that has been very close to me as of late, it flowed very naturally as it’s something I’ve been stuck on for quite a while. Some of it, I’ve already spoken about recently in these past months in review.
82 slides later. I have my presentation: “Don’t be a Trust Me Bro.”
It captures the experience of beginning a field of mastery, game development in its many forms, and humbles you to the harsh realities of truly building that success we all aspire to accomplish. There’s no magic, no mystery, just the actual reality necessary to find yourself with that success at hand through the work you did building up to it. However long that takes.
The presentation at the Level Up! conference went spectacularly; the students were very inspired and excited about the presentation. A long-time veteran colleague said it was the single best presentation on the topic she’s seen in her career. A very proud moment for me.
It is definitely my best, most concise presentation I’ve made so far. By a large margin. I definitely invite you to watch it.
If you feel like sharing it around, that’s also always good for us. Visibility is nice, haha.
Good survived that, now back to the mission.
To further shift into that true, final state of completion for our unspoken project, I started doing some designer outreach/commissioning to bring together the branding and colours for it. Nabbed a very skilled designer, and we’re excited to get into the nitty-gritty of it. It’s pretty exciting to be insofar as to be considering final aesthetic and branding. It means we don’t have a barely started project anymore.
Next:
Oops 1000 papercuts fix messed a bunch of things up. Fixed that quickly, juggling the versioning terror, and am relieved to say they were resolved. Enough to warrant some of the mergers I mentioned above. Primo.
FINALLY. Finally. I got to go back to my actual work.
And work towards that goal of a real and true alpha state for the framework. Many things are close, some are proven, but really need some flesh. And in this case, I really needed to build up a feature set that was one of the earliest in, but hadn’t had any real TLC since.
Phantom Cam!
I LOVE camera work, cinematography, and how much a camera affects the experience of a game. I’ve had so many thoughts on how to really build out the tool set, but time and time again, I targeted other things. Both because they were needed, but also, rotational math, common in camera work, is sooo daunting. Ugh…
So, cameras use a lot of calculation to do all the motions and actions required of a robust camera system. Because of this, I needed to formalize an actual calculation execution order. This is to identify desired placement, calculate tracking, repositioning and things, then step into collision detection, and then more cosmetic ones like noise (camera shake) and any other post-processing.
At face value, it’s a sensible solution. Just create a set of events saying: “Do this type of movement”, then “do the next type”. And that’s a lot of what it is. However, you start getting into interesting situations where you now start needing different position and rotation states from previous stages in the order. Some of them you add to, making the calculations stack, but others need to know what the original desired placement was before, then some need the collision reposition state, and so on.
Turns out that combining 30 different camera movement/position/rotation features together gets a little complicated.
But! We have the first run of a lot of that functionality!
Then the itch took hold…
Took a small break to tackle more painfully needed features in O3DE that directly impact GS_Play features in the long run. This one? Gradient Property and Popup Editor. PR: https://github.com/o3de/o3de/pull/19713
Such a basic need, so I’m really happy with what I was able to get together. It’s mostly done, but needs some final cleanup and hopefully one missing undo step.
Another tangent, brought on by a discussion on the O3DE discord. Render Pass Templates for the Class Wizard. It’s in the cooks right now, not tested as working, but this would bring together the last template I felt is critical for covering O3DE features and development.
Returning to Cameras, as I should do.
Beyond the execution stages of the core camera were a slew of features that I’ve had simmering for a while now. In my professional experience, there were some things I really wanted built to serve some critical, but specific, camera behaviour. Now, solving our own camera needs, I didn’t have to wait for an engineer, I could just go after it!
On the list? Target Groups, and Camera “Tug”.
Two sides of the same coin; camera target groups is a common feature where you track a list of entities, and with some weighted balancing, you target the center of the group with the camera. This enables a lot of control around shared camera space, where you need awareness not just of your character as a central target, but the things around you.
Thinking of a game like the original God of War, as enemies get within combat range, you could add the enemies to that target group, and when you launch a character and juggle them in the air, the group target now tracks you and the enemy, but also doesn’t go all the way; it still has some weight from the enemies on the ground. This allows you to maintain awareness of the status of the ground enemies you will invariably land in after you do your aerial juggling.
This can also be used for shared focus, like during co-op games and things.
Now, this is a great feature, but requires a lot of deliberate command: You need systems to identify targets, add to the list, remove from the list. Or, in the most reductive of ways, already have the x number of targets pre-set and just live with only exactly that.
On the flip side. Camera “Tug” is a reactive and open-ended system. I have been floating around the terminology. It evokes ideas like magnets, gravity, or pull. But I like “Tug” for being very uncommon wording for other systems, preventing overlap with a dozen other game features.
Tug, as the name describes, is a mechanism of pulling the camera out of its standard alignment, like a lasso dragging you from an originating source.
The idea behind tugging is that you can make your cameras reactive to channels of tug fields, making them susceptible to those outside forces to alter the base behaviour of the cameras. Be it ground combat, aerial combat, or others.
An example could be: you have a fireplace, and above the mantle is a portrait, the key element of that piece of level. You should be able to frame it and make sure the player recognizes it as a focal point. In this case, you could always put a stationary camera and blend to it. But often, a stark camera change as you’re navigating an area also means that there’s a stark blend back when you shoot past the camera field and exit it faster than it repositions the camera. Otherwise, a survival horror, hard camera cut isn’t always appropriate for your game.
What if, instead, as you get closer to the fireplace, it tugs harder and harder towards the portrait, and again, as you veer away from the fireplace, the tug weakens and finally releases the camera back to its original state. This then allows for a more organic and situational adjustment to the camera that doesn’t necessarily need an entirely uniquely authored camera to work. You can preserve the usage of your core character camera, while still modulating it in a controlled way for situational needs.
Now returning to high-action character combat scenarios. You’re highly mobile, the arena is expansive and complex… Today, that means you’re fighting in a desert and are being swarmed by enemies. Just then, a massive sandworm comes blasting out of the ground, the first reveal of a very critical boss/hazard/enemy. You don’t know where the player will be at this reveal, you don’t know which angle their camera will be looking, you don’t know which state they’ll be in, like air juggling an enemy.
Sure, you could have a “Look at the focal surprise enemy” camera. Countless of them configured to every special reveal and telegraphed enemy attack state. Or, you could give that sandworm a Tug field. As big as the entire level, even. Like an AoE, it would hit your camera in any state whatsoever and pull the attention of the camera to the worm, for that brief reveal. As it returns to the sand, and the gameplay resumes its normal flow, the camera snaps back to what it was in the middle of, and you’re back to the play.
This, like I alluded to, also applies to special attacks. Like some enemy charging a massive level-wide explosion that you need to interrupt. Use a more gentle tug, but ensure the player knows the enemy is doing it as it engages its nova attack telegraph. Situational, reactive, and additive. Tugs, to me, are an incredibly valuable subsystem for cameras to enable very precise authoring for designers, along with the rest of the palette for painting beautiful cinematic experiences.
Very excited for these.
Accounting for some Accounting
Mobilizing again around our effort to tackle some corporate accounting and apply to the SR&ED tax rebate program, I mobilized for an upcoming meeting and spent a whole day cataloguing the game development things we’ve done for the past year.
That was a doozy, but spared us covering menial details during the upcoming sync meeting. Was arduous, but good to frame it and get it detailed and clear for the accountants.
It was a whole year, but scrubbing over it in a rush made it all feel so small, despite being 365 days of work and struggle and fear and doubt… Funny how being past it makes it so inconsequential when, during the time, it was the whole world in its impact on us.
The meeting went well, got to get into the fine details to fill any gaps in my report the day before. I got to regale the tech representative with wild stories about how everything works in the engine and among our tools. Always fun to be able to share in the excitement and unique details of working with O3DE and in the deeper realms of a game engine in general. It’s also refreshing to notice that it’s still so much fun and exciting to be doing all this work, enough to still have a joy in covering it during a process of satisfying an agenda of evaluating every moment of your year for government scrutiny.
If I can properly follow through on this application, it’s definitely looking very promising that we’ll get a solid return and could possibly actually get a wealth of liquid funds for Genome Studios to use. I would relish being financially decoupled from the business; so far, everything I do has to be squeezed for every dollar, and I have to live very sparingly to afford it.
However that plays out, I think it’s so cool to be working on bleeding-edge technology, enough to be able to frame nearly all our work as brand new development and technology. Having such an intimate knowledge of the engine, taking part fully in the community and ecosystem around the technology, and being able to make all the game development technology I can spend the time making… It’s a really cool field of work. Even including the scary business things; legal, taxes, finances… It’s living the dream.
So, back to your regularly scheduled complete derailment!
To the ends of furthering that scary business stuff, we as a studio still need to be mobilizing around outreach and client acquisition. People won’t buy GS_Play if they don’t know it exists or that developing on O3DE is possible.
Cue the hardest most scary part of studio ownership: Networking and Outreach during conferences… Yuck.
I had registered for a raffle to attend the North American Games Industry Summit being held this year at Game Con Canada here in Edmonton. I was mostly going to dodge this, as I do most conferences, as we don’t have a game far enough along to start reaching out to investors and publishers. However, something stuck out to me. They specifically state that the summit welcomes “Tools & Services” providers. Now THAT, is something we can mobilize around. And it makes sense, you want to connect developers with technology, investors with prospecting engines… Sell more people on FMOD…
And so, Surprise! You get conference tickets!
Well, THAT lit a fire under me. So I immediately scramble to get the website, company, branding, everything shored up and ready to impress.
And as the word impress describes, I really wanted to plan out a way to leave a lasting impression. This involved looking into getting new business cards, and, alongside a successful negotiation or discussion with a potential client, deploying some premium merch for them to take home. Not just a lanyard with the other 400 lanyards you get during a conference. Some actual functional, desirable swag that would ambiently leave Genome Studios in your mind during your day-to-day happenings.
Dove into budgeting out a merch run, I saved the cost of the admission ticket, so that already leaves me with some funds I could argue spending. It’s great looking over cool swag and imagining having it and being ready to deliver on a strong start, strong mid, and strong finale to possible client outreach. You look over bottles and bags… I found some med kits that would have been so cool to get… But reality is a lot harsher than that whimsical world of what if. The minimum quantity of the run, the base pricing for things without a bulk discount due to the small size of the order… All in all, it was fun, but scary and will be expensive, even when modest.
For fun, look at all these mocks! So cool! It’s been about a decade since I did my last Genome Studios merch run. These’ll be some serious collector’s items!
Since then, I landed a local print shop that is aiming to match the budget, so hopefully I’ll get better stuff, and still stay within my kinda reasonable budget.
But that’s not all!
This provoked me to really revise and rewrite the messaging behind the company website. The core is there, but the most recent website development (like 6 years ago) has a very passive and non-committal language to it. I wanted to capture that original intent, but lay it with a confidence and direction that I’ve gathered through experience over the years. To properly reflect what I’ve preached about around being a Trust Me Bro, and actually follow through and bring out the best in the site, in the messaging, and the rallying call for any potential clients.
Not quite through because now I am looking into every design choice and colour and margin and spacing on the entire site, but happily underway.
Then to the ‘Networking’ part…
In anticipation of the event, I also started looking into the Conference “Meet To Match” program. I thought “Meet 2 Match” was a format, like a style of program: “We host a meet to match program so you can meet other developers and investors!” No. It’s actually a corporation, a service that events and conferences deploy to provide actual matchmaking tools used commonly in the biggest and baddest cons and summits. So that was revealing…
Never done it before, so I was so confused with logging in and how to access it to make my profile and fill in all the details. Resources online insist that it’s critical that you set up your profile quickly and put your best foot forward. Tight, direct, precise. This is what provoked all the revisions to my messaging on the website.
But there’s this frustrating, and in my opinion, stupid, implication. There is, like, no information on actually using and doing the Meet 2 Match things. Like. Actually taking part in the system.
It’s not like Tindr, you don’t just pull up the app on your phone and make an account and profile, and now you can get after it. Turns out, you get a unique login deployed to you near the conference date to set up and start matching before the conference starts. This is to set up meetings, pitches and discussions in the networking plaza ahead of time to work out during the summit.
Makes sense, but I hate it for being my first one. There’s this air of like… “Of course you know the meet to match deal, it’s like every other conference. What are you, dumb?” Because it’s staggeringly difficult to actually find out how the stupid thing works. The Meet 2 Match app, and whatever I looked up, has no info on the steps and process. The NAGIS site has no instructions, but I’ll give them the benefit of the doubt for being their first one…
But after all this struggle, I still have no idea what to expect out of the actual interface. What is needed to fill in your profile IMMEDIATELY upon getting access…
I don’t want the profile to be incomplete, or worse, poorly realized, and have people swipe left…
So yeah, for YOUR knowledge:
- You get your ticket for a meet-to-match-enabled conference. It has nothing to do with meet to match yet.
- Download the mobile app and set up your generic Meet 2 Match account.
- Research how to format your profile, what to include, all that stuff and pre-prepare.
- As the conference date comes close, you will get custom login information for THAT specific conference’s Meet to Match… system.
- In the app, you can then select, in this case: NAGIS, put in your login info, and then..
- ???
- Profit.
Holy cow, ugh, okay, what’s next?
It’s the end of the month! Yaaaaay…
What a wild ride.
So much demand this month has me spread real thin. Many real tests of what it means to be a professional, a figure/advocate for your community, and business owner. If you plan to play the game professionally, you gotta really play the game.
We now have the precedence of a standard of quality that I’ve set and now can’t pretend I shouldn’t apply to everything I, and Genome Studios, do. So much this month feels so disparate from our core goals, but we’re getting through it, we’re making opportunities and really giving our best.
I can only hope that all this effort brings us, slowly and steadily, towards a strong standing and truly realized company.
Well then, till next month! See you then!
But actually.
Btw, you can now rep Genome Studios on Discord with our brand new shiny server tag! Every bit counts!
P.S. Did you know you can keep up with our Month in Reviews by signing up for our newsletter? Just check below!
Want to keep track of all Genome Studios news?
Join our newsletter!













