Tabletopping your game

        I am doing a podcast with my friends about games (check out The Adventure Mechanics here) and I decided that I need to try for accountability on actually releasing a game. To that end, I'm going to go through the development process to release a game. Here is the transcript from the fifteenth episode on making paper versions of your game first:

 Welcome to another Adventure Mechanics side quest. I'm Chandler. I have been getting swamped by the overwhelming nature of Cartogratour lately. In an attempt to still make forward progress, I have been trying to break down the game into all the smaller mini games that will make up the bigger game as a whole. Even that's has proven to be a problem for me, though. I keep getting stuck in the development swamp, not sure if the game I am making is even fun. So, I'm going to try something different with the mini game I'm currently working on: I'm going to make a paper version of the game and try it out before spending time committing it to code.  In this side quest, I want to talk about prototyping your digital game on the table first.

So, what does that mean? If it's a puzzle game, that means building and testing them using tokens and board game pieces before you put them to screen. In some other cases, you may be able to proof out the game using just a deck of cards.  For one game jam, the team I worked with did exactly that. We pulled out a set of playing cards and made a game using those cards and a couple of tokens.  It was fun to play in person, too!  The rest of the jam, everyone had a better idea of what the game was supposed to be because we sat down and hashed out all the details beforehand.  In the end, the trash talk from the table didn't get included for the AI we put in, but the core was still there.  Not having trash talk, along with poor instructions, made the digital version confusing and feel kinda flat, but it was amazing to play test the game on night one of the jam.  I'll put a link to what we made in the show notes, but that experience turned me onto this methodology for testing game concepts.

What games can be prototyped like this? It turns out a lot.  If you haven't seen how the original Super Mario Bros was developed, each level was plotted out on graph paper and checked against the constraints before they could be coded into the game.  Everyone had a chance to look at it, see where it wasn't going to be fun, and adjust parts to be able to fit into the tiny amount of memory on the original Nintendo Entertainment System.  By the time they were play testing the game, the team had confidence that each map was going to at least keep the flow of the game, if not be fun.  Keep in mind that at the time, they didn't have the same type of tools that we have today.  Committing to code wasn't as fast as mocking up a pre-fab and pushing it to the scene.  It took more effort to put it in, so making sure it was the way you wanted was more important.
 
Another, probably more obvious, example is Civilization.  The Civilization series centers around the 4x genre; Explore, Expand, Exploit, and Exterminate.  This obviously lends itself to converting to tabletop, since the game that it is famously named after started there.  New game mechanics can be tested and refined in a night of gaming, instead of waiting for weeks to have features implemented. Moreover, developers can set up a specific situation to really test a scenario over snacks.  No one is spending huge amounts of time doing a rudimentary implementation of a game before seeing if it's fun.  It also allows for rapid iterations to see if any tweaks are necessary as you adjust rules to better match the game loop you want the player to experience.

One other, possibly less obvious, reason to make a tabletop version of what you're building is to see if it's engaging.  As Mark Darrah of BioWare fame mentioned in his talk, Will it be FUN?, it can be used to test seemingly inappropriate types of mechanics, such as real time melee combat in an adventure game.  At the end of the day, whatever you end up with for your combat system, you'll have to come up with a model, or some other way to represent it.  If that combat can be represented in some way, it can be represented on the table.  It doesn't necessarily have to exactly be represented on the table, either.  If your combat relies on percentage, you can use two d10 to represent that, or use opposing card draws from a deck of cards.  Whatever you can use to get the same expected feel with a given mechanic will work.  The point isn't to make a full blown tabletop version of your game, but rather to only test to see how engaging it is, or can be.  At the end of the exercise, you should expect to set aside what you build and start work on implementing it digitally.

So, why do this at all?  Well if I haven't convinced you that there is value in examining games, or even single mechanics, before implementing them, I suppose that's your perogative.  Planning out something and getting iterations in when it's relatively cheap will make your game not only better, but also faster to finish.  If you are on a tight budget, or have extremely limited time, spending some time on a table version of things will make your vision more clear earlier in the project.  And that's the point.  I'm not advocating that making a tabletop version of you game will be the magic bullet you need to get you game done.  Far from that.  It's only a tool to explore what you want to make, and maybe expose a flaw in it early.  Like all tools in your toolbox, it's up to you to make use of them, or not.

Now that I've convinced you of at least the value of tabletopping your game, let me talk about how I'm applying this to Cartogratour.  I am currently working on the gardening portion of Cartogratour.  I plan on planting and harvesting being a story point in the game, so I need to have it be engaging.  I examined gardening and farming that a few other casual games, especially ones with a larger focus on story telling, but none of the minigames on farming were really what I was looking for.  I decided to take a mechanic from one of the tabletop games I play with family.  In the game Patchwork, each player is trying to build out their quilt using pieces from the center to make their blanket with as many buttons and as few holes as possible in order to win.  For my take on gardening, I wanted to evoke the feel of getting into your garden and really planning it out, making sure that each plant is getting it's proper framing and can really shine in context.  I didn't see any real incentive for aesthetic consideration in any casual slice-of-life game, so I want to bring that in using the quilt building mechanic in Patchwork.  Instead of building up the quilt, however, you're building up a garden bed.  Each plant will have it's own requirement, and each garden bed will have it's own conditions, including shading and types of soil.  All these considerations will determine the ultimate value of the garden.

That sounds ideal to mock up on the tabletop, doesn't it?  In my initial test, I'm setting up a static version of the garden plot and trying a few different plants, with different layouts.  For the layout of each plant, I'm envisioning that each will be something similar to a tetrimino.  You know, the tetris pieces.  This will force the player to make less than optimal choices and enable a sort of high score for a given garden.  I'm not quite sure how shading will be visualized, but I am going to start with a card that is drawn to give a quadrant that is shaded on the plot to start off with.  My initial plan for scoring is to score each plant in it's ideal conditions, matching the soil types, along with shade requirement.  If there are any blank spots in the garden, that will be some sort of point penalty. Once I have all of these mocked up on paper and play test it a couple of times, I should be able to see if the game is engaging.  I'll let you know the results in a follow up episode.

But, that's enough about tabletop testing your game.  As always, if you have suggestions, observations, or any other thoughts on this, leave a comment or reach out to me on Twitter.  My handle is @jcsirron.  This has been another Adventure Mechanics Side Quest.  I'll talk to you next time.

Accessibility

       I am doing a podcast with my friends about games (check out The Adventure Mechanics here) and I decided that I need to try for accountability on actually releasing a game. To that end, I'm going to go through the development process to release a game. Here is the transcript from the fourteenth episode on accessibility and including some in your game:

 

 Welcome to another Side Quest for The Adventure Mechanics.  I'm Chandler.  Today, I wanted to spend some more time talking about another topic that we brought up in our Deadbolt episode; Accessibility.  The core of accessibility is making the game available to the widest number of people possible.

This isn't the same as approachability, however.  This is, you know, making the mechanics and gameplay clear and understandable.  There is a case to be made that accessibility and approachability are, in fact, the same thing, but I don't think they are.  It is possible to make a game's controls and visuals accessible to everyone, yet still be obtuse and have topics that make the game almost completely unapproachable to most people that try to play it.  A walking simulator that tackles tough topics, like a person's role in society or one's own mortality would be a good example of what I'm talking about.  If you think I'm making a distinction without a difference, let me know in the comments.

With that caveat out of the way, let's talk about accessibility.  I know this can be a somewhat contentious topic, with many erroneously claiming that making things more accessible will somehow compromise the developer's original vision.  I'm going to state right now that this is nothing more than a red herring.  As the industry currently stands, there is nothing preventing a person, company, or entity from making a game that only people in peak physical and mental condition can play.  Flashing lights, quick time events that demand millisecond reaction times and more can all still be developed.  The fact that we don't see many commercial games that do this is rather telling, however.  There isn't much incentive to do so, outside an intentional or artistic statement of some sort.

Moreover, those who are arguing that making a game more accessible only diminishes their experience in the game are arguing in bad faith.  The fact that they are arguing that a game can make them feel lesser somehow if it includes things like a difficulty slider or a color blind mode, indicates that they are projecting onto their hobby far too much.  Developers are more than capable of both including modes or features to allow those with disabilities to play and enjoy the game and not ruining their vision for the game.  Sometimes those features added even add to the game and make it more enjoyable to play, such as the high color blind mode in Fortnite.  Blending in using ridiculous skins may have been an unexpected feature in the game, but not everyone was capable of seeing them.  The fact that color blind mode began to be used by those without colorblindness to combat the abuse was just a happy side effect. Having a hard game for the sake of being hard is one thing.  Doing so to make players with fragile egos feel better is a whole other ball of wax, though.  You can add in, or exclude, features to cater to both your goal of the game and include more people as well.

So what do I mean by putting in features?  It could be something as simple as having textures or patterns to go along with colors so that players with color blindness can play your game.  It won't cost much more in terms of design time and you aren't limiting your game to those who can see colors the way you intended.  In this example, if color is paramount AND you can't put in a pattern as it would ruin your aesthetic, just be absolutely aware that you're cutting out potentially up to ten percent of the population with a bad implementation of your aesthetic.  In indie game terms, ten percent more or less sales could mean the difference between a successful release and failing as a development company.

Now, that's not to say that your implementation will be so bad that color blind people won't be able to play your game at all, but I use it to illustrate a point.  Disabilities, such as color blindness, low vision, and deafness are all things that you at a minimum consider while designing.  It doesn't take much to walk through what you can accommodate and what you cannot in your game.  Is a quick-time event really the best way to get the player to feel that emotion, or can you put it into a cut scene?  Is it really that hard to put in closed captioning into your cut scenes?  These are the type of questions that you should be asking as you design.  If you are adding these in at the end of your development, you are too late.  A bit of foresight will do wonders to make sure that your game can be played by as many people as possible.

As I point out ways to change your game, notice that I haven't touched on anything that changes the difficulty of the game.  At all.  That's because I'm just looking at the low hanging fruit.  With accessibility in mind, you can go to town and tune your game into a game anyone can play.  Or not.  It's entirely up to you how much effort you put into including everyone.  As you design your game, however, remember that all design changes that you make can be a barrier you're putting in for someone that wants to play your game.  I, personally, don't want to be responsible for causing someone to have a seizure, so I don't include many rapidly flashing colors in my games.

So far, I have only pushed for accessibility from the money perspective.  Let's say that you don't care if many, if any, play your game.  You just want to make it.  Good on you.  I get the feeling.  You should still at least look at making your game at least somewhat accessible.  Good art strikes a chord with those that engage with it, and not everyone is you.  Art games have a different audience, even if that audience is a population of one.  Getting your vision or point across to that one person is still the point of an art game.  Making a game accessible will only help you get that vision across.  It's still worth spending time to consider things that make your game easier to engage with.  Like a handrail on a ramp, not everyone will need them.  Those that do will certainly appreciate it, though.

Obviously, this is a deep topic and can take a developer deep down a rabbit hole trying to accommodate everything possible.  I am not advocating for that here, but I do want to bring it up, since whether you like it or not, putting accessible parts into your game will change the way a non-trivial amount of players view it.  When I playtest my tabletop games, if my prototype is not color blind friendly, I don't have nearly as many play testers as I would otherwise.  It may be shallow of me to say it, but losing those play testers makes my game objectively worse.  Not only do I lose their input, which could be the change I need to take my game from good to great, but I am also souring the well to be able to use them in the future.  That's a straight up lose-lose for me.  Your experiences may vary, but I would be surprised if you didn't run into at least one person that was disabled in some way in your playtesting group.

This is absolutely not all that I could talk about in terms of accessibility, but I feel like I have done at least a good introduction to the topic.  As always, if you want to talk about it more, think I missed something, or just want to comment on this episode, leave a comment on this episode or reach out to me on Twitter.  My handle there is @jcsirron.  I'm still Chandler and thank you for listening to this Side Quest.

Achievements

      I am doing a podcast with my friends about games (check out The Adventure Mechanics here) and I decided that I need to try for accountability on actually releasing a game. To that end, I'm going to go through the development process to release a game. Here is the transcript from the thirteenth episode on achievements and putting them into your game:

 Welcome to another edition of the adventure mechanics side quest.  It's me, Chandler.  Today I want to expand on a topic that we got side trackedo n during our Deadbolt episode:  Achievements.  You know what I'm talking about, the little toast that shows up seemingly randomly while playing a game.  The strange ways to play games that the developer thinks that you should do to truly "complete" the game.  They seem so straightforward, yet their simplicity belies the massive amount of effort that goes into creating them.  Make trivial ones and your game feels like it doesn't take achievements seriously.  Make achievements impossible for all but the most talented players and you make your game unapproachable.  Let's talk about some of the considerations that go into designing achievements so you don't end up alienating large swaths of your audience and taint their view of your game.

First of all, let's go ahead and actually define what an achievement actually is.  Achievements are essentially challenges in the game for bragging rights of some sort.  They've been around since at least the Atari era, but they really came into their own when they began getting tracked on the XBox 360.  With that, you could really show off what you've done and rub your achievements into the face of that kid that always claims to have beaten every single game you bring up.  Ever.  Or so I'm assuming.  I never actually got into the XBox 360, so my first experience with achievements was through using the PC gaming service, Steam.  Whatever the bragging right, achievements getting tracked forces game developers to consider what is worth implementing as an achievement and what is not worth tracking.

As Devon mentioned in our Deadbolt episode, not all achievements are created equal.  Some achievements focus on progression, especially for story-driven games.  Others will focus on challenges that the player must complete in order to get.  They can veer into the absurd and have the player searching for trinkets or other things and find them all.  Since achievements don't have to fit into the game's world, they can get the player to do things outside the game as well.  For the sake of this talk, I'm going to break achievements into three main categories:  Progression achivements, where the player is likely to get them as long as they are playing the game, Challenge achievements, where the player must do something difficult to complete, and Meta achievements, things that aren't necessarily challenges or story progression, but still are ways of interacting with the game.

As we start talking about achievements, let's step back and ask about how often to use them.  Ideally, they should be uncommon.  They should be a surprise that the player stumbles across while playing the game.  If the surprise is too common, they won't really be surprised by them.  Tripping over them will make it feel like achievements don't have value to them.  Done poorly, it will feel like walking through spider webs; you just can't get away from them and they're always in your way.  Don't make your player feel like this.  Let's talk about the types of achivements now we know to not use them too much.

Let's start with progression achievements.  These are the most straightforward.  When the player makes it to a certain beat in the story, they get the achievement.  As long as your game is broken into chapters, acts, or whatever, you can tie achievements into these sections.  And since achievements are typically tracked, this provides valuable data points from your playerbase.  Is everyone making it to the end, or is there a sudden drop in progression achievements after a certain chapter?  You can use this data to change the way that area plays or make it easier to progress in some other fashion.  You don't necessarily have to change anything, either.  It's just valuable information to have to make sure you're both serving your player base and the story you've created.

Next up, we have challenge achievements.  These are the achievements that are for the those that love your game so much that they need more of it in some fashion.  The story of the game is over, but they can still go through and beat it in a different way, or faster, or whatever.  These are a bit harder to implement.  They need ot incentivize the player to do something , but they can't be so hard that no one can achieve them.  Requiring a world record speed on your game isn't reasonable, but on the other hand, requiring the player to do something trivial isn't reasonable, either.  Challenge achievements must be balanced to a difficulty slightly above the average player's capability.  Challenge achievements should not end up in tedious fetch quest style missions, however.  No one really likes killing the same thing over and over and incentivizing the player to do so with achievements only crystalizes that.  Tedium is not fun, no matter what pat on the back there is at the end of it.

Then we have the last category; Meta achievements.  These are achivements that aren't like the other two.  Defeating a specific character or monster with a comedy weapon, doing something specific on a specific day, or something like watching ads *shudder* can all be meta achievements.  The player knows that they're not part of the world and they're doing something arbitrary just for the sake of achievement hunting.  These types of achievements are the most challenging to pull off and should be used the most sparingly.  You don't want to pull the player out of your game and these types of achievements do exactly that.  If you want the player to experience something specific, then put an achievement in for it.  You must control the urge to put in a large number of these, though.  You can inadvertently make your game another progression path by doing so.

Let's talk about the other part of meta achievements, though.  If you need players to watch ads to make money, for the love of whatever diety you choose, do not make it an achievement!  This signals to your player that you don't actually care about them.  You only care about their eyeballs for money.  While this may be true for you, coming out and saying it poisons the well of players before they give you their attention.  Another way to alienate your playerbase is to wall off achievements in some way.  I'm talking specifically about date specific achievements or one time achievements.  If you want your players to do something on specific days, you can.  Doing it through achievements is not the way to do so.  If you force the player to be online at a specific time (and perhaps only at one opportunity), you're going to annoy players.  This shows to your player that either you didn't think out your achievements, or worse, you're an arbitrary and capricious developer.  Challenge is fine, but time-limiting something?  It's just not worth it.  Give players multiple chances to get something, even if it demands they play through again.  I guess i'm saying, just don't be mean to your players, as tempting as it may be at times.

So, what's a developer to do with these three types of achievements, besides use them sparingly?  Use them to get the player to interact with your game in novel or strange ways.  Get the player to be delighted when they come across an achievement.  If they've already peeked at the list of achievements, make it a puzzle that they must solve.  Make your achievements interesting.  Show your players that you respect their time and you want them to play it more.  There's a lot of examples of doing achievements well, and even more that are garbage at it.  Do  they add anything to your game, or are all of the ones you can think of boring and tedious.  Unless you plan on releasing to a platform that requires them, consider leaving them out.  As with any creative medium, one thing may not fit a given design.

Although I have more to say about achievements, I think this is a good spot to stop for now.  As always, if you have any thoughts, comments, or whatever, reach out to me on twitter. My handle is @jcsirron.  This has been another adventure mechanics side quest.  I'll talk to you next time.

Momentum

     I am doing a podcast with my friends about games (check out The Adventure Mechanics here) and I decided that I need to try for accountability on actually releasing a game this year. To that end, I'm going to go through the development process to release a game. Here is the transcript from the twelfth episode on momentum and how to keep it going for a project:

Welcome to the adventure mechanics side quest and it's me, Chandler. With the holidays in the rear view mirror, I've come up against this unenviable situation: I've been officially working on CartograTour for over a year. Sure, I haven't worked on it as much as if it was my day job, but I still haven't gotten nearly enough of it done. I've taken a look at my version control history, and, I've got to say: it's a sorry sight. There are periods of manic pushes coupled with rather large swaths of... Well, nothing. Some of those lulls were due to personal issues, but most were due to lack of inspiration. I had trouble refining the main gameplay loop in my head for quite some time. I have only recently come up with other things for the player to do that fit diegetically. With those last pieces in place, I think I have a relatively good foundation to start executing on the game. Artwork continues to be a struggle for me and sound design hasn't even come up, yet. That being said, those things aren't something I had to focus on quite yet. But now the project is now to the point where coming up with ideas is finally ending and it's time for me to look at something I haven't really done for a game: production. For today's side quest I'm going to talk about production and keeping momentum going on a project.


Now, I know I just did a side quest on motivation and you may wonder why I'm talking about momentum. They're roughly similar in terms of goals and results, so why focus on something so close to it? Well, honestly, it's because of the difference between the two: motivation is about starting, momentum is about continuing. That is one step closer to the end product, after all. More importantly, that's what you need for production. All of it is in service of that end goal; getting the game out the door and into your hands. Motivation is the micro issue every day, momentum is the issue for every update. I'm not going to be obtuse and say it's a macro issue, but it is certainly an issue. Without momentum, you can easily get stuck in "the swamps" of game design. And, oh boy, you do not want to get stuck there. Trust me.


First, let me clarify what "the swamps" of game design actually are. They are the time between first prototype and final polishing. That time where you're not quite sure the design is actually fun. You're in production, yes, but you're not done with tooling up, yet. These are times where momentum is absolutely sucked from you. The swamps may be short, or they may take a long time. Bioware programmer and producer Mark Darrah somewhat loathingly describes the end of the swamps as "Bioware Magic." This is that magic point where productivity shoots through the roof and the roadmap to finish the game finally hits something more realistic than finishing a decade from now. Now, to be clear, that typing point is also a sign of crunch in a team and I highly recommend listening to his reasoning why you shouldn't use the term "Bioware Magic" at all, but that's not really why I brought it up. It's more so because of that time before suddenly becoming more productive. The times where you're struggling to find the fun in the game, to get the real core of what the game you are developing should be. Time in the swamp can be short, or it can be years. How can you avoid, or at the very least minimize it? Keeping momentum.


Keeping momentum going in your project is rough. If you need any proof, take a look at any dev log for an eventually abandoned game on YouTube. Solo devs spend a year (or more?) on a single project, only to end up abandoning it later. They may lose motivation, they may have a life event that prevents them from developing further. Whatever the reason, though, their game is left only visible in dev log videos, a stark reminder of what could have been. Now, some of these games were appropriately abandoned, others, not so much. One thing that is common to most of the projects I see is that the developer tends to spend more time producing the dev log updates than actually working on their project. That’s certainly not true with all projects, but enough of them want to talk about their game and produce “sizzle reels” over actually getting the game done. After all, time spent on producing other things can take away from the project itself. Sometimes you need to walk away from it and come back with a fresh mind, but if you’re working on a consumable related to the game that isn’t in service to the end goal, you really are taking away from it. *cough* I’m looking at you, Chandler… *cough*


So, how can you avoid that fate and keep on track? Well, in perfect honesty, I’m probably not a good role model to look at. That doesn’t mean that I don’t know what's necessary to get a project done, though. Small wins are key. They are the things that you look back at and point at that you completed, or are really proud of. That doesn't mean amazing artwork or a really appropriate soundtrack or sound effect, either. It's making the main menu, the options screen, all the small things that make a game complete. Sure, there may be some days where you look back at what you've worked on and not really be able to point at anything, but you need to keep those days to a minimum. Even if it's a tiny improvement, completing that one feature or even tweaking it to feel better will keep momentum going. In the game forum I'm part of, we have a saying, "no zero weeks." The real quote is, "no zero days," but most of the forum goers have day jobs and family and can't necessarily work on our game designs every day, hence why we changed it to weeks. The point still stands, though. If you want to get a game done, you need to put in the time to finish it. It will never get done if you don't put in the time. And for me, at least, that means having small wins every time I sit down to work on Cartogratour. That little bit of dopamine keeps me wanting to come back to work on it.


That's not to say that's the only way to keep momentum. Another way to keep momentum is to have some form of accountability. It may be something you announce publicly, or to yourself, but having accountability will force you to have someone, or some time to be done with your game. I know I literally just railed against devs that did it and quit, but dev journals can be one method of making yourself accountable. I personally don't find them to be really motivating, since your accountability is more nebulous than having a friend that can take you to task when you're not done when you say you were supposed to be. A public dev journal does provide some sort of accountability, though. If that's going to be enough for you to get your game done, do it. Personally, I need something more to keep myself on task, though. As I said earlier, I am part of a game development forum. Part of that is updating everyone on what you've done over the last week. It's not a whole lot more, but having to say that you haven't gotten much, or anything, done on your project does give a tiny bit of a guilt trip to keep making progress on it. So far, that has actually kept me working on a game design longer than when I didn't have the forum for accountability. Having to update a group on a regular interval is what helps me the most in terms of keeping accountability.


Whatever you use to keep accountability, make sure that you're not losing the end goal of having it in the first place: Getting the game out the door is the first priority. If you no longer are getting value from one form of accountability, jettison it. If the accountability isn't helping you get closer to your goal, change it's form or ditch it entirely. Accountability is only as good a motivator as you allow it to be. If that accountability changes to something else and becomes another hobby or whatever, make sure to find a replacement. Most importantly, if you don't get motivation from the accountability, don't spend time trying to conjure it. Switch to a different strategy that works for you.


On that note, one last way to keep momentum is to make a timeline, or set a short term goal for what needs to get done. In more formal company environments, I would be advocating for scrum or sprints. In this case, I'm advocating to chunking out the work into as small of pieces as possible to get the game done. It's not sexy, or even interesting for that matter, but it works. Small pieces are just easier to finish over getting something huge done. That ties into my first method, go for the small wins. Having small pieces planned out can prepare for just that situation. I may not like mixing work and my hobby, but this is genuinely one thing I have pulled from my professional life into my personal life that helps me. The important thing is to not plan out everything in such detail that you feel like it's "just executing" on it to finish the game. Things change in design and when they do, you'll be throwing away that effort that you put into the later parts of the plan that are no longer relevant. And that's just wasting effort that can be put towards the game itself. So, plan in smaller chunks and get those parts done. Then repeat that cycle as many times as needed. And if you find yourself getting overwhelmed by the pieces you've made, it's a good sign that you aren't done breaking apart your work. I'm currently in the throes of doing exactly this to Cartogratour. I'll make another update for that when I'm done planning it out, though.


That's about all that I have for this side quest. Hopefully you find it entertaining, if not enlightening. As always, if you have any questions, ideas or comments, reach out to me on Twitter. My handle is @jcsirron. I will talk to you next time.