Text 23 Jan 23 notes

Anonymous asked: How's progress on Sealark? I know it's pretty early, but I was wondering if you're enjoying it and not having too much trouble. v uv

Ack!  I didn’t see this in my ask box until now, sorry anon!

It’s going pretty well, I’ve spent a lot of the time programming, which is the most enjoyable part of it for me, though it’s also the least interesting when it comes to showing off.  I should though at least try and talk about it, sorry if much of this makes little sense! 

The most time consuming thing I’ve been working on is the overall structure the code takes, and making sure I’ve wrapped the libraries and OS calls away, so porting is painless.  The structure I have now lets me hardcode everything in C++, without using Lua or otherwise parsing outside files (sprite sheets, music, configs, and log files are exceptions of course).  Everything from dialog to individual events is hardcoded.  This lets me code events and systems as freely as possible with minimal friction.  (Friction being, if I were instead using a “game engine”, the effort needed to break free of an engine’s limitations and do something it wasn’t designed for.) 

The drawing system is done for the most part.  How it works is, there is a Drawable base class that can be inherited by classes that represent game objects that need to draw themselves.  This gives them access to a suite of methods, including being able to request image references, font references, screen coordinates, and perform common screen transforms (such as when drawing UI elements on screen).  They can then register one or multiple callbacks at different z-depths, for objects like rain, water, or boss characters that couldn’t be drawn correctly otherwise.  And finally a virtual “draw(int triggerID, Camera * camera);” method to overload.  This function is what is called by the main game loop after sorting the callbacks by z-depth.  This ensures distant objects are drawn first, and near objects are drawn over them.  This also makes it easy to not draw objects which have no active area on the canvas.  In which case they are never asked to draw().  Anything can go in this function.  From simple sprite drawing, to openGL drawing. 

Keyboard and mouse events use a very similar system, sans the depth sorting.  Any object ingame can peek at input, though none can actively change it, making it safe no matter what order objects get their input in. 

There is also a similar system set up to give every object a “frame” of execution, once every specified number of milliseconds, based on it’s priority level.  This is different from input and drawing, in that it’s guaranteed to trigger once it’s time has come, or multiple times if a single frame took too long to calculate due to low frame-rate (though, this effect caps off to prevent a lag feedback loop). 

Time is handled through a TimeManager singleton, and Time objects.  There are several “channels” of time, some of which are derived from other channels.  Essentially, you can change the tempo of a channel, and any Time object or channel deriving from that channel will reflect the change in tempo, thus speeding up or slowing down objects using those channels in-game, simultaneously, by merely telling them less/more time passed than has actually passed.  It’s also possible to completely halt the passage of time, though there’s no way to reverse time of course, aha.

And then there’s other boilerplate of course, but that about sums it up so far, whew!  I think it’s moving along at an okay pace, though I wish I’d have done more art than I have.  I’ll have to get on that asap, so I have more interesting things to show everyone come February and March!

Thank you for stopping by!

  1. pumpkinappearifier said: Thanks for the update, even though I hardly understood any of that. heh
  2. clairvoire posted this

Design crafted by Prashanth Kamalakanthan. Powered by Tumblr.