Pre-jam post #1

Hey all, XMoby here! I hesitated a little, but finally decided to jump in. A full-month game jam, that’s not a decision to take lightly. Or is it?

I don’t plan on posting on social media, so this topic will be where I’ll post updates, #devtober and all.

Who am I?

I’m a professional developer (as in, it has been my day job for the last 20+ years), but I’ve mainly been working on game tools and frameworks, and never really worked on a complete/complex game. I had to do a couple of trivia games for my employer, rewrote some existing products, but nothing I could really call my own. I’ve been programming since I was 8, starting on some version of Basic more than 30 years ago (yup, I’m that old).

Why am I doing this jam?

For multiple reasons! First, I’ve taken more of a management role lately at work, and I find myself further and further from the code itself. Not that it’s a bad thing, but I don’t think I can really let go. Hence my participation in this jam.

Also, I know I typically thrive in that kind of challenge. I’ve been doing NaNoWriMo three times (not in English, but in my natively spoken French), and I found that a full month is a really nice timeframe to gauge my interest in something, allowing for a nice pace without burning myself or my project, like a weekend-long jam could do.

Finally, I want to learn. Learn about new tools. Learn about the process. Learn about myself. And if I can get some semblance of game or prototype at the end of it, that’s even better.

What’s next?

Tomorrow, I’ll talk a bit more about the project, what I’d like to create, and how I plan to achieve it. Spoiler alert: There’s no way I can get to the final vision I have in mind in only a month! But I’ll try to define a clear objective for that month, and hope the habit and momentum will help me continue after October has ended.

Pre-jam post #2 - The project

Today, I’ll talk a bit about the vision I have for a game, one that’s been in my mind for years now. If a month-long jam does not give me the momentum to finally make it concretize, I don’t know what will.

What’s the idea?

Buckle up, for…

Heavily customizable top-down shooter!

Yup, I don’t think I could have made that title more boring. But then again, that’s the main idea of this game. I’m thinking of a top-down/twin-stick shooter, where the player can create their war machine by assembling one or many hull parts, then attaching different parts to it (weapons, naturally, but also batteries, boosters, coolers, etc.).

I remember playing MechWarrior on the SNES (hey, I said I was not young!), and I liked how you had to find the balance between mobility, firepower, versatility, all that while also dealing with the arena’s specificities. Going on a lava planet? Better forget about those powerful heat-generating lasers, and instead rely on machine guns for this mission. I played a couple of iterations of the series after, and I liked how that customization got refined with time. What I didn’t like that much though, was how slow-paced the game was. Also, while the 3D inside-your-mech dashboards-everywhere setup was interesting, I feel there should be another way to experiment with all those customization options.

“That’s it?”

Well, not exactly… At least, not in the “final version” that currently lives only in my head. Here are a couple of things I’d like to see/implement in there, in no particular order:

• Placement-based customization: Not only do you get to choose what pieces of equipment you bring, but also where to place them and how to orient them on the hull. Will you concentrate fire in front of you, or go for a weaker spread? Maybe a just-in-case pellet shooter in the back?
• Attachment grouping: The attachments could be configured in groups, with the same attachment in different groups if desired. Each group would then have a hotkey to be used. For example, balanced fire on the first key, and some all-out energy-draining shot on a second key, to be used with parsimony.
• Reputation system: Depending on which missions you accept, you gain reputation with different factions, unlocking unique missions, equipment, etc.
• Cosmetic personalization: Now, I’m not an artist, so this will be very limited, but I’m thinking colors and decals on the war machine, at least.
• Research: Not all pieces of equipment would be unlocked at first. You would need to spend money on research, hoping you can get your hands on some new tech.
• Gathering: Money can’t buy everything. For some items, you would need to scavenge specific parts or materials on the battlefield… and bring them back home without dying.
• Multiple war machines: Considering the different environments and mission types, you would need more than one war machine. One could be perfect for an infiltration mission, another one to lay mass destruction, and maybe even one for those necessary transport assignments. All of those would be stored in your…
• Hangar: Sure, you’d need to unlock parking spots for your war machines, but you could also customize that to make it your own space. Maybe even have some kind of office, to receive potential customers.

“It’s soooo not unique!”

You’re probably right. I suppose that kind of game already exists. Maybe it even has more stuff than all those fantastic features I have in mind. And it certainly has better art than I would ever be able to produce. That’s OK. I don’t want to make the “next big thing” or anything like that. I just want to make that game, see it live, and call it mine. Miiiiine.

“It’s too huge a project!”

Totally, especially with me being alone on it. But again, that’s how I see the final version of the game. It might not go all the way there, and some features might end up being more annoying than fun. We’ll see.

So, what’s the plan?

I’m aware that this is a big project. There’s no way I can get to the finish line in a month, with even half the features mentioned above. I’m realistic, and I know enough about game/software development to not aim for that in this jam’s timeframe.

As such, my plan is to complete create a fully playable (but probably ugly as frap) demo, with these core elements:

• Battlefield (kind of the base of all this)
• War machine assembly
• Some kind of shop to buy pieces of equipment

Once I get there, ideally before the end of October, I’ll check which feature inspires me the most, then go with it. I really hope this jam gives me the momentum to continue working on this project until I see its end.

What’s next?

Tomorrow, I’ll list the tools I plan on using for this jam, and why I chose them instead of alternatives. Some are new to me, others are sure shots (in my opinion).

By the way, I didn’t mention it in yesterday’s post, but comments, feedback and questions are welcome anytime/anywhere in this DevLog-to-be.

Pre-jam post #3 - The tools

Are you excited? Are you? I know I am! The jam officially starts tomorrow, but considering its nature, I might go ahead and not cheat a little by getting started tonight. But first, one more (and last) presentation post, before I can eventually start the “dev” part for this devlog.

What tools I’ll be using?

As mentioned yesterday, I’ll be using a mix of tools I’m comfortable with, and some others that are new to me. After all, I did say I wanted to learn during this jam, so…

Game engine

This one is always the big question, and in the case of this jam, is going to be where I’ll be learning the most, I think. In my last jams and projects, I’ve been using Unity, like a lot of people I suppose. That said, I plan on doing a 2D game, and while it’s possible (and easier than ever) to do so in Unity, that’s still not its forte.

On the other end, my little brother told me about Godot recently, and I’ll admit I was a bit reluctant at first. Why? I honestly don’t know. Probably because I’ve been burned with a couple of promising engines and tools in the past, promising the world and its moon, then dying silently of prolonged inactivity, or changing their business model and/or technology enough to make my project irrelevant. But after reading a bit more about Godot, I decided to give it a spin last week… then decided I would give it a longer spin. It’s lightweight, easy to use, free on all accounts and it seems to have a great community. And I particularly like Python, so GDScript seems like a natural fit for me. All in all, I’m confident.

From what I’ve seen, the code editor in Godot is nice, but if I need to step it up a bit, I’ll certainly use Visual Studio Code.

Assets

As I mentioned in an earlier post, I’m a programmer, not an artist. In the last couple of years, I bought a couple of asset packs, mainly through Humble Bundle bundles. I’ll rummage through them to find assets looking and sounding like what I need.

On the graphics side, I’ll probably use Paint.net if I need to retouch things. If I need to create things, then… I seriously don’t know. I used Hexels in a previous jam, but I’m not sure it will apply well for this project. I guess I’ll see.

For the audio, if I don’t find what I want in the asset packs, I’ll probably experiment with BFRX to create sound effects and the particularly surprising Autotracker-C for its automagic music generation.

Source control and Project management

It’s not because it’s “only a jam” that I should not take this project seriously. And any serious project needs some sort of source control. There’s no way I’m just keeping undocumented backups in a vulnerable folder somewhere on my disk!

While there might be a source control system more adapted to game development, I really like how git works, and what more, it’s even supported as an official plugin in Godot. Now, to decide on a backend…

I considered GitHub and Bitbucket and decided to go with the latter. First, because I’m already using it heavily for work, so I’m aware of some of its features, and it will not be lost time to dig deeper. Also, I compared both’s project management tools, and I prefer how Bitbucket handles things. Considering I’m aiming for a private project while on a free plan, I came with this little comparison table:

While there are a lot more differences between the two, what’s listed above is what is important for me.

What’s next?

Now that I’ve written much about the project, it’s time to start getting down to it. I’ll start by some setup (e.g. create the Godot project and Bitbucket repo), then I’ll probably dig right into the battlefield scene. I’ll keep the UI stuff (shop and garage) for a bit later.

Any thoughts about those tools? Anything you would change? Something I didn’t see or think about?

Day 1

Done today (and yesterday)

• Bitbucket and Godot projects
• Player-controlled tank
• Camera following the tank
• Cannon that aims and shoots at the mouse position

Graphic resolution

I spent waaaaayyyyy too much time (over)thinking about the game’s graphic resolution. By default, Godot seems to configure the project as 1024x600. While this is a near-enough ratio for a lot of variants, I prefer to aim for a 16:9 ratio, so it scales perfectly on 720p, 1080p and 4K. However, I want to be able to embed the game on a web page, so going for 1920x1080 is a no-go. Also, 1280x720 (720p) does not scale exactly for the very common 1080p (pixels would be 1.5x). To be pixel perfect with all possibilities, 640x360 would fit the bill: 2x for 720p, 3x for 1080p, etc. But, not being a (pixel) artist myself, it seems a bit too cramped.

In the end, I decided to go with 960x540. This is slightly smaller than the default size in Godot, exactly 50% of 1080p to which it will scale perfectly if needed, while still being able to fit within a web page when deployed in HTML5.

Assets

I’ll start my development using the Kenney Game Assets 3 bundle, more specifically the Top-down Tanks Redux pack. I was (and still am) not sure the player’s war machine should be, but something like a tank sounds like a good place to start. I also like how the assets from that back allow me to assemble different parts on the tank, to fit with the core gameplay element of customization. I will need to tweak some things, and probably some weapons will not show visually when on the battlefield.

War machine

Starting with the basics, I created the player’s war machine. For now, I’m focusing on keyboard and mouse input, so moving with arrows or WASD, and aiming and shooting with the mouse.

I made the controls responsive, but I wanted to add a nice visual by making the tank rotate slowly as the player moves. Nothing fantastic, but it took me some time to get the maths done, without any exception when wrapping the angle over zero or tau. Also, the cannon follows where the mouse is, as one more visual indicator. The only thing though, the bullet always spawns at the rotation point, and not at the end of the cannon. Noted as a FIXME for now.

The war machine is currently assembled as a Godot scene, hardcoded to a specific hull, cannon and projectile.

What’s next?

For tomorrow, I plan to complete the following:

• Crosshair instead of mouse pointer for aiming
• Collidable objects in the battlefield
• Warmachines that can be assembled by code/config

Day 2

Done today

• Mouse cursor is now a crosshair.
• Fought with physics.

Game’s name: Privateer

I finally decided on a name for the game: Privateer. It reflects how the player will get mandates and missions from some higher powers, them being states, organizations, etc.

Now, it’s just sad that I can’t rename the topic in this forum. “Unnamed top-down shooter” sounds a lot less sexy.

Stupid physics (or me)

Aaargh! I’ve been fighting with the physics stuff for a while tonight, in order to manage collisions with eventual walls, obstacles and all. I suppose I’m going in the proper direction, but I’m still not there. Either the collision results in some weird rebound, or simply does not happen. At least, I’m not stuck with infinite inertia anymore. Well, it’s getting late, I’ll jump back on it tomorrow.

What’s next?

For tomorrow, I plan to complete the following:

• Win that fight against physics.
• Dynamically assemble war machines.

Day 3

Done today

• Movements and bullets are now controlled by physics.
• Added obstacles on the battlefield.

Fighting with physics, round 2

Thanks to some tutorials, and a fresh head this morning, I was finally able to implement physics-based movements and collisions, for the player-controlled tank and the fired bullets. There is still a lot to do, but the basics are there. I was also able to put an (indestructible for now) obstacle on the battlefield, making sure the player’s tank react accordingly.

A funny thing I noticed while watching those tutorials, is that they both use the same assets pack I chose for my game. Well, it seems that the visual aspect won’t be where this game shines with originality!

War machine from JSON

I made it possible to assemble a war machine from a JSON string. It all goes through an intermediate class, which I’ll be able to use in the garage when it’s going to be the time to let the player assemble their machine. It’s still far from complete, as is does not contain things like health, armor, bullet types, damage, etc.

For now, it allows to select:

• A hull: Each hull is a scene, with a sprite, collision shape and one or multiple attach points. The collider is re-parented to the war machine upon assembly.
• Attachments: A list describing which attachments (e.g. cannons) are tied to which attach point, and to which firing group(s) they belong.

For now, this looks like this:

{
	"components": {
		"hull": {
			"prefab": "Hull_TankDarkHuge"
		},
		"attachments" : [[
			{
				"type": "cannons",
				"prefab": "Cannon_Dark02",
				"groups": [ 1, 2 ]
			}
		], [
			{
				"type": "cannons",
				"prefab": "Cannon_Dark02",
				"groups": [ 1 ]
			}
		]]
	}
}

And here is the tree for a hull with two attach points:

What’s next?

Tomorrow, I plan to work on the following:

• Damage, health and destruction!

Day 4

Done today

• Crates can be destroyed.
• Revamped the classes and scenes hierarchy.
• Documented some stuff.

A bit of clean-up

Once I got the crates destructible, I decided to go and do the stuff a bit cleaner. I considered that obstacles (StaticBody2D), war machines (KinematicBody2D) and eventually some projectiles (RigidBody2D) can be destroyed. As such, they should all inherit from the same base object, so I had to add a level of indirection to all objects. Before today, each object was a PhysicsBody2D, but of different types. With the revamp I did today, the base object now has a PhysicsBody2D as a child node, aptly named “Body”.

The class hierarchy now looks like this:

─ GameObject: Any object in the battlefield
  ├── BaseDestructible: Object with health that can be destroyed/killed.
  │   ├── Obstacle: Objects like crates, trees, walls.
  │   └── Warmachine: Object that can shoot and/or move.
  │       └── Player: The warmachine controlled by the player.
  ├── BasePickup: Object that can be picked up by the player.
  └── BaseProjectile: Object shot (typically) by a Warmachine.

─ BaseAttachment: Anything that can be attached to a machine's hull.
  └── BaseCannon: Fires one or many projectiles.

And here is how the Player scene is assembled (most of it through code):

─ (Node) Player: Where the Player script/class is attached.
  └── (KinematicBody2D) Body
      ├── (Camera2D) Camera
      ├── (CollisionShape2D) Collider
      └── (Node2D) Hull
          ├── (Node) AttachPoints
          │   ├── (Position2D) Attach_01
          │   ├── (Position2D) Attach_02
          │   └── (Position2D) Attach_...
          ├── (Sprite) Sprite
          ├── (BaseCannon) Cannon_01
          │   ├── (Sprite) Sprite
          │   ├── (Position2D) Nozzle
          │   └── (Timer) Cooldown
          └── (BaseCannon) Cannon...

And a bit of documentation

While it’s interesting to put that kind of information in the devlog, I think it’s also essential to keep it alive and updated. Coming from a framework background, I tend to put much value in proper documentation. I also know how hard and time-consuming it can be. Considering this is first and foremost a game jam, I’ll keep it minimal for now, especially because I’m currently the only audience of that doc. A couple of notes in the README.md will do the trick (and a properly documented codebase, naturally!).

What’s next?

Tomorrow, I plan to work on the following:

• Different cannons and projectiles.
• An enemy war machine.

Day 5

Done today

• A single enemy, aiming (but not shooting) at the player and following them around.

Controllers

In typical component-based thinking, I moved the controlling of the war machines outside the Warmachine class, and into a dedicated Controller one. The player input was moved into a specialized controller for that. Enemy behaviors will also be coded into such controllers. For now, I only have one that moves towards the player, the tries to stay within a specified distance (min/max).

What’s next?

Tomorrow, I plan to work on the following:

• Having the enemy shoot at the player.
• New projectiles/cannons.

Day 6

Done today

• Can now add multiple controllers per war machine, using code or the editor.
• Danger, an enemy is shooting at the player!
• Added a gatling gun cannon-type.

Godot Tools for Visual Studio Code

Having two computer monitors, but being stuck to work in a single one, was not ideal, so I went in and configured Visual Studio Code as an external text editor. Using the excellent godot-tools plugin, I’m now able to do as I did in Godot (breakpoints, variable and scene inspection, etc.). It only took minutes to configure, and the process is well documented. I’ll see how I like it after a couple of days, but tonight at least, it felt less cramped, and did not seem to come with any drawback.

Controllers as components

Yesterday, I added a single controller as a member of the base Warmachine class. Today, I decided to extend that, so that any number of controllers could be added to a single Warmachine. This will allow for multiple concurrent control schemes (e.g. gamepad and keyboard+mouse), and will give me more freedom when assembling complex behaviors for enemies. I also made those controllers as scenes, so they can be added and configured from the editor.

Enemy shooting at the player

For now, the enemy is as dumb and aggressive as can be. One controller makes it charge the player, optionally staying at a minimum distance, and another controller shoots towards the player non-stop. This would probably need to be refined when working on proper enemies, but it does the trick for now as a proof of concept.

I had to do a couple of changes, mainly making the cannon class know who can be hit by the bullets it spawns. Making it configurable allows me to reuse the same cannons and projectiles both on the player and their enemies.

What’s next?

Tomorrow, I plan to work on one of the following:

• Detaching the projectile and cannon types.
• Basic UI to show the player’s health, and manage dying more elegantly.

Day 7

Done today

• Added a simplistic and not fully-functional HUD.
• Added a health gauge and pause button to that HUD.

Playing with GUI

I started to play a bit with the GUI elements. While some things are not as intuitive as they could, I ended up being able to do what I was aiming to. The HUD has a place for a minimap, gauges (and eventually text values) for health, shield, energy and heat, and a working pause/resume button.

I debated between a HUD with floating items in the corners or a full panel on the side. I decided to go for the latter. That way, the visible game area is a full rectangle, with no overlay masking anything, so I can be sure of what is visible or not. I don’t want the player to be killed by an enemy hidden behind the minimap!

One week in

It has already been a week since the jam started. While I’m not as advanced as I would have hoped, I can safely say that I learned a lot in that week. And the project is aiming in an interesting direction too. I feel like Godot was indeed the tool for the job.

What’s next?

Tomorrow, I plan to work on the following:

• Creating weapons by assembling cannons, projectiles and other stats (e.g. fire rate, damage, bullet speed).

Day 8

Done today

Weapons

I had a long day at work today, so I was a bit mentally tired tonight. In the end, I was able to create that Weapon class, which is now a scene to be attached to war machines. Some variables are exposed, like fire rate, damage, etc. I tested it on the enemy, and he’s now peppering me with its brand new heavily powered up minigun. It hurts. A lot.

What’s next?

Tomorrow, I plan to work on the following:

• Some clean up is definitely required in the whole weapon-cannon thingie.
• Once this is cleaned up, I will be able to create more weapon types: rocket launcher, flamethrower and the like.

Day 9

Done today

• Split the cannons vs. weapons logic.
• Made war machine assembly possible through JSON or scene.

War machine assembly clean up

I experimented with different paradigms for the cannons, weapons, machine assembly, and all in the last days (in fact, since the beginning of this jam). Considering the “customizable” part of the game is kind of at the heart of it, I have to make sure it’s solid. I took the time to clean up some things tonight, and it’s now more solid and customizable than ever. The same cannon (visual) can be used for multiple weapons if needed, and each weapon (and its logic) can be customized, both in the editor and through JSON. JSON is what I’ll use to serialize the player itself, while the editor is going to be used to create the enemies. In the end, no matter where the war machine configuration is coming from, it all behaves as it should.

Second-week rut

I suppose I should have seen it coming, as it was exactly the same pattern for the three years I did NaNoWriMo: the second week of a month-long challenge is just the worst. I burnt all the initial energy of the beginning and did not reach the middle of the challenge yet. The habit is not totally in place, the project is not advanced enough to be a “must-complete”, so it’s sooooo easy to just quit, and take back possession of my evenings. But I will not falter! Even if progress has slowed down in the last days, it’s still progress. I should focus on the little everyday wins, not on the mountain that stands in front of me. (Why did I just think of that right now?)

What’s next?

Tomorrow, I plan to work on the following:

• New weapons types.
• Heat emission and energy consumption for weapons.

Day 10

Done today

• Revamped the projectiles’ logics.
• Homing missile!

Grateful for tutorials

When starting the project, I looked for and found a couple of nice tutorials, which I linked to in a post above. Today, as I was working on new weapons and projectiles, I went in one of them in more details. This one, and another one about seeking missiles, really helped me produce a better and lighter system for my weapons and projectiles.

Homing missiles

I created a homing missile, which follows its target as it moves. For now, the target is hardcoded to the player, but I plan to have variable targets, like the enemies when the player is shooting, or eventual flares/lures to be used to evade those deadly projectiles.

What’s next?

Tomorrow, I plan to work on the following:

• New weapon types (again).
• Heat emission and energy consumption for weapons (for real this time).

Day 11

Done today

• Energy consumed and heat generated on attachment/weapon usage.
• Health and shield gauges flashing in the HUD when damage is received.

Change of plans

Even though I planned on working on new weapons today, I decided to enjoy my pre-(Canadian)Thanksgiving Sunday, and work a little less than usual. As such, instead of creating and testing new weapons, I went for simple-enough mechanics and UI changes.

Energy and heat management

Each attachment (only weapons for now) can use energy and generate heat. If there is not enough energy available, the attachment group cannot be activated/fired. Energy regenerates and heat dissipates with time. For now, overheating does nothing, except pushing the gauge to its limits in the UI, but I plan for some kind of automatic shutdown when a certain (configurable) threshold is reached, and death if reaching the maximum heat (the war machine explodes). It will be up to the player to configure where they want the automatic shutdown to occur. Too soon, and the war machine is always in cooldown mode, but too late and it’s “game over, man, game over!”. That will be one more interesting customization dynamic, I think.

What’s next?

Tomorrow, I plan to work on the following:

• New weapon types (maybe for real, this time…?).

Day 12

Done today

• Added a small laser weapon.
• Fixed some bugs:
  • Fixed a bug with excessive energy consumption when shooting weapons.
  • Fixed a bug where values like health and energy could regen over their maximum limits.
  • Fixed a bug where not all parts of the enemy would flash when receiving damage.
• Experimented with UI and popups.

Bug hunting

When creating and testing the new weapon type (laser), I noticed a couple of issues that I decided to fix right there. There was also this “enemy flashing” bug, where not all parts of an enemy would flash when receiving damage, that has been there since day one (well, since this flashing mechanic was put in place). Before having fun with new features, I think I might do a quick bug-fixing round, so the rest will be easier to implement.

Damage types

Right now, my damage system is quite simple. It involves removing health from the target equivalent to the damage amount of the projectile, which is determined by the weapon that fires it. Upon collision, the projectile is destroyed. As I said, a very simple thing.

To have more variety (and fun) with the weapons, I would need to implement (at least) the following features:

• A shield, which absorbs damage before it’s applied to health, and that regenerates over time.
• Some projectiles (e.g. laser) that partly/totally ignore the shield.
• Exploding/Area of effect damage, that deals continuous damage to one or more targets. Naturally, it cannot apply damage on each frame, so there would need to be a mechanic to apply damage on a repeated basis, per target.
• Damage over time (DoT), like burning, acid, etc.
• EMP to reduce energy or paralyze.
• “Hot” projectiles, which would increase the heat of the target.
• Something that would screw the controls, like making the war machine advance in a single direction, or shoot all over the place.

When heat or energy is affected, there should be some clear visual feedback. At the very least, the associated gauge would need to flash or something. Maybe some common animation may occur on impact too, like a small lightning when hit by an energy-depleting attack, etc.

Playing with UI

I’ve been playing a bit with the UI, to create some “Paused” and “Mission Failed” dialogs. I started to tinker with CanvasLayers and customized controls, and I realized that I should probably investigate the custom themes before I dig too deep in the UI design. This game will probably need some heavy UI when customizing the war machine, so I think it’s best if I experiment and learn with some simpler things first, like those popups.

What’s next?

Tomorrow, I plan to work on the following:

• New enemies (behaviors) and/or weapons.
• More UI experimenting.

Day 13

Done today

• Created a Theme resource, and reusing it in existing UI.
• Created a centralized EventBus, so events like “pause game” can be emitted from different sources (a pause button in the UI, the P key).
• Added a “Mission Failed” popup when dying, allowing to retry (which works) or abandon and go back to the garage (which doesn’t work, yet).

UI and flow

That, and centralizing stuff, was really the main theme for tonight. I know I can create additional weapons and enemies, so there’s no real feeling of (technical) exploration there, nor does it give a better feeling of completion. I may want to spend the next couple of days to “dress” the game area, maybe even starting to assemble the garage, where the player can customize their war machine.

KidsCanCode to the rescue, again!

I wanted to add a greyscale filter over the game area and UI upon death. It seems that with shaders, that’s quite simple… as long as you know what you’re doing. As luck would have it, KidsCanCode wrote a nice recipe to do exactly that.

What’s next?

Tomorrow, I plan to work on the following:

• Some UI and flow. Maybe having the player be able to go back and forth between the game screen and a (mostly empty) garage screen.

Day 14

Done today

• Added a mock “Mission Select” screen to navigate to and from.
• Added a timer when (re)starting a level or coming back from pause.

What’s next?

Tomorrow, I plan to work on the following:

• A “Misson” object, indicating the level to load, objectives to complete, etc.
• Mission objectives list in the game hud.

Day 15

Done today

• Created a global GameState object, holding (for now) a Mission.
• Created objective types and details, to be used for missions.
• Added a compact list of mission objectives in the game HUD.
• Added a more complete mission objectives list in the pause screen.

Global game state

I want to be able to look at and affect the current game state from any scene. As such, I made the GameState as an autoloaded script, using the CurrentGameState singleton name. The nice thing with this is that the same class can also be used to save and load the data to disk.

Mission and objectives

I created a Mission class, which can contain one or more objectives, as well as a summary, and an eventual “briefing script”. That script will be used to present the mission with a fixed dialog, actors, etc. For now, though, it’s only a string.

Each objective in the mission has a type, that defines what needs to happen: Destroy a number of enemies (any type or a special one), survive for some time, protect one or many units, capture spots or pick items up. By setting the type, the target quantity and some additional data (for some objective types), I can automatically format the objective as a short string (for the HUD) or a long one (for the pause popup), and display a formatted progression. I think this system will be flexible enough to manage what I want to do with it.

What’s next?

Tomorrow, I plan to work on the following:

• Have events in the game affect the current mission objectives (e.g. number of kills, time survived).
• Maybe a “Mission Complete” popup, when all objectives are met.

Day 16

Done today

• Printing the reason why the mission failed.
• Managing “negative” mission objectives (i.e. failure on a specific condition, like time-out).
• Added (and managing failure) on a “Complete in X time” mission objective.
• Current mission objectives status properly refreshed when popping the pause popup.
• Added popups for mission success and failure.

Mechanics vs. Content

I had a lot of fun implementing game mechanics since the start of Devtober. However, I realize that what is harder for me, is all the “content” stuff: creating enemies, levels, missions, etc. I think that it’s because it’s easy to know when a mechanic is properly implemented, but for the content… It’s not like you can test it to see if it works as it should. There’s a lot a subjectivity there. I guess my background as a framework developer is really showing here.

What’s next?

Tomorrow, I plan to work on the following:

• Handle the remaining objective types.

Day 17

Done today

• Fixed multiple mission-related bugs:
  • Time formatting now has a short version, to fit in the in-game HUD.
  • Checkmarks are properly added in the in-game HUD for mission objectives, as they get completed.
  • It’s now possible to complete missions that have “negative” objectives (i.e. survive for X time).
  • Timers and player control are now disabled upon mission completion or failure.
• Pressing “Pause” while the countdown is active now pauses the countdown, instead of restarting it.

What’s next?

Tomorrow, I plan to work on the following:

• Handle the remaining objective types.

Day 18

Done today

• Reworked/simplified objective types and formatting.
• Added a “Destroy” objective type.
• Added accounting for the following objective types: Kill, Destroy, Protect.
• Shield now gets damaged before health.

What’s next?

Tomorrow, I plan to work on the following:

• Health and shield bars for enemies and destructible objects.
• Explosion and destruction animations.
• Pickups.

I’m not sure yet of exactly what I’ll be tackling, but it’s probably going to be something on the game screen.

Day 19

Done today

• Added management of the “reach” objective.

Slowly but surely

While I do love this Devtober challenge, I must admit it’s been quite exhausting. I’m working all day on very technical stuff, then spend my evenings on more technical stuff (in addition to, you know, life).

To make sure I don’t burn myself and the project out, I’ll permit myself to stop after only one feature or bug fix per day. That means that I’ll have slower days (like today), but I think it’s the only way I can get through at least the month, and ideally the whole project. I might even go as far as allowing days off… but not before the end of the month!

What’s next?

Tomorrow, I plan to work on the following:

• Extending the “reach” objective, to manage the “capture” one.

Day 20

Done today

• Added management of the “reach” objective (with no visual indication of progress though).

What’s next?

Tomorrow, I plan to work on the following:

• Visuals in the game area: Gauges for enemies or captures, explosions, something like that.

Day 21

Done today

• Added a visual indicator while capturing a zone.

What’s next?

Tomorrow, I plan to work on the following:

• Some more visuals in the game area: Gauges for enemies, explosions, something like that.

Day 22

Done today

• Added a health+shield gauge for enemies, to be displayed only when not full.

What’s next?

Tomorrow, I plan to work on the following:

• There are a couple of bugs to fix, so I might clean that before aiming for new features.

Day 23

Done today

• Fix: The pause/resume button in the HUD is now properly updated when resuming from the pause popup.

What’s next?

Tomorrow, I plan to work on the following:

• Untangle the HUD, game area, camera and all that (so that no action occurs under the HUD).
• It’s Saturday, so I might be motivated to do some more visual stuff, or gameplay stuff, or something more substantial than in the last couple of days.

Day 24

Done today

• Fought with viewports.

Viewports, canvas, cameras, hallelujah!

Now that I know I want to have my HUD as a side panel, I’d like to use the remaining space as the gameplay area. This means having the player centered in that zone, and not in the whole game window/screen. I also want the popups to be centered in that zone. And, clearly, I don’t want any action to happen behind the HUD like it was the case up to now.

I’m reading multiple articles about viewports, cameras, etc. It may be because I’ve been a bit brain dead in the last couple of days, but I can’t seem to make sense of it all. This KidsCanCode recipe seems to hold the answers I’m looking for, but it came a bit too late in the evening. I’m keeping it open, and I’ll jump back to it tomorrow morning.

And if there’s a Godot king/queen among you, please let yourself be known; I would really appreciate some guidance here. ;)

What’s next?

Tomorrow, I plan to work on the following:

• Win that fight!

Day 25

Done today

• Viewports in progress

Viewports, day 2

I was finally able to create the kind of display I want for the viewports and camera. The player is properly centered in the game area, and game input still works as expected (aiming with the mouse, etc.).

However, since I started to play with viewports, it seems like the mouse clicks are not consistently reaching their intended UI elements (buttons). I guess I’ll have to come back and read this article once I’m a bit less brain dead.

What’s next?

Tomorrow, I plan to work on the following:

• Win that fight, for real!

Post-mortem

October has ended, and this Devtober project for me… Not exactly at the end, no. Far from it, in fact. Going in, I knew I wouldn’t be able to complete that fantastic game I described in my second post, but I still hoped I would at least have some kind of complete game loop: doing missions, piling cash/credits, upgrading the war machine… In the end, what I have is more like an embryo of a game engine.

That said, it’s not all bad. I learned a lot in this project, both on the technical and personal sides.

What went well

Daily accountability

I gave myself the objective of working on the project each day and report on it by the end of the day. To be fair, it really kickstarted the thing gloriously, and there was real and visible progress for the first two weeks or so. There was always something new to do, enough so that I didn’t even have a proper to-do list/Trello board at that point. Ideas were flowing in, and the motivation and energy were there to make them real.

It also helped, at the end of each day, to think about what I could do the day after. That way, if I was not inspired, I would just have to jump on that thing that I knew was ready to be tackled.

Choice of tools

In retrospect, Godot was indeed the perfect game engine for this project. It’s easy to use, fun to learn, and powerful enough for a game like Privateer, even in its expected final form. There’s also a large community around that game engine, and since the game I’m trying to create is not breaking any technological boundary, it was easy to find the help I was looking for (most of the time).

Using free assets also helped in not spending too much time/energy in creating them, considering this is absolutely not my forte (nor is it a pleasure for me). And since the assets came in a pack, it made the whole look and feel consistent, which was another nice win.

What went not so well

Daily accountability

Yup, this concept belongs to both “good” and “not so good” categories, at least for me. While daily accountability really helped to get the project going, it began to feel like a burden around the middle of the month. Fatigue from the project started to settle in, the initial motivation drive dwindling, and the rest of life still happening. After a hard day at work, where I gave it all, my mentally-drained self still had to work on my Devtober project. The initial tasks, full of discovery and concrete impact, were replaced by very specific bugs or features that were harder to implement and had less visibility in the game itself. The excitement was slowly replaced by some sense of dread.

I consider myself “lucky” to have fallen sick toward the end of the month. Nothing too bad, just enough for me to miss a day at work, and two nights on this Devtober project. Taking that forced break, having to rest for a little while, gave perspective to the whole thing. Sure, I already felt this project lost its fun and appeal some time before, but that pause gave me the permission I needed to just stop before I burn myself and this project out. If I am to see this to the end, I need to make sure I listen to myself and adopt a better/saner pace. There’s a reason why we do not (or at least should not) work seven days a week, for multiple weeks at a time.

Unclear goal and no plan

I described my ideal game in my second post, and already decided it would not be feasible in a month. As such, I targetted something smaller, complete, and doable (at least in my head). However, that something was not exactly clear, and I made no concrete plan to achieve it. Each day, I was just putting some more work in, working toward some unknown final state.

With a plan, I feel like I could have spent less time on some features (e.g. the viewport thing I was working on in the end), and focus on the targetted game flow. Yes, it would have been flawed and riddled with odd bugs left and right, but at least, it would have given me a good idea of the game in its entirety, and maybe would have helped with the motivation.

Takeaway & the future

The main takeaway, at least for me, is that there’s a limit on how far the excitement can carry a project. For something that large, I need more than “a good motivation and a kick in the butt”. I need a plan. A flexible plan, but a plan still. I also need to take care of myself. When I feel like it, I must take advantage of it and put the work in, but when I’m too tired, from work or otherwise, I need to rest a bit. In the end, I’ll get up and running faster that way, which is good both for me and the project.

As for this game, I still want to work on it. I think it can be fun to play, and fun to create. Not having a rigid development schedule, like the one I imposed myself last month, will help me bring that fun back in Privateer.

In the end, I am glad I participated in this game jam. I now have in my hands the very basis of the game I had only in my head for the last couple of years. Now, let’s see where it goes from there.