UI update

I wanted to post an update on the new UI elements that are now in the game. I’m very happy with how they turned out. There are still some UI elements left that need to be designed and implemented but most of the placeholders are now replaced with real UI elements.

Here’s a screenshot of the new UI elements:

Adding a star system

Here’s a quick update on a new feature in the game! After some pre-alpha tests by some close friends, I learned a lot. Especially about how I thought people would like certain things and they ended up hating them lol.

One of these things was the whole “map view” combined with lives. The idea was, you get x lives, you die, you have to start over. Turns out this was way too hardcore for the type of game All Ships Must Sink was. Playing through 6 levels, only to die on the 7th meant you had to restart at level 1. I was hoping to create replayability with this, to engage the player to try again and perfect their game. Turns out it mostly lead to frustrating people, making them close the game in anger.

So the map is out and so is the hardcore type of life system. I’ve replaced them with a simple level select menu with a star system. If you fail the level, you fail the level. You can retry as many times as you like. The stars add replayability of the levels as it will be easy to get 1 star on most levels but (very) hard to get 3 stars. This way, depending on the type of player you are, you can choose to keep optimizing the same level to perfect it or just get 1 or 2 stars and move on. Either way is fine 🙂

Here’s a quick screenshot of how this screen now looks. It will need a design overhaul but you’ll get the general idea:

Visual Update

You might have noticed it already in some of my previous posts, but the visuals of the game has been re-done. The visual we used before were a combination of free licensed assets. While there is nothing wrong with using those, I felt like to give this game a unique feeling, it needed unique (custom made) sprites.

At this point, a lot of the sprites (images) are already done and in the game. Currently the UI elements (buttons etc.) are being drawn, I hope to have those in the game soon as well.

Here’s a gif of what these new sprites look like in action. New custom sprites in this gif are: background tiles (grass, water, etc.), scenery, cannons and ships!

Cannon recoil!

I took some time today to add a small visual feature that I think really does a lot for the cannons. Upon firing, the canon now has “recoil” meaning the barrel of the cannon is pushed back a little bit when it shoots the cannonball.

As you can see in this update (and a little bit in the previous one), the game has gotten a big visual upgrade as well. Pretty much all the sprites have been replaced with new, custom, ones. I plan to write more on this, and share some more device screenshots, later this week!

Here’s a quick preview how the cannon recoil currently looks:

Level Editor

I spent the past 2 days building an internal tool that will help me a lot in the future. It’s a web app (build in React) that allows me to create levels via a web interface.

From the start I knew I didn’t want to hard-code the levels into the game. It wouldn’t be flexible and would require recompiling the entire app every time a level is changed. Since I’m a web developer mainly, I knew a great way to store data readable in a file is JSON. So that’s what I did, I created a levels.json file and wrote a small Unity parser to convert that JSON data into data objects in the game.

There was one downside however, that I quickly ran into. The JSON file started to get pretty large already, making it hard to read and edit for me (as a human). And I only had created 4 incomplete levels yet. With the hundreds of levels I have planned for All Ships Must Sink, this was gonna be a real issue.

So I decided to create a web-app that allows me to parse a given JSON string, manipulate it via a GUI and then on the fly generate the new JSON. Only thing I now need to do is copy the new JSON string and paste it into my Unity project.

The tool’s been made in React and is directly parsing and storing the json into the browser memory. Here’s a quick video of the tool in action.

Game Menu

It doesn’t do much yet, but I made a game menu. In the future this is the place where options and other things can be set. For now I just liked to add this feature as it wasn’t a lot of work and, for me at least, make the game feel more like a game 🙂

I’ve been working on a lot of cool other stuff, I’ll make some time soon to write about that as well. Here’s a quick gif of the menu:

Super Early Closed Alpha Run

Yesterday I released a very early alpha version of All Ships Must Sink to a group of close friends. The game is far from anything I will eventually be. Gameplay is very linear, it lacks pretty much all features expect the very basics. I knew it would still have bugs (it did haha). It didn’t feel great to show a product that doesn’t feel finished to people and still I knew this was the right thing to do.

Because even though only a hand full of people played the game yesterday, I got a ton of great feedback already. From small UX things like “double clicking to place a turret doesn’t feel good” to deep questions about story line and level progression.

I don’t know if this is a the case for all developers but I know I get tunnel vision very easily. Having a couple of fresh eyes play the game and give me feedback is so important. It makes me realize I was wrong about certain assumptions. Which is great. Because now I can easily change them instead of continue to build on them for months and months.

I sent out a tweet today with a quick video (with bounce, I’m sorry I’m trying to be hip) showing in the current state, the slowing towers are too OP haha. Although balance is not high on the priority list at the moment, it does need some balancing to have a playable alpha. The tweet got some unexpected attention (12 favorites and 5 retweets as I’m writing this), which feels amazing! Anyway, here’s the tweet:

Quick preview video of the first alpha version on iPad. Sorry about the quality, I recorded this with my phone that was filming my iPad (yikes).

UI Overlay and Dialogs update

As the last part of the UI update I’ve done this week, I’ve updated the overlay and dialog today. These were also using placeholder beach tiles which needed to be replaced for both of those reasons. Anyway, this is gonna be a post short on text, rich on images. Here are some new screenshots.

The new overlay
The new menu
The new build menu

UI Buttons Update

Today I visually updated the UI control buttons (on the top of the screen). The ones I previously used were matching the version of the game which still had beaches. But since the beaches are gone, so are these buttons.

While I was at it, I optimized how the buttons work as well. In terms of code they now share the same class. But they are now also re-clickable and have an active state. This makes it visually clear if a button is pressed / activated. I also added the option to pause the game by clicking the play button again. While the game is paused, towers can’t be build but this does give you some time to think and figure out how you want to solve a wave you didn’t expect.

Again, finishing this devlog with a quick screenshot:

Turret Visual Update & Cannonballs

Today’s been mostly about turrets. I started with updating the sprites to something I hope matches the theme of the game more. The turrets are now cannons used by a person that shoot cannonballs at the ships. To keep things simple, I’ll keep calling this cannon+person combination “turret” on the devlog.

Next up was to make the turret rotate so it is facing the ship it’s shooting. I decided to let the turret continue to rotate the target it is currently focusing as long as that target is in range. So even when the turret only shoots once per 2 seconds, it will continue to rotate around its axis every frame update.

Last up was adding projectiles / cannonballs. These are actual objects that cause damage on hit. So the turret no longer damages the ship, the actual cannonball does. For now, I’ve created this cannonballs in such a way that they will always hit the target it is originally shot at. It will continue to follow the target until it hits it. Visually this isn’t really noticeable because of the speed the bullet travels. I think I will change this behavior later, calculating a cannonball trajectory when shot. This allows the bullet to miss if it’s not fast enough. This will also allow the cannonball to hit a different shit it wasn’t shot at (say ship 1 is too fast but ship 2 is tailing ship 1, causing the cannonball to hit ship 2).

Anyway, enough ideas for the future. Here’s a quick video of the new turrets in action.