On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

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.