Weekly update 2D shooter #3 – Adding art!

The initial prototype works nicely (most of the time) but looks pretty bland (as well as bad, as is not optimized for pixel art yet), which is “normal” as I spent almost all my time in coding the initial game play and mechanics.

I track the time working on this game using Harvest and Trello cards, this image is from 10th of June, which shows 8.13h dedicated to Graphic Design. What the image does not say is that the same 10th of June I dedicated 7 of these hours, if we take that from the equation we have 48.60h tracked from which 30.49 are for coding and 7.75 for learning C# and Unity.

This makes 92% of the time was spent in code, and the rest between Marketing and Design (85% after making this screenshot):

Invested time in each part by 10/06/2018

This is not bad, or off. Is just the natural progression as without a working prototype you cannot really start to work in other stuff.

Before investing more time into new mechanics, implementing features from the Todo list and fixing bugs, this week I’ve put more time on putting everything together as well as on the art side. For example:

1) Project settings: Fixing the camera for the expected resolution, and optimize the project to support and display sprites and pixel art properly. This took take some research (like disabling anti-aliasing, as is something we definitely don’t want for pixel-based games) and re-optimization, as changing the sprite sizes will also change the perceived speed and pace at which the game is set up now, so I had (and still have) to re-think these.

By changing the resolution to 16:9 (as is supposed to be viewed in), you can see the actual difference between the playable zone before (red square) and after (black zone):

 

This means I have to redesign a couple of things before moving forward.

2) Art: Add designs, add animations, backgrounds, effects, explosions, particle systems, camera shakes, 2D effects, an improved scrolling combat text, health bars for enemies, GUI and general interface, menus, sounds, etc, …

Before all of that I have to chose a general art style and be consistent through all elements of the game. Through all of these hours coding the idea about the game varied widely: Will it be pixel art? Maybe 2.5D low poly? Or 100% top down? Futuristic? Abstract? Shiny? Dark? And I changed my mind dozens of times, however the game play and the mechanics underneath are the same:

A frenetic top down shooter, where controlled chaos is king. This is how it looked after the first day working on this (pretty different than the previous video, uh?) :

What will I use for this?

Sketch software for overall design & Aseprite software for sprites and animations, as Sketch is cool for vectorial-based art but is not the right tool for pixel art.

Other stuff like particle systems, camera shakes, scrolling text and such are still code based, but are graphic niceties so I’ll treat them as “Design”

I also started sketching some characters, that I’m unsure if I will use them or not, or if will be enemies, main character or something else entirely, say hi to space penguin:

 

Invested time in each part by 15/06/2018

 

At the end of the week I could add around 4h into the art side, and another 4h into the programming side for task related to art (aka animations, particles, and such), which ended adding lots of stuff for example:

  • Main character and basic animations (idle, shooting, getting hurt, ..)
  • Camera shake on hit
  • Pixel bubble explosions
  • Plasma explosions when generating a new enemy instance
  • Added dynamic graphical health bars for the enemies
  • Enemy basic animations

Here’s a little update:

And of course the scale was messed up a bit when making it pixel friendly, but I may add this as a game mode in the future, who knows? 🙂

What about next week? Bug fixing, keep adding art and start to plan what should include an MVP for a soft-launch.

Also worked a bit through the GUI, making the interface more appealing:

This week I’m almost 60 hours into the project, and even is my first one (and precisely for this reason) I don’t want to extend it for too long, trying to add infinite features, implement a thousand ideas or trying to make it perfect. At the beginning I though that 100 hours could be a good arbitrary timeline to launch a first project, but maybe is too little and somewhere around 120-150h sounds more realistic.

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 241 other subscribers

Tags:

Comments

Leave a Reply

%d bloggers like this: