It’s not entirely finished yet but I’m working on a system to give the player a choice of what to do whenever he interacts with the world and multiple interactions would be possible.
Before, one of all possible actions was chosen at random, which wasn’t very practical, neither for playing nor for debugging.
I’m not sure what I’ll do next. First, I’ll have to finish this system (still some kinks to work out). After, working on a fencing system is high on the list of things I’d like to do. I’ve been thinking about this for a long time and I still have no idea, what I’d exactly like to implement.
If I really go down that route next, I don’t expect to be able to show too much in the next few months because not only will I have to implement whatever I come up with, I’ll also first have to go through the creative phase of coming up with something…
Regrettably, I didn’t make a lot of progress during June. Over 3 weeks were spent on fixing a bug (or, as it turned out along the way, several bugs) that caused either the player ship, the enemy ship or both to seemingly not move smoothly/stutter during combat.
When plotting out the movement over time, everything was looked smooth as can be. That’s why I relatively quickly realized the problem had to be related to the camera, which turned out to be true.
I won’t go too much into details here but it had to do with the fact that different things in Unity are moved at different times (things controlled by the physics engine e.g. update their position at a different time than things controlled by Unity’s path finding/navigation system) and also at what points in time the camera was moved.
Normally, I don’t care too much for visual glitches at this time but I had a feeling that this could heavily impact core code components that determine how and when I move objects and I felt that such a fundamental design decision should be corrected as soon as possible.
In the remaining week, I didn’t have enough time left to finish something new I could present.
Admittedly, I felt a fair bit of frustration after spending 3 summer weekends just to get back to where I was before. That certainly doesn’t help with motivation but you’ve got to take the bad with the good and there’s always next month!
- Most important: I might get some help in the near future, which I believe would benefit my project greatly and also make working on it more fun; it’s nice to be able to share a passion project 🙂
- Spent quite some time on soundtrack related stuff. It’s not yet the right time to share anything, though.
- Updated some menus and made other small graphical changes to test out stuff like reflections in real battle scenes.
Although graphics aren’t important yet, there’s still a need to test some things out from a technical perspective to see if and how they could be implemented.
- Internal restructuring so scenes now can detect if they were directly started from the editor or loaded from another scene or save game. This is needed for components to know if and what initialization data they should load (e.g. player position).
- Added the shipyard which allows for repairing ships. Finally, we have a very small but 100% gameplay loop of “Fighting ships -> win -> receive gold -> go to port to repair ship -> rinse and repeat”!
This are the things I got done in April:
- Finished savegame/loading refactoring (at leastf or now 😉 )
- Thanks to the revised save system, I was now able to easily add some more things that get persisted in a save game and thus won’t be lost anymore when you switch between maps or load a save game:
- Direction player character faces
- Direction player ship faces
- NPC ships on overworld map
- Damage taken during ship fights.
- Added a game over screen
- Game now pausing overworld when opening the menu
- The blog now runs with https, which will hopefully further improve the search ranking.
- Fixed various bugs (walking animation bug, ships sometimes vanishing just after spawning, etc.)
- NPC ships can now be attacked in overworld
- Made a big update for the NavMesh2DSurfaceBaker. This wasn’t needed for DotS but someone using the 2DSurfaceBaker asked for some new features. I’m happy something I made is useful to someone and wanted to support them as good as I can. Just listing this here since it took the whole Easter weekend and I want to give you an overview, where all my personal coding time went . Hopefully, this will also pay off for DotS in the future 🙂
- Defeating an NPC ship now nets you some loot and allows you to return back to the map
Over all, I’m quite happy with the results. Since the player now can attack the spawning ships and gain some loot, we’ve finally got something resembling a small gameplay loop.
A thing I’ve long been waiting for and felt like I was “almost there!” for about a year now…
Originally, I wanted add some more gameplay related content. However, as I was working on it, I realized that I would make more sense to first rework the save system as well as some stuff concerning persisting data across different scenes.
Here’s a shot breakdown of what I roughly did in the end:
- Lots of changes concerning how games are being saved/loaded and how the game state is kept between different scenes (ongoing).
- Since Google also considers the page loading speed when ranking search results, my CESMAPRM (Chief Executive Social Media And Public Relationship Manager , also known as “I”) optimized this blog which, before the optimizations, sometimes took forever to load.
For those loving numbers as much as I do, here are some. According to gtmetrix.com, I managed to:
- Increase the Google PageSpeed Score from F(49%) to A(96%)
- Increase the YSlow Score from D(63%) to B(86%)
- Reduce the full load time from 4.4s to 1.3s
- Reduced the page size from 2.95MB to 1.62MB
- Reduced the HTTP requests from 73 to 27
- Lose half a day of work
- Learn more about WordPress than I ever wanted to
- Created a makeshift title screen
- Replaced the old text system with a new one to get clearer texts without having to tinker with every text to get it looking nice and sharp:
- Created some simple AI ships for the world map. Ships spawn randomly in close proximity to the player, sail to and then enter a port. Here’s a short video demonstrating this:
- Moved all my in-house hosted tools (code repository, issue tracker, wiki) into the cloud. As is the case with a lot of things in IT, what initially seemed like a simple task, got quickly out of hand. Everything that could go wrong (and some more things..), went wrong and what I estimated to be done in 6-8 hours ended up being close to 30.
I’m still glad, I did it, though. It was just a question of when and not if my home server failed. And when that moment would have come, it would have taken even more time to recover the data and set everything up again, let alone the cost of getting new hardware.
One thing less which causes a latent and constant feeling of impending doom 😉
- I started learning about shaders. This admittedly didn’t have the highest priority for the project but I felt a bit frustrated after the whole “move to the cloud” thing and sometimes you got to reward yourself 🙂
Here’s the result of trying to create some kind of water reflection effect for the naval battles:
- Figured out how to implement some UI related things.
A lot happened in January but most of it I already posted.
- Developed a system to generate NavMeshes (data telling the AI where it can move) from 2D objects.
- Finally finished the first naval battle prototype.
Out of curiosity, I created a chart that shows how many issues I created and resolved in the last 120. I was surprised how well you can match the pattern in this chart with things happening in my life: