TL; DR: Turn off “Filtering” on your imported image for the Tileset.
The Problem:
Gaps are showing between tiles on your Godot TileMap, something like this:
The Solution:
There are a couple of potential problems that could be causing this behavior.
One potential problem is that “Filtering” is on for the imported image that is used for the TileSet.
If you go to export your Godot project as an Android .apk file and you get the following error ‘apksigner’ returned with error #1:
Ensure that in the Android -> Export -> Options you either:
- Left ‘Debug’, ‘Debug User’, AND ‘Debug Password’ blank (in which case, Godot will fallback to the keystore provided in the ‘Editor Settings’, which should be set if you’re following the Godot “Exporting forAndroid” tutorial).
“Do a lot of work. Finish a lot of work. Share a lot of work.”
For my second month-long game jam, I was a bit more ambitious with the scope of my project and made a game with a small narrative. Overall, I’m pleased with how the game turned out and that I’ve kept up this daily project habit.
What Went Well:
- Scoping and finishing: Once again I was able to actually complete the game I had envisioned. I was able to do so because I kept the scope of the project to the bare minimum. I decided that the narrative was what…
“Do a lot of work. Finish a lot of work. Share a lot of work.”
I participated in the Game Dev Field Guide’s 2nd Monthly Game Jam in February. This was the first step in my resolution to dedicate time to game development and publish games.
I consider the project a success because I achieved my primary goals:
- Learn the game engine Godot
- Publish a game (you can find it on Itch.io and the Google Play Store)
What Went Well:
- Godot: I decided to give Godot a try thinking I could benefit from using a “fully-fledged” game engine (read more about that decision…
“Do a lot of work. Finish a lot of work. Share a lot of work.”
I’ve dabbled in game development for a long time but I haven’t had much to show for it. I don’t finish, let alone publish, projects because I get bogged down with questions like, “Am I ever going to be able to finish this?” and “Is this the best way to be spending my time?”
This is the year that changes. This is the year that I start publishing games. And here’s why it’s going to be different:
Clearly defined purpose
One of my previous colleagues was notorious for…
November, 2020 — Go Modules (the standard for Go dependency management) had been out for over 2 years since its experimental release in go1.11, but Compass was still vendoring dependencies. Changing the dependency management tool for a monorepo isn’t an easy task, so we put it off for as long as possible. However, we were experiencing issues with an end-of-life’d vendoring tool, hundreds of megabytes of vendored dependencies, and an inability to integrate some of the latest and greatest dependencies. We couldn’t wait any longer — we needed to catch up with the world.
This is the story of that…
“Do a lot of work. Finish a lot of work. Share a lot of work.”
I am a software engineer today because of the Starcraft Campaign Editor. Back in 4th grade, my friends and I played the original Starcraft everyday before school, after school, and on weekends. We often played custom campaigns which, I learned, can be made by anyone with the Campaign Editor. I had my first game engine in front of me. I spent hours and hours on it, never really finishing any of my “games”. But it gave me my first window into programming and game development.
Why you should review code & how to get started
Why review code?
I perform code reviews because:
- It gives me practice reading code.
- I learn more about the code base.
- I learn different styles and approaches to writing code.
- I understand what people are working on and what is changing.
- It helps my teammates improve their code, catch bugs, and get their code through the door.
- It earns respect from teammates.
Hopefully, you’re convinced you should make code review a habit. However, the biggest hurdle probably isn’t motivation, but uncertainty on how to get started.
Tips for reviewing code
Reviewing code when you’re starting at a company can feel daunting. Not only because of “imposter syndrome”…
Transitioning the code review tool of a monorepo
This is part of a blog series on managing monorepos. If you haven’t already, check out https://medium.com/compass-true-north/repositories-one-or-many-f9da590611af. More to come in the next few weeks!
At Compass, we have over 350 software engineers collaborating on a single monolithic repository (see our post on multi-repo vs monorepo) that is home to hundreds of our backend services.
We were using Gerrit as a code review tool for this monorepo but decided to switch over to Github. This is the story of that transition.
Why did we do this?
The benefits of Github that fueled the transition include:
- Many engineers have a preference for the Github UI over…
