As announced in the last update, there’s nothing new this month I can present. But since it’s been quite a while since the last video, I recorded a short play session to show how everything is fitting together so far:
The video chronologically demonstrates the following:
Attacking an enemy ship
Player taking damaged, which is visually reflected in the ship graphics
Defeating enemy ship, winning gold
Sailing to port
Repairing ship with gold the player just earned
Buying and selling some items at the trader
Going out at seat again, attacking another ship (player ship graphics now are back to “pristine” since the ship has been repaired) and defeating said ship
Spawn lots of ships, pressing the interaction button -> menu pops up that let’s player chose preferred action
I already finished my other project, which means I’m back at Devils of the Sea again!
I always wondered, how emulators were made/what they exactly had to do to get games running.
So, I decided to develop a prototype of a CHIP-8 emulator for Unity.
The project was super interesting and I learned a ton! Anyone can check out (pun intended) the source code over at GitHub.
But be aware that it’s just a quick proof of concept and there’s not much code quality to speak of. Please don’t take this as an example how things should be done.
At long last, I can happily present the first version of the ship-to-ship combat AI!
It’s really simple, for instance it’s trying to aim at the center of the enemy ship, while often aiming a bit more towards the bow would make more sense.
But for a concept of proof, I’m more than happy with it!
Here’s a short video demonstrating the AI. The black ship is controlled by me, the yellow one by the AI:
One of my next goals is, to implement a simple naval combat AI to finally have something playable. I feel, this should have happened way sooner. Sure, you can sail around a map, enter ports, buy some things, etc. but that doesn’t feel like a game (no matter, how rough).
An AI deciding “I should catch up to the other ship!” or “The ship is in bad shape, I should flee!” is no good, if it doesn’t know how to catch up/flee/etc.
That’s why I’m currently working on some simple movement patterns.
The focus of September was on AI ship movement, mainly on path finding.
There are a lot of common path finding algorithms out there but there is one drawback they have: while they can take some information like terrain movement cost into consideration, they generally just find the shortest way assuming an agent could move however he wanted. This also means that they can’t calculate a path considering possible agent restrictions like that the agent can’t fully slow down (or only with some delay), an agent might have a limited turn rate and only be able to turn whilst also moving forward, etc.
Another thing they can’t do, for example, would be to also consider the wind direction and it’s influence on ship speed, to calculate the quickest/best path.
Unfortunately, an algorithm supporting all this would most likely be not only be computationally too expensive but also out of my league, time and ability wise.
So, what I opted for instead was the following idea: I use some standard path finding but instead of just moving ships along this optimal path, I’ll try to stick to the optimal path as much as possible but will only move/rotate the ship as much as the calculated restrictions allow. For example, when the calculated path tells me the ship should rotate 5° in a frame and the ship can only rotate 3° considering alignment to wind, wind speed, etc. I only rotate the ship 3° and will then try to rotate the rest in the next frame.
Following, you can see a video where I try this out with different turn rate settings. One important thing to note is that, at least currently, the ship can’t slow down and will always move as fast as possible as it can under the current circumstances (wind direction, etc), which further exacerbates the problems you’ll witness. This isn’t entirely realistic but might be kept for game play reasons. But even if not, the ship would most likely still have some inertia that will keep it from slowing down instantly.
Things to note
As long as there are no tight turns, movement works flawlessly.
Tight turns pose big problems.
With higher turn speeds, the problems become fewer but are still present.
There are situations in the video. where you can see the problem I described in the beginning: Since it has problems making quick turns, it would make way more sense for the ship to continue sailing around an obstacle and make a soft turn instead of trying to immediately turn around. But because traditional path finding calculates what it determines the most ideal path without considering the ships slow turning speed, the calculated path is totally different and causes the ship to do an almost 180° turn practically on the spot.
This picture shows the problem as well:
Why this might not matter
I currently won’t try to fix this for a few reasons:
The ship stats/controls aren’t calibrated at all. As long as I don’t at least roughly know, how the ships will steer in the end, there’s no sense in optimizing an AI for it.
Luckily, naval fights mainly consist of loads of water and the occasional “Arrrh!”. There simply will be near to no obstacles at all. At most a few ships and the rest is open space.
If there are practically no obstacles, having problems with avoiding them might simply not matter. But to be sure, I’ll have to develop a simple naval battle AI first.
What if it matters after all?
I do have some ideas on how I could fix or at least lessen this problems:
Ships could slow down and try to rotate in a smaller arc if the amount they want to rotate is greater than a certain amount of degrees.
Ships could not rotate when too close to an object so they don’t crash into it, etc.
I could try to calculate paths from a spot a little in front of the ship to the desired destination and use that path if it contains fewer path segments than the currently calculated path.
When sitting together with a friend and talking about my project, we came onto the subject of a dilemma I am struggling with almost since the beginning of this project: I’m very unsure of what to present on my blog.
I’m no artist at all, which means that (for the moment at least) I’m relying on bad programmer art, assets from very old games and assets made freely available on the internet (thank you, kind souls!). Especially because of the latter two, I am very reluctant to show anything on my blog. I don’t want to adorn myself with borrowed plumes and I also don’t want to raise wrong expectations what the game will look like. That’s why I almost always decided against showing something visual in the past. But if I don’t show any of this graphics off, it’s hard to show anything tangible at all because 90% of what I produce is source code and that’s very hard to present in a visual way.
However, my friend made some compelling arguments for just putting everything I produce out there at this stage of the project. His points made a lot of sense, at least to someone who admittedly deep down always wanted to do this anyway but was simply too worried.
He convinced me and I thought to myself “Yeah! I’ll go home and start putting my stuff out there! No holding back anymore!” And that’s what I did! Well, almost. This conversation with my friend took place back in March or April, I think. But hey, no good project without some good, old-fashioned delays, right?
Without further ado, I hereby present the first result caused by this decision. A short video of some of the features that are already integrated in the game: