Calendar Adjustments

As I ramp up my work on the project again, I am reading over and relearning a lot of code.  Today I got to the GameCalendar class and remembered that I had a bunch of changes I wanted to make before I’d stopped work on QubeKwest.  What I wasn’t sure of exactly, was what changes I wanted to make.  After a bit of consideration followed by a bunch of coding, here’s the things I’ve changed.

Tracking game ticks was a pointless complexity for the calendar system.  Thus it was removed and that of course means that the math ticks added into the calendar was removed too.  This makes several parts of the calendar easier to calculate and it also means that the internal workings of advancing the time for the calendar now only needs to happen roughly 1/53rd as often.  It’s not a lot of overhead, but I’ll take it.

Days were too short.  My brother and I have played a bit of Minecraft lately and been repeatedly frustrated by how short the days are.  While I’d already build days to be longer than they were in Minecraft, I decided I wanted to make them even longer, and a bit more asymmetrical in favor of daylight.  This table demonstrates what I’m talking about:

Part of Day   Minecraft   QK (Old)   QK (New)
-------------------------------------------------
Day            10 min     16 min     40 min      
Dusk          1.5 min      3 min      4 min
Night           7 min     10 min     12 min
Dawn          1.5 min      3 min      4 min
-------------------------------------------------
Total          20 min     32 min     60 min

This change adjusted how the game represents the current “wall clock time.”  In simple terms, the math is different for deciding what time of day it is.  The game will still represent the clock as a 24 hour clock of 60 minutes in each hour.  The length of a minute in the game has just increased.  (Now 2.5 seconds each.)

Seasons were too short.  Due to the length of months (16 days) it seemed incorrect to have seasons be only 2 months long.  Thus, I’ve changed to a 16 month calendar.  Now each of the 4 seasons is 4 months long.  I haven’t come up with names for any of the months, and I’m not even sure if I’m going to bother.

Moon phases still line up in the months the same way they did before.  This is because neither the length of a month nor the number of moon phases there are have been changed.  It doesn’t sound like a lot, but I was thankful for this break in the sweeping changes I was making.

Due to the collected changes, the timestamp format was adjusted to have a second digit for the day of the month. The resulting format is:

hh:mm YYYY-MM-DD

Calculating this was simplified by the removal of game ticks from the calendar, but it was an almost total rewrite for this method to accommodate that adjustment.  The best part is that the wall clock time and the timestamp are no longer only approximate values.  Since I now only track down to the minute level, the number of minutes involved is always exactly known.  No rounding errors any more.

Last but not least, the collection of constants used by the calendar were updated in both name and value to make using them a little cleaner.  It’s been a fun day that involved drawing in my notebook, coding, and correcting tests that I blew up with all these changes, but I’m also glad it’s all set now.

A Bit of Housekeeping

It’s been a long time since I made any serious effort on the holy grail task of getting a cube on the screen.  For that reason, everything I was trying to use to do it is now very out of date.  This problem resulted in a bit of housekeeping.  Since I’m in there updating tools and reading over code I’d written, I figured it was also a good time to grab the latest collection of libraries and assorted goodies and make sure that the new versions didn’t break anything.  Specifically, I believe it is time to bump LWJGL up to the latest version, and to seriously consider a switch from the main line of Java to OpenJDK.

I’ve been coding on Java 8 for a very long time.  I had everything I needed, and Oracle kept updating it with bug fixes and other useful patches, so I really didn’t have any need to change.  Recently however, Oracle has gotten onto a pattern of releasing major versions of Java much much faster than before.  In fact, since I last posted, the official JDK has advanced all the way to version 11.  With this new pattern of fast releases, they also appear to have changed the license agreement in a way that I don’t care for.

If I’m reading or understanding their new license correctly, they are making it pointlessly expensive to use Java to create commercial software.  I hope I’m just not understanding the intent of the new license, because if I’m right, it seems like Oracle is essentially trying to make Java itself go away by pricing themselves out of a market with dozens of other free options available.  As a coder that prefers Java to all other languages, this makes me rather sad and was the driving force behind my idea to switch to OpenJDK for QubeKwest.  With any luck, it’ll be pretty straightforward to do this, and unless I’m misunderstanding again, the use of OpenJDK dodges this entire license issue completely.

Starting to Itch

A friend of mine has been talking a lot about a game project he’s been working on lately.  In general, I love talking about coding projects, even when they aren’t mine.  I find it sets my mind spinning in fun and interesting ways.  When I’m not talking about one of my own projects, I mostly hope that I am a useful source of ideas for the person I’m listening to.  There is another side effect though.

Talking about other projects, and sharing in the excitement that other people have for their projects is great, but I end up missing my own projects that have stalled.  I describe this longing for my own coding projects as “itching to work on them.”  Thankfully there isn’t any actual physical itching involved, but conversations spawn ideas.  Ideas in turn spawn problem solving.  Problem solving causes a desire to put these theoretical solutions to code.

The last time I posted anything here was nearly a year ago now.  In that time I’ve worked on several other projects and as a rule, I’ve stalled out on all of them.  I’m not sure why I do this, but I think it has to do with getting to a part of the code that is hard or boring or otherwise just not something I want to work on.  The solution is to simply stop until I wish I was working on it again.  That time is fast approaching again.

To that end, I’ve updated my development tools to their latest versions for probably the 3rd or 4th time since I stopped work on QubeKwest.  I’ve done some thinking about my library choices and I’ve devoted enough time picking over the code I’d already written that I found some things to correct about my project documentation.  The itch is returning in full force, and I expect to resume working on the project soon.  Hopefully, “soon” really means soon this time.