itch.io

Sorry for the late response - they are additional arguments after the IP:P, like "server.exe 123.123.123.123:N 42 abcde"

I mentioned this during the stream too but after a while I noticed the noise had stopped. Still no idea what the issue is

Opening the game makes my audio shitty, even for other programs and even if I mute the game. Running in WINE

Don't know if it's been done already but MIT license does require at least including the license somewhere.

cel-shading*

Also I accidentally pressed X during a story mode scene and lost my progress

wizard is very weak, you should halve his barrier recovery and boost his meter gain when in the back

By the way I figured out the workaround for the unity games that have this problem, you can set WINE to emulate a virtual desktop, which fixes some focus issues or something. I can pretend I'm playing windowed if I set the game to fullscreen since then it just takes up the window for the virtual desktop.

Found this out while trying to pirate rimworld, then I pulled an all-nighter+ and forgot about my stream slot

another one, this one spontaneously stops working when it passes over the gaps in the ceiling (set to detect machining)

Having another issue that probably has to do with update order, the on pulse at the port gets dropped (when the actuator extends after retracting) so it doesn't detect the negative edge. It's connected for the delay of two transistors so I feel like it should go through.

Does signal drop depend on the blocks it passes through? This one seems to be dying a lot earlier than the latch one:

EDIT: Thought it was a signal drop issue since using a toggler next to the block detector did what I expected, but after messing around a bit it might be an update issue since it would work sometimes and break if I moved it. This is more annoying to work around because updating blocks near the block detector didn't help. I'm not sure what fixes it since I tried placing blocks around the ports but that didn't help either.

Here's also a different case I saw where dropping something on the block detector didn't update the signal it was outputting:

I also wasn't able to figure out how to make this one update.

EDIT2: If I drop the block sideways then one wire is activated

EDIT3: If it sees 3 adjacent ones then it's enough to cross the gap and power everything

I guess this might be some feature for detecting the number of blocks, for now I'm working around it by putting two transistors behind it

Not that I can remember, but I will let you know if I see anything like that

Thanks, I didn't realize the latch doesn't refresh the signal. What about situations like this (the block detector is set to any)?

I had it against a wall and used right click to move it away, then the wires coming out of the block detector became stuck. If I let a block fall in front of it it would update and the wires would be off after the block passed. Also the top wire seemed to update to off for a moment while the block fell a little bit but wasn't in front of the detector yet.

The signal doesn't seem to be propagating from the latch, am I doing something wrong?

I wasn't able to reproduce it when I tried, but I'll note it down as something to look into. Thanks for the report

There's an issue when I run under WINE on Linux that the UI becomes unresponsive if you switch window focus to something else. Don't know what causes it or if it affects other people, but I remember I had the same problem with Oxygen Not Included (when running via WINE and not natively)

I think mainly you speed up when descending and slow down if you turn too hard, but the max speed is set a little low currently (relative to acceleration) so it obscures things a bit. Dunno about the UI stuff though, I'm freeing the main menu scene when I switch (except for when I show the manual page) so I'm not sure how that would happen. What button were you able to press?

I hadn't thought about paring away the dodging aspect so I'll need to think a bit more on that one. It's mainly there to add some spatial constraints so that it matters that you have to draw the glyphs instead of some other casting method, but it's true that it doesn't really mesh well in its current state. I still want to make it work, but I'll consider leaving it out if I can't.

Part of the reason I submit is the streaming, so I'm looking forward to seeing some live feedback there. I guess I should look for people who I can watch play it more regularly.

Thanks for trying out the mac version, sorry to hear that it didn't seem to work properly. I feel like it could still just be an issue with the game since didn't find anything searching for related bugs in Godot, but right now I can't really verify it. Going forward I will have to get some way to test the OSX builds to support it.

I'm not sure if I made it clear enough in the game, but you can draw the symbols at any size and they will have basically the same effect (there are controls to change the guide size, but when it gets too small it's easier to do it without). Might still be good to raise the ceiling though, since defending the base I think accomplishes the ceiling's original purpose of keeping the player from running too far from the enemies.

I agree that I need some quicker attacks to clean up smaller groups of enemies. I was thinking to add a weak non-spell gun to the plane, but haven't thought through whether it would be better to have a quicker spell instead (or maybe have the power of glyphs scale with size in some way). Don't know if you tried, but currently it's possible to cast glyphs faster by drawing it smaller (there are controls for adjusting the size of the guide, though when it gets too small it's easier to not use the guide since it's easier to adjust for mistakes).

What did you try for the time slow? In the tutorial I forgot to mention that you need to hold the input, so maybe that was the issue. Dodging is currently kind of hard without time slow, other than very coarse dodging to avoid most of the shots. Releasing your drifts when you're about to be hit can help by making the enemies overshoot.

The other points are fairly straightforward so I don't have much to comment on them. Thanks for the detailed feedback!

I played for a bit and got as far as automating a few things (metal / wafer production, dismantling large chunks of dirt, mineshaft driller). Overall the base mechanics feel very solid, and I was surprised the thoroughness of some of the interactions (like when my unanchored combiner pushed itself up by ejecting its products). It feel like it has the depth to encourage 

My main pain points were that the blocks in the guide menu were rendered too small to recognize, and that I was confused during the initial hints since I couldn't figure out the build/place controls until I looked at the options. Other than that, maybe it would help to define some high-level objectives for the player to help direct them into learning what they can do with the game, since I find that kind of thing helps me when I'm getting into Minecraft automation mods (I haven't played many automation games outside of that).

Just pushed an update to try to handle some of these issues:

- Acceleration is controlled by mouse now

- Made the storm glyph recognition threshold a little bit easier

On the movement points

1. I just pushed an update like AutomonDev suggested where throttle is controlled by how far your mouse is from the ship; let me know how it feels if you get the chance to try it.

2. Having a continuous trail sounds like a good idea, if I can automate figuring out the start and end of a shape. I don't know how to do that yet so it's currently an implementation limitation. I'll note to look into it when I'm trying to improve the glyph recognition in general

My motivation was literally to find a game these mechanics work in, so you're right about that. I think what's really needed for it to work is some deeper interplay between how you try to draw symbols and other parts of the game like dodging, enemy attack behaviors, etc., but the current demo doesn't really achieve this. I'm not really convinced that drawing this way has to be clumsy though, since I was able to get used to it after a while - maybe it needs a better onboarding process from when people start out to where they feel comfortable with it.

Thanks for the feedback - I really like the suggestion for mouse-based throttling since I wasn't sure how to give more fine-grained speed control with the current control scheme. It didn't occur to me to have moving as the default either.

The shape thing does need some work, I've been trying to tweak it but it gets kind of biased in what is considered a "good" shape and I had trouble making it more lenient without it accepting shapes too readily. Short-term I can probably adjust the thresholds for the more complex symbols, but I think I will need to look more into the handwriting recognition literature. I've also experienced the pain points of losing momentum, so I will have to figure something out there too.

Time shifting requires that you have some time meter (indicated by the spinning shell) which you get by destroying enemies, and it gets stronger the more you have stored. As a visual indicator there should be kind of a fog that appears when you use it that scales with the strength of the slowing.

Hopefully I can address some points before the submission period ends

I enjoy

There's two kinds of networking I will eventually need:

The first is the communication between the players' game clients and the game server(s) actually running the game simulation. Firebase does not provide anything particularly useful for realtime messaging, which is needed in Shmup 99 because the players have continuous interaction with each other. Firebase might be suitable for games that don't require realtime communication, but I don't know for sure and can't give any Firebase advice, as I haven't used it. For game communication I currently use yojimbo, which I linked earlier. I'm satisfied with how that is set up.

The other kind of networking I will need is between game servers or players and centralized servers for authentication, stats tracking, etc.. Firebase might be more useful here than game communication, but I won't use it because it's proprietary. I have not started working on this portion of the game, but the central servers will probably expose a web API and use some SQL-based database system. There are lots of existing libraries/frameworks for that kind of thing and I have not made any concrete choice on what I will use. Firebase provides a database system and push notifications, which may be useful if you decide to use Firebase for your persistence stuff.

Thanks. For networking I'm using a library called yojimbo (https://github.com/networkprotocol/yojimbo) which has a similar use case to ENet but also provides authentication. My netcode logic is a shared deterministic simulation, mainly input-delay based but with a rollback-like hack so that there's no delay for the local player's screen. However I avoid applying rollback across the whole game state (so I don't have to save/restore it every frame). Because the interactions between players are very delayed, and I avoid input delay for the local player, the game can tolerate large network latency.

It's down again, I'll try later and see if firebase is back up.

All the cases of bleed removal was on the enemy being attacked, so I guess that's working as expected. When I was trying self-care though I did it when Jean had high enough OT built up that I should be able to see the change (like 12 or so). I didn't choose actions very efficiently so it was common to get some OT buildup.

EDIT: Also I forgot to mention, I think Kamui and Avicenna's headshots have different OT gates and effects, which was unexpected for me. Another thing is that OT is consumed even if I use a skill when below the OT gate (the manual says it is subtracted if you use it when above the gate)

I couldn't register, the game would just never finish registration. I tried to sign up with the (fake) email 2hu@4u.com and the username 2hu4u. The same thing happens if I tried to log in.

Thanks. I realize that I was being a little bit passive aggressive with the last sentence (and that it's a bit self-serving to apologize only after you did the thing).

The keyboard worked this time, though there was still no mouse (intended?). I like that the layout is efficient, even though I didn't really make that much use of q/w/e/r. Having keyboard controls in non-combat menus might improve the flow further since I won't have to move my hands to the mouse. Some kind of skip input like common in VNs would have been useful too, since my main computer crashed during the last prologue battle so I finished it (and the new storyline) on my laptop and I had to mash space to get through the dialogue. My main annoyance UI-wise was that the character portraits when taking combat actions would cover up the action bar and status effects of enemies on the right side of the screen.

I've played RPGs a little bit and found the combat system easy to get used to. Since I couldn't get hard mode to work (see bugs section), I found it easy to keep everyone buffed / the enemy debuffed and found combat a little bit boring. I imagine that with hard mode working it would be more challenging, and the fights would be over sooner anyway since I would have to learn to play faster. On the note of balance, I didn't seem to need to mess with polarity very much to win the prologue encounters, other than keeping it near 0 to avoid surprises. Increasing overall difficulty might make it more important, but it could also be cool to have some encounters designed specifically to exercise polarity manipulation (this would also teach the player to use it effectively in future encounters). In the final chapter of the prologue the crew became less useful in the middle of battle because everyone was buffed, I didn't need heals very often, and the crew has low attack power. Even when I did need heals, I ended up with an OT surplus since Nostradamus was not needed often. Also, I noticed some attacks delivered "high" damage, and others delivered "large" damage. I wasn't sure what the difference was.

I like horny designs so that's a plus.

Bugs I noticed:

• First time I went to the settings I got a black screen and had to restart the game. Didn't happen again so don't know what caused it.
• I still had the issue where the settings page resolution would be different from the initial resolution
• I got a game over during the prologue and my mouse didn't come back like it usually does after an encounter.
• You can change polarity even when in menus, regardless of whether hard mode is on. You could cheese the game by keeping attack high and then raising defense only before the enemy attacks, and it would make the polarity effects of moves redundant.
• Hard mode setting didn't work (good thing for me because I spent a lot of time in the menus). The setting toggles but the meters still pause in menus.
• Hard mode setting toggles either when you enter settings from new storyline base
• At some point during the first demo battle I couldn't see Sparta's status effects anymore. They didn't actually go away and will display again sometimes when here status effects change.
• When selecting a skill targeting enemies, the menu sound effect would interrupt the BGM. The sound is also louder than usual so maybe there are multiple instances of the sound playing. I only noticed it in the Alcor battle after some time had passed, and it seems like the sound was getting louder over time.
• Sometimes bleed would be removed from enemies after attacks, not sure if this is because some enemies have faster recovery or something else.
• Impenetrable would reduce polarity but wouldn't raise defense.
• At the end of the prologue you can press space and the last line of dialogue would reappear and flash
• In the bestiary, if your mouse is hovering over an item in the enemy list, scrolling with the wheel doesn't work (at least on touchpad).
• Self-care didn't appear to distribute OT, at least not instantly
• Only left shift works for cancel (Though with the key layout left shift is nicer anyway)
• Dialogue doesn't appear after gaining 100% in the new storyline (but I guess that's probably just because there's no dialogue written for that part)
• The same flickering status bug that was already reported

Not much to comment on but I thought of a couple things:

• Colliding diagonally with the enemies feels really bad because it looks like they're not touching. It would be more intuitive to avoid them if you give the player and enemies circle collision shapes.
• It's difficult to enter the door going between the two lower rooms. Giving the player a circular collision shape would help here too.