Wee Free Studio
  • Home
  • Games
    • Powargrid
    • Key, Shovel, Treasure
  • Blog
  • Asset Store
    • Bug Reporter
    • Guided Missiles
  • Press
  • Contact

Instant Islands

9/29/2017

1 Comment

 
​Another week and there is more progress to show for Key, Shovel, Treasure. As I said last week, that's one of the advantages of working on visual stuff. Actually, the visual stuff is nearly done now. For the in-game sprites, only the treasure is left:
PictureShouldn't be hard to spot the low-res treasure sprite.

So what's new compared to the last update? Mostly, the lands have had an overhaul. Here's a comparison of the old and the new look:
​As you can see, all lands were square and had no texturing. In order to make the land tiles look better, they at least need shore lines that aren't straight. Also, some subtle surf around the beaches helps to soften the transition between land and water. So I spent an afternoon figuring out how best to create these effects.

One disadvantage of having better looking shorelines is that repetition becomes an issue. As long as all your shorelines are straight, with sharp 90 degree corners, this is no problem. But if a more wavy coastline is repeated, it becomes more difficult to ignore that some shores are the same. Apparently there has to be a balance between naturalness and repetition for things to make visual sense.

The solution is simple enough: draw multiple sprites for each type of land and randomly select which one to use when generating the map. I figured that three sprites per type of land would be a good number, which turned out to be correct for all lands except the peninsulas (peninsulae?) that have one land neighbour. Tose requires six versions to prevent repetition. But that did mean drawing 24 lands and also 24 covers for the undiscovered tiles. I wanted the covers to exactly overlap the lands so the surf is also visible around undiscovered lands.

Even with a good workflow this is a lot of work, so I spent some time looking for a way to automate the process. I use Paint.net for creating artwork, which works really well but doesn't have a macro function. And as far as I could find, there's no plugin that adds macros. This led me to search for an external program. After some experimentation, I settled on AutoHotkey.

As the name implies, AutoHotkey allows you to create new hotkeys for general use. You can add scripts to these hotkeys and sends things like key commands and mouse clicks. I created an AutoHotkey script that creates a land, the surf and a land cover starting from an outline of the coast.
Picture
Part of my .ahk code for generating land sprites. There are probably a ton of things in there that could be done more elegantly and/or efficiently. For instance, I just noticed that I could have written "Send, {Up 3}" instead of three times "Send, {Up}". But the goal here was to write something that works. Which it does. Mostly :).
Of course, this wasn't as simple as I would have liked (nothing in gamedev ever is it looks like). For instance, it took me some time to figure out that some operations in Paint.net don't get completed instantly every time. This causes problems, since AutoHotkey sends the next command immediately. Having your script fail only part of the time instead of consistently makes it a lot harder to figure out what is going on. Adding some 100 millisecond sleep commands in a couple of places fixed this issue for me. But it's quite possible that with a different (faster?) PC, this wouldn't even have cropped up.

Another problem was that my script kept clicking in places that were not at the coordinates I specified. A logical culprit was that the script was using the Window CoordMode, which calculates the coordinates relative to the active window, instead of the Screen CoordMode, which looks at the absolute coordinates on the screen. The fact that the colour palette in Paint.net is its own window pointed in that direction as well. But I also found that the default setting for CoordMode is the correct one: Screen. So the CoordMode couldn't be it and I searched on. What I should have done instead was test this by adding the line "CoordMode, Mouse, Screen". When I did that, it quickly became apparent that the default (for my script at least) wasn't set to Screen and the bug was fixed. I guess  that's another programming lesson learned :).

Something that came in really handy was an Autohotkey script that displays the current cursor coordinates (by Jackie Sztuk_Blackholyman on the AutoHotkey board), since I needed a way to determine where to have AutoHotkey click. Makes me realize that  having an active and engaged community is one of the greatest assets a program like AutoHotkey, Paint.net or Unity3d (or many games for that matter) can have.

Eventually, I got the script to work 90% (or so) of the time. Which is good enough for my purposes, since I'm not planning on using the script regularly. The time I saved probably is insignificant, but I did learn a lot about scripting with AutoHotkey in the process, even though I hadn't heard of it before last weekend. Funny where gamedev can take you. The big advantage of having this script is that if a land shape I made doesn't really work in game, I can now easily redo it. Also, if I want to change how the lands look, for instance change the colouring, I can simply change a part of the script an re-run it for the lands I made.

Seems I'm more and more getting into the habit of thinking like a programmer. And looking at things with the eye of a (nit-picking) artist:
Picture
This is a comparison of two options for the lands: with and without a border between the tiles. I was wondering which of these looks best, so I asked Michiel for his opinion on this. He told me he preferred the version without the borders, but also that in the (full game) screenshots I sent him, he was hardly able to tell the difference. I'll just tell myself that looking at smaller and smaller issues is a sign of progress.

Speaking of progress, the palm tree pictures were also updated:
Picture
Again, drawing better pictures meant that repetition became more obvious and more versions were required. In drawing the new versions, I decided to do some research into how palm trees actually look. This led me to first draw a way too detailed version, which turned out way too blurred in the game. After that, I found that more realistic colours didn't stand out very well against the land tiles I created, so I moved much closer to the colours I used in the old image. Hence the evolution of the KST palm tree:
Those are the Key, Shovel, Treasure updates for now. I'm happy with the progress over the last couple of weeks. In a couple of weeks more, with a bit of luck, we'll be able to provide you with a link to the finished version.

- Willem -
1 Comment

Key, Shovel, Powargrid

9/21/2017

0 Comments

 
Another week, another update on Key, Shovel, Treasure. Slowly but certainly, I'm getting the hang of this graphics stuff. The upshot of that is that I have things to show :). Here are the new versions for the key and the shovel:
Picture
Picture
And here is how they look in the game:
Picture
I also updated the menu for team play. You could choose between teams 1 and 2, but those numbers mean nothing in game. So I changed the numbers to the I cons I've also used on the sails: a skull and a set of cutlasses.​ So the menu now looks like this when teamplay is toggled on:
Picture
I think this is much clearer than using numbers. And the icons make sure that the selection here is linked to what you see in the game.

​I've also fixed a transparency issue in the menu. It helps for clarity if the menu items for players who are not in the game are transparent and non-interactable. And the same goes for the team selection elements if teamplay isn't on. When I first put that in the game, I used a hack by simply covering those menu items with a semi-transparent image of the same colour as the menu background. But that no longer worked after I created parchment for the background.

So I set about trying to find a way to actually set the alpha of the menu items. Turns out that you can loop over all the children of a game object, which looked promising. Not having to separately set the alpha for every individual menu item sounds good to me. But then I ran into the problem that accessing the alpha works differently for the various types of menu items like texts, buttons and images. Which meant more work than I'd hoped.

And then I found out about Canvas Groups. Which do exactly what I wanted. You can use them to set both the alpha and interactability of a menu item and all its children. I guess the lesson here is Google first, code later :).
​
Picture
One thing that Michiel has been commenting on project-wise is that hitting the play button from the game scene in the editor doesn't start the game properly. So testing always involves switching back to the menu scene before starting. Today, my own annoyance at having to switch back finally got to the level that solving this moved to the top of my list of priorities. After some (more) Googling, I found a great solution for exactly this thing on Unity Answers.

Turns out you can add menu items to the editor by placing a script in a folder named "Editor" in your project. And the script that you need for this is really simple, courtesy of the people who put in the time to figure this out. You can find the relevant thread here. This may just become a standard addition to my Unity projects.
​
Last but not least, something about Powargrid (and yes, I couldn't resist using KSP as a title for this post). It's been a while since we've said anything about Powargrid, but we certainly haven't forgotten about it. As we've said before, we're running Wee Free Studio next to our day jobs (and our family lives of course), so the time we can invest is limited. But having said that, we're still working on the next Powargrid update.

The main part of this update will consist of a number (we're not yet sure how many) of missions that can be played independently from the campaign. We're calling them Challenge Missions, since they're supposed to be a challenge for players who have finished the campaign. But they will have an easy setting if that's more to your liking. And a hard setting for if you're feeling particularly masochistic.

These mission will have dialogues, just like the campaign, but no overarching story line. So the order in which you play these missions won't matter. Story-wise these missions are set after the campaign. Having said that, we're do try to keep the spoilers to a minimum.

Speaking of which, here is a screenshot of one of the challenge missions (obviously a work in progress):
Picture
​We'll certainly write more about this update when it gets closer to completion.

Until then: remember that to err is human, to arr is pirate!

- Willem -
0 Comments

Pirate Arrrt

9/15/2017

0 Comments

 
As I wrote last week, doing graphics and art(ish) stuff is slow going for me. But there is a bit of progress to show you on Key, Shovel, Treasure. Which, come to think of it, is an upside of graphical stuff: you've got something that's easy to show afterwards :).
First off, I added the parchment backgrounds to the UI elements in the game. Getting them right took quite a bit of tweaking, but I'm happy with the result. Here are a few examples from before and after.
Next, I experimented with the look of the sea tiles. Uniform blue tiles do a good job for clarity, but it is nice if the sea looks a little more watery :). So I created five water tile images with different swirly patterns (yay for Paint.net plugins and cloud rendering). When the map is generated, each tile is assigned an image at random and is turned a random amount. The result is rather subtle, but does the job of breaking the monotony.
Picture
A while back, Michiel suggested (for another project) to slightly vary the colouring for the tiles using Perlin noise. This could add a bit of variation on a larger scale. I may give that a try as well. And here I am, still wondering how it is that one always gets lost in the jungle that is gamedev ;).

The last thing I'd like to show you today is a work in progress. I'm re-drawing the boats for the game, so they'll look more like actual pirate ships. In the gallery below, you can see where I started and where I'm at now.
The skull and cutlasses will be added to the sails in team play. I'm uncertain whether I should keep the skull white or whether I should make it black as well. I think black looks better, but white probably makes for a (even) better visual distinction between the teams. Oh, and of course there will also be a skull on the main sail. Other than that, I still need to add the steering wheel and perhaps some more decorations such as a band along the ship in the player's colour.
And that's it for now. Slowly but certainly we're getting closer to a finished game :D.

​- Willem -
0 Comments

Logo and Localisation

9/9/2017

0 Comments

 
Here's another quick update about Key, Shovel, Treasure, our pirate game side project. Progress has been slow, mainly due to other fun stuff like a festival and a LAN party eating away at my gamedev time, but there are a few things we can show. First off, the logo for the game clearly needed an update. I'm quite satisfied with the result:
Picture
Before
Picture
After
Doing graphics stuff is always a slow process for me, mainly because I don't do this often enough to really get it into my system :). However, I did learn a lot about using Paint.net. Mainly thanks to people who have been so nice as to write tutorials. I'll be adding the same sort of parchment-y look to the backgrounds for the menus as well.
I've also added localisation to Key, Shovel, Treasure. This turned out to be more work than I'd initially thought, just like most things in gamedev (or programming (or life for that matter)). But I've now made it so that adding an extra language only requires an extra column in the localisation.csv file, two text files to be translated (for explanation and credits) and a new version of the logo. There is no need to do anything in code, since the game now auto-detects the languages that are in the csv file and adds them to the languages dropdown menu under settings. The fun of automating things aside, this prevents headaches from trying to find out how I programmed this stuff if, a year from now, I'd like to add another language like French (Clef, Pelle, Trésor anyone?).
Of course, the language I've translated the game to is Dutch. There's something to be said to translating this game to a language that my mom and my kids can actually read ;). Here's the Dutch version of the menu:
Picture
A truonsletiun tu Svedeesh Cheff Speek is ilsu un ouptiun. Bork Bork Bork!
That's all the progress for now. There are a couple of things I want to do before I think this side project is done (enough). Having said that, I've certainly learned by now that there is no such thing as a quick side project for me. Not if the goal of the project is to build something I'd like to show to the world (by putting it on itch.io in this case). A valuable lesson I'd say. So valuable that I predict that this wasn't the last time I've had to learn it ;)

- Willem -
0 Comments

    Author

    We're Michiel and Willem. This blog is about our adventures in game development.

    Check out our turn-based strategy game, Powargrid:

    Buy Powargrid Now

    Archives

    November 2017
    October 2017
    September 2017
    August 2017
    July 2017
    June 2017

    Categories

    All

    RSS Feed

© Wee Free Studio | Steam | Twitter | Facebook | RSS feed | Press | Contact