Skip to main content

Darek Greenly

Personal blog, expect game dev and web stuff

GrayScale – dev log #3

Rules are made to be broken.

Player input and visuals

I decided to get rid of GameBoy style input limitation in favor of 360° walking, aiming and dashing. This will open up a lot of possibilities for puzzles and give more freedom in fighting. So in the end players will be able to play on mouse/keyboard setup or using their favorite gamepad and play with analog sticks to aim dash direction.

With this I need to get rid of smooth-follow camera I talked about last time. Right now the camera is locked on player. I got inspired by the game Awesomenauts, right now I have a similar cursor to theirs and your charactes is always in the middle.

A little white box is replaced with a robot guy from the original GrayScale prototype! Fun fact: head and legs are animated independently (2 different sprites) which saves me a lot of sprite animation drawing. Head will always follow a mouse cursor, that’s aim direction, and legs will animate independent of the head.

I started using TexturePacker to merge (almost) all the textures, which didn’t work well with luxe’s SpriteAnimation component. I drew all player animation frames in one file: head looking around, legwork and other animations are put in 16x16 grid, in 4 rows. TexturePacker treats that whole file as one “frame” in a frameset. Luxe’s SpriteAnimation component can’t guess if given packed texture is a mixture of actual frames and independent animations, which in my case it is. I had to modify this component a bit to correctly setup player animation.

In the mean time I’m preparing some functions and variables to be used in new powers. One example would be grab/throw mechanic. My last GBJam game RUSH used it and it was pretty fun. I can already think of much more use cases for it.

On a side note, I’m just amazed that my XBOX One Controller is natively supported on Ubuntu! I remember waiting for the official driver to come out back when I had Windows installed… Linux never stops to amaze me.

Decorations, details, colors

Cracks in metal plates, tiny rocks, smudges on a carpet are just a couple of extra tiles that I can freely add on different layer. With Tiled I can rotate and flip each “decoration” making it appear less repetitive. I’m going to apply many decorative tiles in future, when I eventually get to creating other worlds.

I’ve also decided to make color palettes use 5 colors instead of 4. More colors = more details and 5 should be enough for what I’m planning to do.

More internal stuff

Actors now have on_ground and mass property. The first is used with jumping and stomping. Can’t jump when already in-air and can’t stomp when not in air. Mass will be used with the grab/throw mechanic. Basically, each actors mass can be described in 3 ways:

  • light - can be grabbed with lvl1 grab component,
  • heavy - can be grabbed with upgraded component,
  • none - “ungrabbable things”, eg. bullets, trees, bosses and things I don’t want players to be running around with.

More tools

I’m always trying to automate as much work as I can. This brought me to start creating tools for myself. I’ve already got 3 tools in the works, but only 1 of them is finished enough to be used:

  • AutoTerrainGen - helps create terrain tilesets for Tiled. This one is big, I’m very proud of this and will try to update it with more functionalities while working on the game. There are still some features missing.
  • World Map Editor - whole game world will be separated to zones, which has planets, which has rooms. I need a place to manage all that.
  • ParseWallTiles - another tool for Tiled, helps create complex walls much faster. Draw complex walls with one tile and It’ll redraw it with visually correct tiles.

Next

As mentioned in the previous devlog, I started working in weekly sprints. I choose couple of tasks and set myself to finish them in each sprint. The next sprint is titled COLLISIONS:

  • Use Quad tree collisions - will probably need to modify the way luxe’s TiledMaps are displayed.
  • Simplify collision meshes - big chunks of tiles will need to be converted into a bunch of bigger shapes -> less collision shapes -> faster calculations
  • Swept AABB collisions - if I have more time. This one is interesting and I keep delaying this topic. Time to experiment!

If you’re curious for more real-time updates from me, you can always follow me on Twitter @zielak.pl !

Cheers!

Comments