next »

[Thaumaturge]

As this game is still (very much) a work-in-progress, much shown here is incomplete, some may well be out-of-date, and all may change over the course of development!

What is it?

In short, Moons in Crystal is a top-down fantasy "space" metroidvania.

In more detail:

As a spirit piloting a brass-and-crystal vessel, explore fantastical (and sometimes-strange) moons--and avert a system-devouring doom.

Through exploration, combat, and occasional trade, the player will gain artefacts that provide combat-spells, and traversal upgrades that will open new areas. Not to mention a number of lesser items!

All of this is to the end of averting a terrible calamity: an approaching, devouring presence that, if not stopped, will consume the local systems.

The setting

The setting is built around a strange sort of "crystal sphere" cosmology: Each solar system has a planet at its centre, orbited by a number of moons, and, at the furthest extent of the system, a small, bright sun. All of this is then bounded by a great crystal sphere.

And it is the moons that are intended to be the central focus of the game: Varying in size, each is different in its content--be it exploration and action, or NPCs, or even just a small respite.

And each moon has a theme. Some of these themes are fairly mundane: a "cave" moon, or an "ocean moon", for example. Others are more magical--an "ossuary" moon, or an "aethereal" moon, for example. And still others are strange--a "bubble" moon, or a "sky" moon, for example.

Movement between systems then is accomplished by flying into the sun.

Suns in this setting are not objects composed of matter; rather, they are portals, doorways into a realm of heat and light. Thus, by flying into a sun, one passes into that realm. Once there, one then has access to any other suns within travel-distance. And through those other suns, one has access to other systems.

[Thaumaturge]

Blog post (19th of July, 2021)
Moons In Crystal

Summary: In which a new project is introduced; and the course and state of said project is discussed in brief.

Greetings and salutations!

And welcome to the first dev-log entry for my new project:

Moons in Crystal



The first post above covers (I hope) the question of what this game is. This first dev-log entry, then, will cover it's progress thus far:

Moons in Crystal is my pivot-project: the project that replaces A Door to the Mists as my main work.

In this, it has, I hope, the virtue of being quicker to make: with a lighter art-style and a (largely) top-down perspective, levels should, I think, take rather less work to construct. Further, I imagine that it will prove easier to market to a publisher: an action metroidvania is, after all, not an unfamiliar prospect.



But don't let this deceive you into thinking that I'm not passionate about the game! Indeed,  I recall that this was a project that I wanted to make even before the cancellation of A Door to the Mists, one that I'd had an itch to work on. I've simply started work in earnest sooner than I'd previously thought to do.



As to the course of the project thus far, it has changed somewhat already.

In some of its earliest forms, I envisaged the game as something like a half-roguelike: no metroidvania elements, and randomly generated--but without permadeath.

However, I think that I concluded that this demanded quite a lot of time and work: to make each run different, I would want an awful lot of moons, and quite a lot of weapons.

So I pared it down somewhat, and added a little: the game is now intended to have a non-random, more hand-designed game-world, with with some greater complexity added into its traversal and exploration via metroidvania upgrades.



So, how far into development is the project? The answer is: "Not very!"

A number of the base mechanics have been implemented--too many to comfortably list here in full, I feel! Suffice it to say that the player can move around, explore, shoot, collect, and even interact to a limited degree.

However, a number of other mechanics yet remain. Further, only a little content has yet been made.



That said, I do think that I have one of the smaller moons--the "crystal moon" largely done!

I'm not yet sure of what interval I'll take for these dev-logs--weekly? Fortnightly? Something else? We'll see!

That, then, is all for this post--stay well, and thank you for reading! ^_^

[LucierBlazquiz]

I could see the potential in this. I like the idea that you go to an area and it keeps scaling down, down, down as you further get into it - exposing little details you didn't think of before. I could imagine that having a pleasing psychological effect.

[Alain]

Cool, I'm looking forward to see where this is going!

[Thaumaturge]

Thank you both! ^_^

I like the idea that you go to an area and it keeps scaling down, down, down as you further get into it - exposing little details you didn't think of before. I could imagine that having a pleasing psychological effect.

I'll confess that this isn't really something that I have in mind. ^^;

(Although I think that it could indeed be a neat idea in and of itself!)

Rather, the game can be thought of as having three "layers": The "bright realm"--which is a bit like what a sci-fi game might call "hyperspace"; the solar-systems; and the moons, planets, etc.

Within a given "layer", the scale is pretty much static, with the focus being primarily on horizontal exploration and combat.

[Thaumaturge]

Blog post (2nd of August, 2021)
Encounters and Abilities

Summary: In which a current blog-schedule is decided; development continues; "encounters" are implemented; a design document is made; and "metroidvania abilities" are contemplated and concepted.

Greetings and salutations!

This post's screenshot shows a new bit of (work-in-progress) UI:



As you may have gathered, I've chosen to post these entries fortnightly--at least while the project is in this first, nascent phase of development. As to what's been happening:

To start with, implementation has continued. In general, tweaks, fixes, changes, and improvements have been made to a variety of elements, I do think. For example, I recently improved the player-character's collision-response on impact with NPCs.

But perhaps the most salient change has been the implementation of "encounters".

During the course of the game, the player may come upon various interactive objects; these are marked, on approach, by a little popup that appears over them.



In some cases, the associated interactions are simple: the player presses the "interact" button, and something immediately happens, with no intervening UI. For example, on interacting with a set of stairs, the player is transported immediately to the place to which they lead.

In others, however, an "encounter" is begun.

As shown in the first screenshot of the post, above, this takes the form of a little RPG-like "choice-and-response" dialogue: A text-box describes the current state of the encounter, and the player is given buttons containing various available responses. Clicking on a button selects that response, potentially changing the state of the game, and prompting the text-box to be updated with a description of the effects of the response.

Moving away from implementation, I've also put together a proper (or more or less so, at least) design document. This pulls together my impromptu notes and former somewhat-structured text-file into a document with a little more detail and a proper contents-page, the latter making for easier referencing and updating, I find.

And finally, I've been giving thought to various matters of the game's design. One that has perhaps been of particular concern has been that of "metroidvania abilities"--those abilities that unlock progression and new paths.

First, one of the abilities that I have in mind was for a time--I felt--a little more interesting than the others. Thus, should I give it to the player before other abilities, those subsequent abilities might feel underwhelming; while if I give it to the player last, the player might not have the draw of knowing that it's available.

And second, there's question of what constitutes "enough", both in number of abilities and in depth.

Would just three or four, most with multiple applications, be "enough"? What if I filled out the list with a simple "lock-and-key" ability? Such a list feels a little lacking, I fear...

Thankfully, just yesterday a new idea for an ability came to me, one that I think could be quite neat.

As an ability it's somewhat interesting, I think, perhaps helping with my first concern above: it would give me another "interesting" ability with which to start the player off.

Further, and together with one or two minor ideas, it then leaves me with: three abilities that I'm confident in; this new one that may or may not work, but that I'm enthused about; and a handful of potential minor abilities that I might choose from in order to expand things a bit.

Is this "enough"? I'm not yet sure. But I am feeling a little more confident about the potential ability-set now!

(As for what abilities I have in mind, I think that I'll leave those reveals for another time--perhaps as I implement them! )

That, then, is all for this post--stay well, and thank you for reading! ^_^

[LucierBlazquiz]

Thank you both! ^_^

I like the idea that you go to an area and it keeps scaling down, down, down as you further get into it - exposing little details you didn't think of before. I could imagine that having a pleasing psychological effect.

I'll confess that this isn't really something that I have in mind. ^^;

(Although I think that it could indeed be a neat idea in and of itself!)

Rather, the game can be thought of as having three "layers": The "bright realm"--which is a bit like what a sci-fi game might call "hyperspace"; the solar-systems; and the moons, planets, etc.

Within a given "layer", the scale is pretty much static, with the focus being primarily on horizontal exploration and combat.

That still works.

[Thaumaturge]

That still works.

Excellent, then, and thank you! ^_^

[RealScaniX]

This concept sure looks interesting. I'm looking forward to see this grow.
I guess you wanted to do something completely different after your last project?

[Thaumaturge]

This concept sure looks interesting. I'm looking forward to see this grow.

Thank you very much, on both counts! ^_^

I guess you wanted to do something completely different after your last project?

The choice of this project came from a few different things, I think. Offhand:

First, I wanted something lighter than A Door to the Mists; something that could be developed more quickly and less intensively.

Not something to be made with less passion, mind you--just something of less-massive scale and detail.

Second, I have game-concepts in a variety of genres: RPGs, immersive sims, visual novels, and so on.

Most, as you may gather, are admittedly a bit more story-heavy than is this. But conversely, my game-jam tendencies have often been towards action games: I've made a few mini action-roguelikes, and at least one first-person melee game, as I recall.

And finally, I already had this project begun--originally as a side-project--and was enthused about getting back to it.

(And there may be other matters besides.)

Having it be something different is an advantage, however: it makes for a refreshing change, I think.

[RealScaniX]

Hey, thanks for the thorough answer.
I'm the same in all points, I think. I would love to only do projects so small, that the fresh-start-energy would last up to the finishing line.
(In other words: I will only do gamejams in the future ^^)
 
That your games are story heavy isn't much of a surprise. I think that you are an excellent writer. A talent which (in my humble opinion) should find its way into all your projects somehow.

[Thaumaturge]

Hey, thanks for the thorough answer.

It's my pleasure. ^_^

I would love to only do projects so small, that the fresh-start-energy would last up to the finishing line.
(In other words: I will only do gamejams in the future ^^)

That's very fair!

For myself, I do have a desire to work on larger projects. I would love to someday have the resources to build some of the more-daunting concepts that I have!

However, I can very much see the appeal of small, quick projects, I do think!

That your games are story heavy isn't much of a surprise. I think that you are an excellent writer. A talent which (in my humble opinion) should find its way into all your projects somehow.

Aw, thank you! I really appreciate that! ^_^

I do intend that this project be relatively light on writing. Indeed, the above-described "encounter" mechanic has a distinctly limited amount of space for text, hopefully forcing me to be more brief.

That said... there will likely be at least some writing!

Aside from "encounters", I want to have some light cutscenes (such as for introducing the plot), as well as a codex of characters and enemies. (And perhaps some brief instances of "player-character thoughts", although I'm as-yet undecided on that.)

It won't likely have the breadth or scale of writing that A Door to the Mists had, but there should, hopefully, be some at least! ^_^

[Thaumaturge]

Blog post (16th of August, 2021)
Mana Changes Have Been Made

Summary: In which UI is developed; healing is implemented; inking is altered; weapons require mana; and two "metroidvania abilities" are implemented.

Greetings and salutations!

For this post's screenshot, a look at work that has been done towards the game's UI:



The past two weeks have been busy, I feel! The above-shown UI-work took perhaps the greatest share of the time, but a fair few other elements saw progress, too:

A number of the changes made in the fortnight just past were fairly minor: tweaks, fixes, and little changes. Correcting the positioning of certain doors, for example; or adding a "dying" state for enemy death-animations; and so on.

One change that's perhaps worth highlighting, if not detailing, is that I've now implemented the use of the game's healing items.

But other changes were rather more salient:

First, and as shown above, I've put in some work on the UI that's presented to the player during the main of gameplay.

In that screenshot, the current weapon is displayed on the bottom-left, with its mana-pool as a bar to the right of that; just above is a series icons displaying the weapons currently equipped. At the top-left is the current utility, and to the right of that is the player's health-bar.

Not shown is a third bar that appears vertically on the right-hand side of the view when a particular utility is activated.

One challenge in this UI-work has been my chosen theming of "brass and crystal". These can produce some quite-bold colours--colours that I fear can, if not handled carefully, clash or become distracting. I hope that I have succeeded in this challenge!

On a partially-related note, in addition to the in-level UI the "encounter" UI has seen some tweaks, making it, I think, a little more comfortable and appealing to look at:


Sticking with the visuals of the game, I've changed my approach to the "inking" of objects.

Previously, inking was handled entirely procedurally: a post-process shader compared depth-values, and inked where it found large changes in depth.

This worked well enough for hard-edged 3D objects, I do think. It worked less well, however, for soft-edged 2D art: there it tended to leave a little gap at the semi-transparent borders (where the object's depth-value was still being written), and further, it tended to poorly follow the lines of the art, I felt.

So I've changed things somewhat: now, procedural inking remains for certain objects, primarily those that are three-dimensional--but is disabled for most. In place of the procedural inking, 2D art then simply includes line-work in its image.

It's a little more work, but I feel that it looks rather better, provides greater control over the inking of the game, and allows for more freedom in my handling of depth-values!

But not all of the salient work of the fortnight just past has been visual--a few matters of gameplay have also seen progress:

For one, you may have noticed above my mention of weapons having mana-pools.

Previously, I was undecided on the matter of limiting the player's use of a given weapon. I could, of course, allow the use of weapons to be limited only by firing-rates and charge-times. However, this means that the main thing balancing high-damage weapons against low-damage ones would be firing rate. And further, it might lead to players relying on a single weapon, when I'd like to encourage them to vary the experience of combat a little more.

I considered a single mana-pool shared by all weapons--but was dissuaded by a timely video-review. (If I recall correctly.)

In the end I settled on each weapon having its own pool of mana--a weapon won't fire (or will be less effective) without sufficient mana. Conversely, mana regenerates over time.

I'm hoping that this will encourage players to switch between weapons more freely--without being burdensome!

The use of such mana-pools does also open up a gameplay opportunity--more on which presently...


Perhaps more excitingly than mana-pools, I've begun implementing the game's "metroidvania abilities"!

The first of these abilities allows the player to generate "mana crystals".

The primary purpose of these crystals is in the powering of certain mana-driven devices: plop one down on a "mana switch", and something happens (such as a door opening).

These crystals are, however, quite short-lived, disintegrating after a short delay.


They also present an opportunity: as they provide mana, they can be used to boost the mana that is consumed by the player's weapons. And further, I intend to have certain enemies attempt to take advantage of such a boost, too.

More dramatically, the crystals are incredibly fragile: a single attack, regardless of power, is enough to shatter them. And when shattered in this way they release a damaging burst of energy--perhaps both a hazard and an opportunity for players...


And the second "metroidvania ability" thus far implemented is line-of-sight teleportation.

This ability is more straightforward than the crystal one: within a given range, and within line-of-sight, the player can jump to a new location.

While perhaps useful at times in combat, this ability is primarily intended as a traversal-tool: it allows passage across hazards or through narrow gaps that might otherwise stop the player.

(I don't have any appropriate traversal areas yet, so the following demonstration just takes place in some open rooms.)


And finally, the design-doc has seen further changes and additions, including at least one new intended weapon/artefact!

That, then, is all for this post--stay well, and thank you for reading! ^_^

[RealScaniX]

The border UI looks nice, I think. I have the feeling that some of the UI elements (like dialog boxes) are a bit too colorful and might be received as "too loud" after a longer playtime. But as it's the beginning of the project, I bet they will go though lots of iterations.
Just a thought: If possible, I would try to combine the skill icon and the energy bar (like filling the icon vertically or something). It might reduce the UI a bit and each resource to just one place instead of type + bar. Just an idea. Don't know if it would be applicable or to your liking.
 
Coming up with skills reminds me of coming up with obstacles for Spaß Taxi. Xd
The "line of sight teleporter" looks interesting. Maybe he could be extended by using some crystals or mirrors to move the "teleporter beam" to a place you could not reach without?
 
This is for sure an interesting project to watch.

[Thaumaturge]

The border UI looks nice, I think.

Thank you! ^_^

I have the feeling that some of the UI elements (like dialog boxes) are a bit too colorful and might be received as "too loud" after a longer playtime. But as it's the beginning of the project, I bet they will go though lots of iterations.

I do worry a little about that. However, it's hard to tone down brass without making it look unlike brass, I fear. ^^;

(That said, I have indeed toned it down somewhat--compare this new "encounter" UI with that shown in the previous blog-post. Perhaps more could be done still!)

Just a thought: If possible, I would try to combine the skill icon and the energy bar (like filling the icon vertically or something). It might reduce the UI a bit and each resource to just one place instead of type + bar. Just an idea. Don't know if it would be applicable or to your liking.

Hmm... I'll admit that I like the clarity of a bar.

That said, there is a form of what you suggest present already in the small icons to the side (look closely at the gif that shows weapon-mana being used), and I have been thinking of extending this to the "current weapon" icon, too... (As is already the case for utilities.)

Coming up with skills reminds me of coming up with obstacles for Spaß Taxi. Xd

How did it go there?

The "line of sight teleporter" looks interesting. Maybe he could be extended by using some crystals or mirrors to move the "teleporter beam" to a place you could not reach without?

That's an interesting idea! I might keep it in mind--thank you. ^_^
 

This is for sure an interesting project to watch.

Thank you again! I much appreciate that! ^_^

[RealScaniX]

Coming up with skills reminds me of coming up with obstacles for Spaß Taxi. Xd

How did it go there?

It was quite the fun part of the project. There were simple obstacles like moving walls with buttons, magnetic fields, rockets that chase you, laser beams that activate when they see you, teleporters (not really an obstacle ^^).
By building obstacles and (in your case) skills, you get quite a handful of "building blocks" to design your levels. You then need to make sure that all of them appear in an equal amount (some maybe more or less depending on how fun they are ^^) and make sense in the level, e.g. laser beams in the prison break level.
In your case, there is the metroidvania part, so you need to show the player things he/she/it cannot reach right now. The player will need to keep those places in mind. Having played lots of those games, the player will immediately recognize those places. Usually they have some unique, very noticable element to them, like a brightly colored sphere or something like that.
Or there might be a strong wind blowing you back, which might have a certain look to it and you know that you need stronger engines or the boost to get past it.
My gamejam game had metroidvania stuff a bit. You would encounter a large box that you would need to move to get up to somewhere, then find a tool to move it. Then find the double jump, etc.
 
I think the difficult part is to build a whole world that really works with all the dynamic elements and the game progress. In case of my gamejam game (which is significantly smaller) I can proudly say that it was pure luck. :D

[Thaumaturge]

It was quite the fun part of the project. There were simple obstacles like moving walls with buttons, magnetic fields, rockets that chase you, laser beams that activate when they see you, teleporters (not really an obstacle ^^).

Ah, it sounds like you had some interesting stuff, and a fun time of it! ^_^

As to the application of such to metroidvanias, I think that agree to some degree.

I do plan on having at least some of the abilities be associated--in at least some cases--with subtle and/or varied indicators. I like the feeling of discovering a potential location for the use of an ability, of spotting something that looks like it might apply to an ability, and thus don't like to have these things always be telegraphed too much, I think.

(Although amusingly enough, the primary target-object for those mana-crystals is indeed intended to be a bright sphere or circle!)

(Also, I'll note that there's always the possibility of the game being someone's first metroidvania; I don't like to presume that all players will have previously played a given genre of game. After all, every player has to start with some given game!)

[Thaumaturge]

Blog post (30th of August, 2021)
Effect-ive Changes

Summary: In which trails are made; hit-flashes are implemented; a particle system is developed; a stone guardian is (I think) completed; work on that guardian provides a base-model; a worm is partially done; and the player-avatar acquires damage-effects.

Greetings and salutations!

This entry's screenshot shows some new effects, and an indication of an attack used by an enemy:



Aside from a miscellany of fixes, changes, and suchlike, this past fortnight focussed, broadly, on perhaps two elements: enemies and special effects:

Starting with effects, three new special effects were developed in the fortnight just past: a "trail" effect, a hit-flash, and a particle system.

Of these, the trail-effect is perhaps the most salient. In short, this effect allows me to create an animated path, such as in the wake of a moving object.

And indeed, that is its primary purpose: along with some new variables stored in the locations of the game, it gives the player-character a trail of whatever's appropriate to the area: dust, for one, and I'm hoping that it'll extend to a water-wake, too!

Here you can see it producing fine dust in the Treasure Hoard Moon:

And here it is in my testing area, with different parameters:


Perhaps the least interesting of these new effects is the hit-flash: it's simply a set of bright spiked rays, of varying directions and lengths, that appears suddenly and then dwindles and fades away. It's intended to be used specifically to convey physical damage--things like hits from material weapons, and suchlike.

And final of this set of new effects is the particle system.

Now, Panda3D actually does have a built-in particle system. However, I've long found it a little disagreeable to work with, and it has a few limitations--of which perhaps the most salient to me is the lack of an easy way to create a sudden, single burst of particles. Further, I think that I suspected that a simplified, shader-based system might perform better.

So, I created such a thing: a simple particle system that uses a shader to place and render its particles.

And indeed, it does seem to perform a little better than the built-in system (or at least did prior to some of the later changes to the system; I haven't tested it subsequently). Further, it has a mechanism for burst-emission!

Here it is producing some particles in my testing area:


Moving on to enemies, I believe that I have now completed one more enemy--or a draft thereof, at least--and nearly done so with another.

That first enemy is a stone guardian, a tireless, sleepless watcher over things deemed by someone to be important.

As a game-foe, it is essentially a melee opponent, albeit a strong one: it primarily chases down the player in order to attack with a powerful stab of its stone spear. However, if the player manages to stay at range, it has one more ability that may help it to close the gap: a dash-attack that both moves it rapidly forward and does significant damage in a broad swathe along the way.


(And as you may see above, this enemy uses all of the above-mentioned effects: a double trail-effect for its dash; hit-flashes on landing hits; and particles on taking damage or being destroyed.)

The stone guardian's particle effects have been tweaked a little since the above gif was made--here then is a still of their revised appearances:


And as the stone guardian is the first humanoid character thus far developed for the game, it also provided a base-model that I intend to use for other humanoid characters.

And the second enemy is a creature endemic to the Treasure Hoard Moon specifically: a worm that eats the gold stored there. And should a threat approach--such as the player--it rears up and spits globules of damaging aqua regia at the interloper.



And finally, the player now has some indicators of damage being taken and of the state of being at low health. The former is a particle effect--one that I'm not yet quite happy with. The latter, on the other hand, uses the extant fire effect to create a ring of crimson flames around the player's vessel.



And that, then, is all for this post--stay well, and thank you for reading! ^_^

[RealScaniX]

I really like the trails. I think they improve the feeling of movement a lot.
When you said "flash", I expected the whole screen to flash in a color. I think some games are doing that, too.
Showing a small highlight at the hit position is nice. It solves the problem in some fights, where the player wonders where the hell he got hit. ^^
The red particle effect when losing health is certainly doing its job. I'm just wondering if it resembles blood a bit too much. You are a space ship if I understand it right, aren't you?

[Thaumaturge]

I really like the trails. I think they improve the feeling of movement a lot.

Thank you very much! And I'm glad that they do so work! ^_^

When you said "flash", I expected the whole screen to flash in a color. I think some games are doing that, too.

Hah, I can see one thinking that, indeed! And in all fairness, I may have used the wrong word there--looking it up quickly, it seems that perhaps the term "hit spark" is more accurate.

Showing a small highlight at the hit position is nice. It solves the problem in some fights, where the player wonders where the hell he got hit. ^^

The red particle effect when losing health is certainly doing its job. I'm just wondering if it resembles blood a bit too much. You are a space ship if I understand it right, aren't you?

Perhaps, indeed. (And indeed, you are a space ship--or more accurately, a spirit piloting a brass-and-crystal flying-vessel.)

I have replaced the particle-image now, as it happens--it is still red, if more brightly so, and has a different shape.

The trick here is that: (A) Red tends to be associated with health, (B) I want the "damage particle" to connect to the loss of health, and (C) I want the damage particle to be distinctly different from any of the player's attacks--I don't want it to resemble an attack going off for no reason. And the player's attacks are quite varied in their colours and behaviours.