Forem: Allison Day

Unity - tint your editor while in playmode

Allison Day — Tue, 23 Jun 2020 07:35:18 +0000

A really quick tip for those of you using Unity...

How many times have you forgotten to stop your game when you're in the middle of developing, or wonder why nothing's working then realize it's not in play mode?

Well there's an easy fix for this!

You can change your settings so your Unity editor will change to a different color when you're in play mode, and then go back to the usual grey when you're in edit mode!

To set a color:

If you're on a Mac, go to Unity > Preferences

If you're on Windows, go to Edit > Preferences

Select Colors in the sidebar

Find General > Playmode Tint and click the bar or color dropper to choose the color you prefer. (Personally, I go with #D796FF!)

Go back to your editor, click the Play button, and see your new Playmode color in action!

And there you have it! Now you'll more easily know when you're in play mode, and when you're in edit mode. Happy developing!

0 to 100 YouTube Subs: The First Three Months

Allison Day — Fri, 29 May 2020 19:46:56 +0000

We're just over three months into our YouTube channel, and have just barely clawed our way past 100 subs (at the time of writing, we're currently at 119). This has been simultaneously easier, but also more difficult, than we went into this expecting it to be.

In the three months (and 13 days) since our first video was posted on Feb 15th, we've gotten:

119 subs
2,597 views
304.5 watch hours

It helps to have an existing community.

We've spent the last two and a half years building up a community on Twitch - and a lot of our viewers are super loyal, and will follow us anywhere. They were a huge part of our initial boost in numbers! Combine that with a (not amazing but definitely decent) pre-existing Twitter and Instagram following, and I can definitely say that the fan base we've built up over the years helped - at least a little bit.

People have to be convinced that they'll enjoy your content.

I'll likely write some articles about Twitch and our ongoing journey there at some future point, but one thing we've noticed there is that people really have to be convinced that they'll enjoy your content. This takes time, and repeated exposure.

We have so many people who are solid community members and even close friends, who found our channel through a raid or browsing on Twitch, and didn't really stick the first time around. It wasn't until the third or fourth time that they ended up on our channel that they realized, "Hey, I actually like it here," and became a more solid part of our community.

The same goes for our YouTube videos. We've gotten a ton of subs from our Twitch community, but since the content is completely different (cooking on Twitch vs. gaming and programming on YouTube), the majority of them didn't really watch more than one or two videos. But we continued being consistent and uploading every day, and three months in, we're starting to see people get into a habit of watching our videos, and even get hooked on the different series of games we're putting up.

Long-term consistency is key.

About that consistency…

For the last month or so, we've posted a video to our YouTube channel every. single. day.

We're a little nuts.

You definitely don't need our posting schedule (although it is VERY manageable for us - I'll write more about our filming and editing processes in a future post!), but consistency is very important, no matter what sort of content you're creating.

You want to become a habit for people. If you can have a consistent time and place that you post things, people will get used to that and start to show up before you do.

People are always asking, "what time should I post/stream/tweet?" And while I don't doubt that there's all sorts of data and such that will tell you exactly what you want to know… I will still insist that it doesn't matter as much as you think it does.

Post once every few weeks or so during PRIME TIME? Cool. You might get lucky and get a little attention. You might not.

Post every single week at a consistent day and time, even if it's not the "perfect" hour? Even better. Now people can make you a habit.

Have fun!

You know what makes it easy to be consistent? When you're having tons of fun doing something!

Gaming on YouTube may be SUPER FREAKING SATURATED and totally not our path to success. And that's okay. Even if our programming videos take off and our gaming videos keep getting meh numbers… we'll keep doing it, because we have so much fun.

But part of fun, for us, is making sure that it's fun for our viewers as well. So a few things we've learned:

• Don't take the games too seriously. We're not amazing gamers. Nobody should be watching us for speedruns, or perfect playthroughs of new games, or game tutorials, or anything like that. So do things "wrong," play the game weird, try out things that make absolutely no sense!

• Don't take yourself too seriously. I credit our Twitch streaming experience for teaching us how to be goofballs. Both of us used to be afraid of looking ridiculous, or doing something wrong. Two years later, we've learned to give no shits! (But in a non-asshole sort of way.) We've both sung horribly, ugly laugh-cried, said the most off-the-wall things, and it will all be on the internet FOREVER… and we're hardly ever self-conscious about any of that any more. I'd like to think we're funnier, or at least more entertaining for it!

• "Yes, and…" This common phrase from improv classes means, don't shut the other person down. If you react negatively to a bad joke, or close off, it makes the video uncomfortable and awkward to watch. If one person does something completely ridiculous, go along with it and see where it takes you… and you'll have more fun!

The best games for our YouTube channel ended up being the ones we didn't expect.

We FOR SURE thought Overcooked 2 was going to be a hit. It's a hugely fun game, there's constant chaos, it's colorful and entertaining to watch, and we can both play… an easy win, right?

Turns out, while it wasn't terrible, it also wasn't the game where we shined the most in our videos.

On the other hand, Last of Us is dark and depressing and only a single-player game. We figured we'd try it since we already owned it and Son's been wanting to play, but we weren't expecting much from it.

It ended up being the sleeper hit of the year for our YouTube. It may be an old game that tons of people are already familiar with, but the combination of a great story, Son's frenetic playing, and my irreverent commentary (who knew Last of Us was a comedy?) is not only super enjoyable for us to play, but our viewers are also loving it.

There have been some games we've really wanted to play that ended up being total disappointments, and others that we had low expectations for that turned into a whole series (A Short Hike and Aegis Defenders were two games that we didn't realize we'd love!)

A few weeks ago, we decided to add in the Epic (and occasionally Humble Bundle or Steam) free games that are out every week, and post them on the weekends. While we do skip games if they don't seem great for our YouTube channel (GTA V would be a great game, but would need to be a long-term series, not a single episode. Civilization VI seemed like it would be a bit too slow, and we've skipped horror games as well), viewers seem to LOVE it when we try out a new game (and who doesn't love free shit?)

We've definitely noticed that single episode games or the first episode of a playthrough tends to get the highest viewership numbers. But we also really do love playing through a whole game, and some of our viewers are really into that as well. So our plan lately has been to try to find a good balance between the two - longer series on the weekdays, and shorter or single-video games on the weekends.

We also went into this expecting that multiplayer games where we could both play together would make the most sense. However, we've found that single-player games tend to work better for us! If we're both focused on the game, it's more difficult to perform for the video at the same time. But if only one person is playing, then the observer can commentate, guide the player, make jokes, and generally make the video more entertaining!

We've also discovered that I'm the better commentator - which is a total surprise, since usually Son's the talkative one in this relationship! And while we're about equivalent in gameplay skills, I tend to get super focused when I'm playing, while Son is better at joking around and doing silly stuff. This is why you'll more often see him playing single-player games than me, for now at least… but we're consciously working on this! I WILL GET MY TIME TO SHINE AS A GAMER… eventually.

But we're a programming channel too!

… not that you'd know it from our current video list. 😅

The one devlog we've posted is our most-viewed video, and the most popular with comments as well. (Not to mention, the video I'm proudest of!)

We've always intended to do more programming content, partially because it performs WAY better than our gaming content, but also because I've always loved creating educational/informational content (and, obviously, showing off the cool shit we've done!)

We actually did record a second devlog MONTHS ago, but those are a ton of work to edit, so we haven't quite finished it yet. (Don't worry - it's on the todo list!)

Instead, we're turning our focus to more manageable content (because as we learned from our SushiDay YouTube, if the content is TOO much work to make, then it's impossible to be at all consistent!)

Our new eXcess Reality podcast is super easy to make (although MAN were we both nervous going into it). Too soon to say if people are into it yet, since as I'm writing this we've only posted the intro and first episode! But hopefully next time I write a post like this, I'll actually have something more to share.

We're also brainstorming ideas for super simple, really short "programming tip" videos we can make. 5-10 minutes max, just a quick tip that's easy to record, and quick to watch. Longer-form tutorials are definitely on the todo list as well, but really, how many of us have a whole list of hour-long tutorials that we mean to watch, but never quite get around to… so I'm hoping these little programming bytes (heh) will be easier for people to watch as well!

What's next?

We've only just made it past 100 subs, 2000 views, and 50 videos. 1000 subs HERE WE COME. (Heck, let's shoot for the stars. 10k by the end of the year? LET'S DO THIS.)

More gaming videos, absolutely - they're the easiest for us to film, and so much fun. (We actually have an excuse to game now!) We're doing our darndest to finish up Last of Us (heh) before Last of Us 2 comes out (which we've already pre-ordered). Son's suggested that we try out Minecraft Dungeon (although so far it's a total fail, because everyone's getting locked out of the game!), and he's SUPER excited about Ghost of Tsushima. We bought Table Manners a while ago, and Totally Accurate Battle Simulator is on our todo list as well. And of course, if Epic keeps giving out free games, then we'll keep trying them out (along with our HUGE backlog of all the Epic Free Games we got before we started filming them!)

The podcast is a wee baby right now, so we'll be continuing to film/record episodes of that, and see where it goes! We've been wanting to get into AR/VR forever, so this has been really interesting, enlightening, and fulfilling for us.

More devlogs! Now that we're funemployed, we (hypothetically - LULZ) have more time for game dev. We started prototype #2 way back in Feb, and then never had the chance to get past modeling. But we definitely want to finish our second prototype, so expect to see some devlogs… hopefully soon. Oof.

And lastly, educational programming content! We're trying to start small - tips, advice, retrospectives about things we've already created (like the article you're reading right now!) As I mentioned, eventually I'd love to do more in-depth tutorials as well… because as you can see, I don't have nearly enough on my plate as it is. 🤪 We'll get there.

What do you want to see?

Is there a game you want to see us play? A programming or dev-related question you're curious about? Let us know! We may not get to everything right away, but we always love to hear what you want to see from us.

eXcess Reality Podcast, Ep. 1: Hand tracking, hardware rumors, and an upcoming VR jam!

Allison Day — Tue, 26 May 2020 20:17:26 +0000

Welcome to the very first episode of the eXcess Reality podcast!

You can subscribe to our podcast on: iTunes | Spotify | Breaker | SoundCloud

To start off with some exciting news… we were finally able to order an Oculus Quest!

We've just passed the one year anniversary of the release of the Oculus Quest and Rift S - https://www.oculus.com/blog/celebrating-the-one-year-anniversary-of-oculus-quest-and-rift-s

And Facebook is reporting that they've sold $100m worth of VR apps - https://uploadvr.com/facebook-100-million-dollars/
(Sounds like it's time to get in on app-making!)

There are reports that the popularity of VR has gone up since quarantine - https://abc7news.com/spatial-vr-meeting-spacial-virtual-reality-how-does-work/6183856/

Hand tracking is coming out of beta - https://www.oculus.com/blog/celebrating-the-one-year-anniversary-of-oculus-quest-and-rift-s

Have you seen this mini beat saber? - https://twitter.com/pushmatrix/status/1260209543864356865
I SO want to play it! - https://www.roadtovr.com/miniature-beat-saber-concept-ar-daniel-beauchamp/

If you think that's cool, there's a VR Jam coming up in August, and we're planning to participate! - https://itch.io/jam/tray-table-vr-jam

Some of the ideas we've had:
• hand-tracking orchestra app
• claw machine game
• plane route experience
• horror game - plane crash
• jenga with turbulence

We discuss rumors about the Apple Glass - https://bgr.com/2020/03/24/apple-glasses-ar-leak-features-2022-release/

And the troubles/pivoting that Magic Leap has been facing - https://www.businessinsider.com/magic-leap-could-pivot-to-healthcare-ar-with-new-funding-2020-5?op=1

I'm really excited that companies are addressing motion sickness, since that's a huge problem for me - https://www.thegamepost.com/2020/05/08/next-gen-playstation-vr-patents/

And related to that, this video about the movement decisions made by the Half-Life Alyx dev team is fascinating - https://www.youtube.com/watch?v=TX58AbJq-xo
Who wants to send me headsets to test for motion sickness?

There's allegedly a new, lighter Oculus Quest coming out next year - https://www.bloomberg.com/news/articles/2020-05-05/facebook-s-oculus-developing-smaller-lighter-quest-vr-headset

And our App of the Week is this nifty Size.Link app, that works right in the web browser on your phone: https://size.link/

Let us know what you think, and we'll see you next week for episode 2!

eXcess Reality – Our New Podcast!

Allison Day — Sat, 16 May 2020 04:10:24 +0000

Welcome to the first episode of our new podcast and video series, Xcess Reality!

First things first – who are we, and why are we doing this?

My name is Allison, and I’m joined by Son, my husband. (No he’s not my son, his name is “Son”. We have no kids, although I’m sure you’ll soon see that at times he acts like a kid.)

We’ve both been in tech for quite some time (almost 15 years for me, more than 20 for him) and for the last decade and a half, we’ve been creating things together.

Our projects have mostly leaned towards web dev (Fridgg was one of the first big things we released together that wasn’t a client job), but of late we’ve also gotten into game dev (we released our first game, Bobber Bop, last year – as well as ArmPG, a prototype, earlier this year).

But in the last few years, we’ve explored our entertainer side a little more as well. From streaming cooking and coding, to gaming and devlogs on YouTube, we’ve enjoyed the process of becoming better performers (and geeking out about cameras and editing!)

But all this time, even though it was never something we’ve discussed much publicly, we’ve always been looking to the future. What will the world look like five, ten years from now? How will our lives look as programmers? What skills will be most relevant?

Over and over, we’ve come back to the idea of XR – augmented reality, virtual reality, and everything in-between.

While we got into game dev as a way to develop the skills that will be useful for XR, we haven’t done much beyond that. Heck, we don’t even have a headset. (We are on the waitlist! …but if anyone randomly wants to send us one, hit me up yo.) But, while we’ve been happy to be able to make money with client web dev work in the recent past, lack of time and other commitments meant that our XR-related progress had kind of stagnated.

Then a week ago, as we were discussing how to progress now that our most recent client job has ended, the topic of XR came up again.

“You know what we really need to do,” I insisted, “is start having regular discussions about the industry as a whole. Not even necessarily the technical stuff, but just familiarize ourselves with who’s who, what’s going on, what games are out there, all that. How can we get into XR if we barely even know the industry?”

Son nodded. “We should do a podcast.”

I screamed and burst out laughing at that, because we had said we’d never do a podcast. It makes no sense for us to do a podcast. Seriously, why on earth would we do a podcast when we’re already streaming/youtubing/blogging?!

So… we’re doing a podcast.

We’ll be discussing what’s going on in the industry, brainstorming ideas for cool projects, and injecting a large dose of our signature goofiness. Are we experts? Absolutely not! – although our decades of tech industry experience certainly counts for something. But we hope that you’ll tune in for our XR journey, and let us know what you think.

And a note about the name – eXcess Reality. Its initials are XR, it’s a nod to the fact that sometimes we can be a bit much (and rarely ever take ourselves seriously), and it also just tickles me that when you say the name out loud, it sounds like we’re talking about the itsiest, bitsiest, extra-small reality.

Want to stay up to date with eXcess Reality?

If you’re a listener, we have a podcast – just search for eXcess Reality on your favorite podcast provider (if we’re missing your preferred platform, let us know!)

If you’re a watcher, we have… a vodcast(?) – find our eXcess Reality videos on our SushiCodes YouTube.

And if you’re a reader, or just want more information, all our show notes are available on SushiCodes.com!

Sushi Game Jam: ArmPG Devlog Video!

Allison Day — Tue, 10 Mar 2020 17:14:46 +0000

In January, we made a game prototype on our Twitch stream.

In February, I wrote a devlog about our game here on dev.to.

In March, we finally finished the video for the devlog! If you haven't yet, check out all three - and let me know what you think!

Sushi Game Jam: ArmPG!

Allison Day — Wed, 19 Feb 2020 23:36:51 +0000

In January, @phuson and I set out to make a game about an arm.

An ArmPG, if you will.

The Game

Imagine that you are an arm.

A disembodied arm.

(The game isn't nearly so gory as it sounds, I promise.)

You're an arm, trying to find the rest of your body.

In your search, you've happened upon a dungeon filled with spiders.

Anybody with half a mind would either run for their life, or burn it all down... but you're an arm. You have no mind, it got lost with the rest of your body.

So you decide to fight the spiders, and lo and behold! These spiders just happened to be hiding all the rest of your body parts, and you must do battle in order to find yourself and put yourself back together.

The Modeling

The most obvious model we needed for an ArmPG is... the arm. So that's what Son started out with.

Is it a worm? A plunger? Ohhhh it's a turkey baster.

If this is a fighting game, then our arm needs a weapon! Someone in our Twitch stream chat suggested a buster sword, so FF-style it was.

Because what every arm needs is a MASSIVE FREAKING SWORD.

Next up, environment!

For inexplicable reasons, Son decided to start with a scone.

Er... sconce.

Now I want scones.

... and after all that, he didn't even use it.

He claimed he was making a dungeon wall, but we're still not fully convinced he wasn't tiling a shower.

Or maybe it's a bookshelf?

Every dungeon needs a library, you know.

Pillars?! We fancy.

If your goal is to find your body, you need the rest of your body to find, right?

He made the body parts...

No such thing as too many swords.

He imported the body parts into Unity...

Well if you're just gonna leave your body parts laying around, it's no wonder you lost them!

Body parts. Everywhere.

And then spent the week distracted, playing Socket League.

We're pivoting - this is way too much fun.

Luckily (or perhaps unluckily) for everyone involved, I finally managed to convince Son not to pivot or abandon the prototype-a-month project in order to develop Socket League.

Last thing we needed was some sort of enemy!

Son decided to go with spiders...

... and very stubbornly decided that spiders are completely fine with only 6 legs.

Unspider.

#arachnot

There we go. Eight legs!

Pro tip: if something has a lot of the same part (such as, ahem, eight legs), you can create it once and then duplicate it! For our spider, Son created the body and one leg separately, imported them both, and then in Unity added all of the legs to the body.

(Since we are decidedly NOT pros, since this is our first prototype and we've only made one other game, we originally created one mesh with all the legs, until someone in chat suggested we do it with just one leg. OH RIGHT THAT'S HOW THIS WORKS.)

Once one spider was done, Son made a few different textures so we could have different color spiders, and then resized them in Unity. We have a variety of spiders, every type you could possibly want!

SO MANY SPIDERS

And to finish it all off, the one feature every game spider needs - boobly eyes.

googly eyes + boob physics = boobly eyes

From a performance point of view, the spider and legs were baked into one mesh to optimize draw calls, which helped with performance dramatically.

The Dev

Let's get some models moving!

First thing we worked on was the arm movement. We've been using the Final IK Unity asset for procedural animation. Understanding inverse kinematics and procedural animation was one of our main goals for this month's prototype.

We tried out a few different solvers (different algorithms to calculate the arm/joint movement) - FabrikIK, CCDIK, and finally settled on LimbIK. (LimbIK is the obvious solution for arm movement - after all, the arm is a limb! - but we wanted to try out the different solvers to understand the difference between them.) If you don't use the right solver for your intended type of movement... things get weird.

Next, we needed some movement controls. The arm will work if you drag around the control target in the scene, but in order to play, you need to be able to use the keyboard or a gamepad to control the movement.

For this, we used another Unity asset called Rewired. We use Rewired to control the position of a control target, and then created a loop in our code to control the crawling motion of the arm. The arm will now always move in the direction of the target.

The sword cuts through the ground like buttah! Wait... that's not right...

Just one problem - we're dragging the sword through the ground! Just a little vector magic and voila - the sword now faces in the right direction no matter where you're going.

We implemented jumping, dashing, swiping... TADA! Our player character is done!

Next we imported the environment (the backsplash bookshelf wall looks so much better with proper lighting!), and baked the wall assets as long walls to keep draw calls down.

Hey, it's a wall!

... and discovered that the arm can go through walls.

Unity colliders, WHYYYYYYY.

Welp.

Okay, we can fix this. Instead of directly changing transform.position, we changed that to use rigidbody.MovePosition() to move the arm. This respects the colliders, and now you can't just push right through the wall.

Stuck.

Let's add some monsters! Son's model allows us to have eight-legged spiders... but how do we move all the legs?

*boogies*

Just as with the arms, each leg is controlled by inverse kinematics, using the LimbIK solver from Final IK. I added a loop to alternate between legs, so rather than all the legs moving towards their goals at once, only the even or odd legs can move at any one moment, and then they switch. This gets real creepy crawly.

Run awaaaaayyyy!

Then, we used the A* Pathfinding Project Pro Unity asset to tell the spiders where to go.

help.

Time to fight! The sword has a trigger collider, so we used OnTriggerEnter to check if the sword collides with anything on the Enemy layer in the game. If so, then that spider will take damage, and we AddForce to throw the spider back!

On the other hand, if OnCollisionEnter is triggered on the arm collider by anything with the Enemy layer, then the arm takes damage and is thrown away from the spider.

DIE SPIDER DIE

... and then we realized we needed to lock the rotation on the spiders. Otherwise, one hit and you get some very, very drunk spiders.

Go home spider...

From there, just a few more things to complete the game.

Lighting is everything. We added some light balls, baked the lighting, and then got rid of the balls... AND LOOK HOW PRETTY IT LOOKS. It's almost like it's a real game now.

Great balls of lighting!

Levels! We added some ScriptableObjects for each level, that hold all the information about the waves of spiders, and the reward for each level. Now it's super easy to add more levels or change existing levels on the fly.

This is exactly how things are supposed to work, why do you ask

We added Cinemachine (which comes with Unity) for camera work, so the camera follows the player nice and smoothly.

Uh oh. But look how pretty the game looks!!!

A little UI, a few simple movement swoosh effects, and voila! We've got a game!

Fight!

Fight!!!

FIGHT!!!

The Future

Since we only had a month for this prototype, there were a lot of wishlist items we didn't have time for. We're hoping we'll be able to sneak these into future prototypes, or we might someday decide to come back and finish this ArmPG.

ArmPG Bucket List:

invulnerable state for player
more of an RPG-type of story
finite state machine (chase/attack, idle, roam) with procedural animation for each state
be able to chop off spider legs
add blood trail
particle effects
raycast for spiders' feet to check where we're moving feet to
procedural environment (at least randomized drops)
treasure chest for body parts
armor/other pickups
sound effects/music

WOOOOOO!

Our game prototype is available to play! Download it at itch.io, and let us know what you think in the comments!

Enjoy this post? Consider sharing it on social media - every tweet helps, and you'll have my eternal appreciation!

For more, follow me on Twitter or check out my Twitch streams!

12 Days of Gitmas: Merge conflicts and PRs!

Allison Day — Wed, 05 Feb 2020 19:05:47 +0000

On the tenth day of Gitmas, my mentee asked of me...
what does "PR" mean?
what a branching strategy,
what's this gitignore thing,
push-ing, pull-ing, diff-ing,
what is SSH-ing,
how do I connect these,
what's this "GitHub" of which I've heard,
Git's ready - what then,
how do I get Git set up,
and could you explain Git, pretty please?

Now that we know how to branch out of the main branch, we need to know how to merge your branch back in!

There are a couple of ways to go about this. If you're working on a smaller personal project, you can technically just directly merge your branch back into the master branch. But if you're working on a project for a company, or an open source project, or pretty much any time you're working with other people, you should create a pull request.

What is a pull request?

A pull request (aka PR) is essentially a request to merge the changes you made in one branch into another branch. This allows the repository owner or other designated reviewers to look over your code, make sure things are working, and confirm that this is a change that should be merged in. They may ask you to make changes, or leave comments asking you to explain something in your code. Once everyone approves the PR, it can then be merged into the target repository.

It's a good idea to always check the README, any other documentation, previously-merged PRs, or to talk to the rest of the team to make sure you know how they want PRs to be done. This process can often be different from project to project!

So how do you create a PR?

First things first, make sure you git commit all the changes you've made in your branch.

Then, git pull down any updates that have been made to the branch you're intending to merge into (we'll refer to this as the target branch).

git checkout [target branch]
git pull
git checkout [your working branch]

Merge the target branch into your working branch, so your working branch is up to date and won't have any merge conflicts once the PR is approved. (If it takes a while to get approval, you may have to do this several times in order to make sure your working branch stays up to date. PRs with merge conflicts can't be merged in!)

Make sure you're on your working branch and run:
git merge [target branch]

If there are merge conflicts, Git will yell at you, and now is when you deal with them.

Go into the file(s) that have the merge conflicts, and search for <<<<<<<. The file will show the changes you made, and the incoming changes from the other branch.

Edit as needed - you can choose to keep your changes, keep the incoming changes, or make any necessary changes needed to keep both changes. (If you're unfamiliar with the incoming changes, talk to the developer who made them, or the person in charge! You definitely don't want to be accidentally deleting someone else's work that's supposed to be in the codebase.)

Once you've fixed all the merge conflicts (there can be multiple instances in a single file, or multiple files involved - make sure you get all of them!), I HIGHLY recommend re-running and re-testing your code to make sure everything works as expected. Sometimes merge conflicts can be tricky, so you want to make sure you're not trying to merge broken code once you submit your PR.

If you're using VS Code, things are a little easier. In the sidebar, the little symbol with the three circles and lines is your source control tab. Click on that, and you'll see the files that are currently staged for commit ("Staged Changes"), the files that aren't staged ("Changes"), and the files that have merge conflicts ("Merge Changes").

If there's nothing under Merge Changes, then you have no merge conflicts. But if you do, then click on one of the files. Somewhere in the file, you'll see a section that looks like this:

This shows the two versions of that portion of the file that are conflicting with each other. Right above it is a list of links you can click for different actions:
If you want to keep your changes only, click "Accept current change".
If you want to keep the changes from the target branch and discard your changes, click "Accept incoming change".
If you want to keep both, click "Accept both changes" (but keep in mind that sometimes this may leave out things that existed in both versions, such as a closing brace, so make sure to check that the code looks and works right after doing this!)
"Compare changes" opens the two versions of the file side by side so you can see in a different format how things have changed.

Once you've fixed any merge conflicts and are certain everything works correctly, git commit your changes again. Git will automatically fill in the commit message for you, so you can just accept this message and continue.

git push your working branch, then go to GitHub to create your PR.

On GitHub, if you've recently pushed a branch, then you may have a light yellow bar with a green "Compare & pull request" button. If you have that, then click it; if not, click the "New pull request" button next to the branch dropdown on the left.

If you're manually creating a PR, then on the next page, make sure the "base" branch is your target branch (the one you want to merge your changes IN to), and the "compare" branch is the new branch you've been working on. (If GitHub already knew which branch you're merging, and you clicked the "Compare & pull request" button, then you'll skip this page.)

Once you've chosen your branches, you'll see a form. Here you can write a title and description for your PR, as well as choose reviewers or add any other appropriate information. A lot of this will depend on the preferences of the people or team who own the repository - they may require certain information be in your PR, or that things are formatted in a specific way, or that you label your PR correctly.

Regardless, it's always a good idea to be descriptive when submitting a PR. Explain the issue you're solving, and link to any relevant tasks or issues. Include screenshots showing the before and after of what you fixed, or a gif showing the new feature in action. Include instructions for how to test the fix or view the new feature - assume you're writing for someone who's completely unfamiliar with the project, and be as clear as possible with your instructions.

Once you're happy with your PR, click the big green "Create pull request" button at the bottom of the form - and there's your PR!

From here, keep an eye on your PR. Remember to merge in your target branch regularly, so your branch stays up to date. If your reviewers leave comments about changes they would like to see or issues they've found, you can make any necessary changes locally, and then git commit and git push as usual - once you push, your new changes will show up in your PR. Sometimes reviewers will leave comments asking questions about your code, or suggesting a different way of doing things, in which case you can reply to their comments directly on GitHub.

Depending on the team, you may have to wait for build processes to pass before merging. If you're unfamiliar with this, talk to your team! There's often someone who will be happy to explain all their processes to you.

Once your PR has been approved by the reviewers, now it's time to merge! Make sure you know what the process is for the project you're working on - sometimes, someone specific will do the merge; other times, you can merge your own PR once you have the required number of approvals. As soon as your PR is merged, congratulations! Your code is now part of the main codebase.

Have you tried creating a PR yet? What was the first project you contributed to? I'd love to hear from you in the comments!

If you have any other questions about Git or requests for other topics you'd like to see me blog about, please leave a comment! And if you're enjoying this series, consider supporting me on Patreon, following me on Twitter or checking out my coding or cooking Twitch streams!

Our Personal Game Jam

Allison Day — Mon, 03 Feb 2020 07:43:31 +0000

A game prototype a month, every month, for a year.

Depending on how much you've worked on games, this either sounds totally doable, or completely impossible.

It's practically our very own game jam!

Are we absolutely nuts?

Yes, yes we are.

The first question is... who are we?

My husband (who shall henceforth be referred to as "Son" - yes, that's actually his name; no, he's not my kid) and I are traditionally web devs, as you may have guessed if you found me though my Gitmas series. He has his master's degree in computer science, and worked at Yahoo! for a while before turning to consulting work; I was a dancer when we met (15 years ago!) but always loved math and science - he quickly turned me on to programming, and we've been working together (both on client work and on our own projects) ever since.

While we still do plenty of React work for clients (and you'll continue to see plenty of web dev-related posts here), in the past few years we've begun to delve into the world of game dev. In our free time, we stream coding, cooking, and occasional gaming.

Okay, but... why are we doing this?

Games are a ton of fun to make, and we actually released a free mobile fishing game called Bobber Bop last year. It was an amazing experience (and we're so proud to have actually launched a game!), but when you're focusing on getting a single game to launch, you don't have the opportunity to play with other game dev techniques and learn other skills.

Ultimately, Son and I want to be developing for AR and VR, and to be versatile devs. (There's a lot of overlap between games and mixed reality - creating 3D objects and effects, and being able to move around within and affect a 3D space are a necessity for both.) But the way we see it, being bogged down working on a single game with a limited scope for months or years... can be great if you want to be focused on releasing one big game, but doesn't quite align with what our goals are.

Thus the prototype-a-month project. Working on a bunch of different prototypes achieves some specific goals for us:

we get to try out lots of game ideas in a short period of time, and decide which are worth pursuing, and which aren't great
each prototype has a different focus - so we learn a wide variety of techniques and can play with different art styles
lots of practice brainstorming game ideas
impossible to get hyper-focused on one game or technique, to the detriment of all others
forces us to jump off the deep end - it's a lot easier to mess around and try out new things (like, ahem, Blender - we were definitely tempted to stick with Voxels, since we were already comfortable with that from Bobber Bop) since "who cares, it's just a prototype, it doesn't need to actually look good"

Did I mention we're doing a good bit of the development live on our Twitch stream? We're only a month in, and we've already been tempted to abandon the entire project and continue developing our first game - so it's helpful that chat keeps us honest!

What are we using?

At the moment, all of our development is using C# and Unity. Most of our 3D modeling uses Blender, although Bobber Bop was made with MagicaVoxel and it's very possible we may occasionally do some voxel art again.

What's next?

We just finished the prototype for January (there will be a post all about our first game soon!) We're super hype about the first game, and as much as we don't want to stop working on it, we know the whole point of this prototype-a-mont project is a prototype... every... month.

We're definitely not saying goodbye to January's prototype for good, though. If we have time outside of streaming/work/blog post writing/video filming (free time? what's that?) we may continue development here and there, but more likely, we'll be picking it back up again either as another one-month project this year, or sometime next year.

I'll be continuing to blog about both web and game dev, so let me know what you want to see me write about. (Don't worry - I'm still working on finishing out the Gitmas series... and yes of course Christmas season continues into February, why do you ask? Next Gitmas post is just about ready!)

Before I wrap this up, I want to know - what are you working on right now? What do you want to learn? Leave a comment below and let me know!

If you have any other questions about game dev or requests for other topics you'd like to see me blog about, please leave a comment! And if you're enjoying my writing, consider supporting me on Patreon, following me on Twitter or checking out my coding or cooking Twitch streams.

12 Days of Gitmas: Git Branches

Allison Day — Fri, 24 Jan 2020 21:24:51 +0000

On the ninth day of Gitmas, my mentee asked of me...
what a branching strategy?
what's this gitignore thing,
push-ing, pull-ing, diff-ing,
what is SSH-ing,
how do I connect these,
what's this "GitHub" of which I've heard,
Git's ready - what then,
how do I get Git set up,
and could you explain Git, pretty please?

We've reached Day 9 of the 12 Days of Gitmas, and today we're going out on a limb... and talking branches!

If you're working on a very small project by yourself, you may not need branches. But for the majority of projects - if you're working on a team, or if you want to work on features that won't go to production yet - branches will be an important part of your Git experience!

When we introduced how to check in your changes, I mentioned that you should do git push origin master, and that I'd explain what that meant more in the future. Well, the future is now!

git push you already know - git is to signify that the command should use Git, and push means you're pushing your changes to the remote repository.

origin is a shorthand that refers to the remote repository that the project was originally cloned from.

master is the branch you're on. By default, when you initialize a Git repository, it will have a single branch - the master branch.

When you run git init, you start on the master branch.

What is a branch
When you're working on a project, you want to be able to check in your changes and "save your work" on a regular basis. But what if you're not ready for your changes to be in production? What if you're working with other people, and need approval before your changes get into the main codebase? What if your team wants to have one version of the codebase on production, and develop and QA the next version before it goes to production?

This is where branches come in.

Think of your repository like a river. Every repository starts with a single branch, called master.

The river can branch off into smaller streams, which could, at some future point, merge back into the main river. This is essentially how branches work in Git.

You can create a branch off of master, at which point the code in the master branch and your new branch will be exactly the same. But from there, the original branch will carry on as it is, but any new changes you make in the new branch will live independently from master. At a future point, you can merge your new branch back into master, which will bring your new code into master, but up until then, the master branch won't know anything about the new changes you've made on a different branch. (We'll talk about merging and PRs in the next post!)

Many projects will have a master branch for what goes to production, and then a develop branch (or something similarly named) that all the developers will work off of. In this case, the developers will branch off of develop, since that is the branch with the most up-to-date code. Once the codebase on develop is deemed ready for production, then they'll merge develop back into master in the process of pushing the new changes to production.

Okay - so we've got the theory, now how do we make this all work in practice?

Creating your own branch
To create a new branch, run:
git checkout -b [branch name]
Make sure the branch name is a string with no spaces: new-branch, rather than new branch (This should be the case for all naming in Git - branches, repositories, file names, etc.)

Pulling down new branches
Sometimes, you'll want to work on a branch that somebody else created, or run the code on their branch while code reviewing a PR. In order to do that, you'll first have to make sure their branch exists on your local machine. To pull down all the new branches that exist remotely, run:
git fetch origin

Checking out someone else's branch
Once you've fetched all the remote branches, you can checkout the branch you want. This command is similar to the one you ran to create your own branch, but note that this time, you won't have the -b in the command:
git checkout [branch name]

From there, you can git pull to pull down their latest changes, or git commit and git push to add your own changes to their branch. Always make sure you have permission to be working on someone else's branch!

Now you know all about Git branches and how to use them. In the next post, we'll be talking about merging branches and PRs!

12 Days of Gitmas: .gitignore

Allison Day — Thu, 09 Jan 2020 07:06:14 +0000

On the eigth day of Gitmas, my mentee asked of me...
what's this gitignore thing?
push-ing, pull-ing, diff-ing,
what is SSH-ing,
how do I connect these,
what's this "GitHub" of which I've heard,
Git's ready - what then,
how do I get Git set up,
and could you explain Git, pretty please?

Today's Day 8 of the 12 Days of Gitmas, and today we're talking about .gitignore - what is it, and when should you use it?

Right now, if you git add ., it will add every single file within your project to Git, and track all of them.

But sometimes, that's not what you want. Say you have a huge log folder that's generated when you run your project. Or, if you're familiar with Node.js at all, that huuuuuge node_modules folder that's created when you npm install. (If you have no idea what this means, no worries! This Git series is for absolute beginners, and Node.js is a bit more advanced.)

Suffice to say, there are a lot of cases where there are files that are created within your project that you won't necessarily want to check in. But if you have a big project, it quickly becomes a huge pain to have to cherrypick which files you do want, and individually git add every single file.

This is where the .gitignore file comes in.

As you might guess from the name, .gitignore is a file that tells Git which files or folders to ignore.

This way, when you type git status in the command line, none of your ignored files will show up, or get added if you do git add . It's a super easy way to tell Git what to pay attention to, and what to ignore.

What do you put in .gitignore? It's just a text list of files, folders, and file extensions that you want to ignore.

In my .gitignore file, I want the .DS_Store and ignoreme.txt files to stay out of my GitHub repository.

For example, if you're working on a Node.js project, then you should probably add node_modules/ so it ignores the entire node_modules folder (which gets regenerated every time you npm install, so there's no point in checking it in).

You can even ignore everything of a specific file type - so, if for some odd reason, you never ever want a JPEG image file to get checked in, you can add *.jpeg to your .gitignore file.

Now, when you type git status in your command line, the files or folders that you've ignored won't show up - you won't even have the option to add them or check them in, which is exactly what you want here!

You may notice that I typed gst instead of git status. That's because I'm using aliased commands to make it easier when I'm using Git a lot! We'll go over this in an upcoming post. The cat command just outputs the contents of the text file into the terminal.

And now, when you commit your changes and push them to GitHub, the ignored files won't be there.

However! .gitignore only works for files or folders that haven't been checked into your repository. If you created a README.md file and checked it into your repository, for example, and then added either README.md or *.md to your .gitignore file, future changes will still be tracked. If you want a file or folder to NOT be tracked, you'll have to manually remove it from the repository and check the repository in without that file or folder.

New files won't show up here if they're supposed to be ignored.

Now you know all about .gitignore!

12 Days of Gitmas: Committing your changes in Git

Allison Day — Mon, 06 Jan 2020 20:00:50 +0000

On the seventh day of Gitmas, my mentee asked of me...
push-ing, pull-ing, diff-ing?
what is SSH-ing,
how do I connect these,
what's this "GitHub" of which I've heard,
Git's ready - what then,
how do I get Git set up,
and could you explain Git, pretty please?

Today's Day 7 of the 12 Days of Gitmas, and today we'll be talking about how you actually track and commit your changes in Git.

If you've been following along, by now you know how to create your own Git project, and connect it to GitHub. Now you can work on your project locally!

But... how do you actually use the version control aspect of Git? And how do you get your changes onto GitHub?

(For this post, make sure you're working on your own repository! The concepts will be the same if you're working with someone else's project, however there's some additional information you'll need to know first that we'll go over when we discuss branches and PRs, in an upcoming post.)

First thing first, go ahead and make some changes in your project. For example, add some information to your README, and add a new file within your project.

Now go to your console, and type:
git status
You'll see a list of all the files in your project that have been added or changed since the last commit.

Here you can see that I deleted a file called .DS_Store, made some changes to the README.md file, and added a new file called index.html.

If you want to see more details about exactly what has been changed, type:
git diff
This will show you a "diff" of the files (the difference between the previous version of each file and the new version).

This screenshot shows the diff of my changes. As you can see, it's only showing the changes in the README.md file, because index.html isn't being tracked yet. Type q to get out of this view.

If you're happy with the changes, then you can
git add [filename]
to add all the changes associated with a specific file, or
git add .
to add all the changed files. This tells Git which files you want to add to your commit, to record them to your version control history.

Once you run git add ., you can do git status again to see that your files have been added. The files with changes that are staged to be committed will be in green. If there are any files left that you haven't added, they will still be red.

Lastly, you need to run
git commit
in order to commit your changes. This will open your default editor to write your commit message. If another text editor opens when you type this, you can write your commit message at the top, save, then quit the application, and Git will commit your changes.

Otherwise, it's likely the default editor is vim. Vim is notoriously difficult to exit once opened if you're not familiar with it, so there are a few other options.

You can do
git commit -m "Write your commit message here"
to just take care of it entirely in the command line.

Or, you can change your editor. I prefer to use nano, so whenever I set up a new computer, I run
git config --global core.editor "nano"
to set nano as my default editor. You can get more information about setting different text editors as your default in this GitHub article.

If you change to nano, your commit will look something like this. ^x to exit, then y to save your commit message. If you n, it will just cancel the commit.

You may be wondering, what should you write as your commit message? Different companies or projects have different standards, so depending on what you're working on, you may have to format your message a specific way or include certain information - like an issue ID, task name, change type (bug, feature, etc.), and so on.

Regardless, you'll want your commit message to be short and concise, yet descriptive. "bug fix" or "asdf" are terrible commit messages (that, let's be honest, we're all probably guilty of - but it's still a bad practice!), while "adjusted spacing on homepage banner" or "created API for scheduler" are much better. Ultimately, you'll want to be able to look at your commits from a day ago or a year ago (or have someone else look at your commits!) and be able to have a pretty good idea of what changed in that commit, in case you need to revert your code, or see how something used to be done.

As far as Git is concerned, you've now successfully committed your changes to the version control system. But wait - your changes aren't in GitHub yet, so nobody else can see or use them!

In order to update GitHub with your changes, there are two more commands you need to know.

First,
git pull origin master
If someone else is working on the project with you, then they may have made changes as well! You need to pull down their changes to your local machine regularly, so your repository is up to date. (We'll talk about what origin master means when we discuss branches in a couple of posts.)

No one else has made changes to my repository, so when I pull, it's already up to date.

Then,
git push origin master
This pushes your changes to GitHub, so everyone else on the project can see them. It's good practice to always make sure you git pull first, because if there are changes on GitHub that you don't have locally, and you try to git push, you'll get an error telling you to git pull first.

Every time you push your code, it will look something like this.

And that's that! You now know how to make changes, commit them in Git, and push them to your GitHub repository. But that's not all! We still need to discuss what .gitignore is, how to work with someone else's repository, and so much more! If you're not following yet, make sure to click the Follow button so you'll get notified when the rest of this Git series is posted!

And if you have any questions about Git or requests for other topics you'd like to see me blog about, please leave a comment! And if you're enjoying this series, consider supporting me on Patreon, following me on Twitter or checking out my coding or cooking Twitch streams!

12 Days of Gitmas: SSH vs. HTTPS

Allison Day — Sat, 04 Jan 2020 08:22:21 +0000

On the sixth day of Gitmas, my mentee asked of me...
what is SSH-ing?
how do I connect these,
what's this "GitHub" of which I've heard,
Git's ready - what then,
how do I get Git set up,
and could you explain Git, pretty please?

Welcome to Day 6 of the 12 Days of Gitmas, where we're discussing how to clone a repository that's not already on your computer, and what all the different options and terminology mean.

In the last post, we discussed connecting your GitHub repository to your local repository, and you may have noticed there was both an SSH and an HTTPS option for the link you use. What do these mean, and why would you use one versus the other?

HTTPS

HTTPS stands for HyperText Transfer Protocol Secure. (That "Secure" bit is why you may have noticed a lot of websites changing from http:// to https:// in the last few years.)

HTTPS is a way to securely send information to websites. This means that when you type in things like passwords, shipping addresses, or your credit card number, those are all encrypted when they're sent to the website.

Click the little link in the corner of the popup to switch between SSH and HTTPS

For GitHub, using HTTPS to connect to your GitHub repository means that you'll have to enter your GitHub username and password into the command line every time you want to connect to GitHub (such as when you push a change).

SSH

SSH stands for Secure Shell.

This is a secure way to remotely log into a server.

Here we're using SSH

When it comes to using GitHub, there ultimately isn't a huge difference between using HTTPS or SSH. However, when you use SSH, you'll have to generate something called keys to give yourself permission to connect to your GitHub repository - more setup up front, but you won't have to worry about entering your password over and over again.

To do this, you'll create a set of keys that lives on your computer. These keys are plain text files that you'll generate using the command line.

Your private key should never be shared with anybody - otherwise, they may be able to pretend that they're you and check things into GitHub with your account.

Your public key, on the other hand, can be shared. You'll add your public key to GitHub, which will allow GitHub to confirm that the person trying to change things in the repository is the same person that has access to the repository on GitHub. Each set of keys is unique, so if you want to push changes to the repository from another computer, you'll have to add the new computer's public key to your GitHub account as well.

If you want to generate keys to use with your GitHub account, GitHub has articles about using SSH and instructions for how to generate a new SSH key.

SVN?

You may also notice that when you click the "Clone or download" button to get the link for your repository, it also mentions SVN. SVN refers to Subversion, which is an alternative to Git. Since this series of articles is focusing on Git, I won't be going over Subversion, but just be aware that Subversion is another type of version control system.

Cloning a repository that you don't have locally

We've discussed how to connect your GitHub repository to your local repository, but what if you want to work on somebody else's repository - for example, if you're working on an open source project?

Go to their repository on GitHub, and just as we did when you were connecting your own repositories, click the green Clone or download button. Copy the link (either the HTTPS or SSH version, depending on your personal preferences and whether you've set up your keys or not yet), then go to the folder you have all your repositories in (NOT inside another project!) and type in your command line:

git clone [link]

After a moment, Git will create a new folder with the new repository name, and download all the project files into that project. Now you can make your own changes, and contribute to the project - I'll go over how to do that in upcoming posts!

You may also have heard of forking GitHub repositories. cloneing and forking are similar, in that they both allow you to work on the repository on your own. However, cloning just "checks out" the repository (like a library book) to your computer, and you can make changes locally (on your computer) and commit them back to the original remote (on GitHub) repository.

Fork it!

Forking a repository, on the other hand, creates your own version of that GitHub repository in your own GitHub account. This is a remote repository, meaning it is on GitHub. You can still make changes and check them back in, however the changes will go into your forked version of the repository, and not back into the original version.

If you want to contribute to someone else's project, then you should clone their repository using the command line. However, if you want to start your own project off of an existing open source project, you can fork it as a starting point for your own project. Once you have a fork of someone's project, you can clone your fork, so you can work on it locally.

(As for the other two buttons - "Star" means you're bookmarking the repository to save for later; "Watch/Unwatch" means you're choosing if you want to get notifications or not when something happens in that repository)

Now you know what SSH and HTTPS mean, and how to clone or fork someone else's project! In the next posts, I'll be going over how to contribute work to a project, what PRs are, and more!

If you have any questions about Git or requests for other topics you'd like to see me blog about, please leave a comment! And if you're enjoying this series, consider supporting me on Patreon, following me on Twitter or checking out my Twitch streams!