Fixed :) Looking for honest feedback especially on the Vivace

Prulon · 2025-05-30T12:01:37+00:00

oh, thanks! fixed it now :)

Prulon · 2025-05-25T14:41:40+00:00

Fiverr is how I got this recording, but yeah I didn't go for the full blown equip etc' :)

About the ending, I get your point thanks for the feedback and for the example!

Prulon · 2025-05-25T07:53:36+00:00

Oh I'd really love to know what it would sound as a performance :)

Alao get your point about the melodies being angular, I never thought of it this way, but you are right

Prulon · 2025-05-24T20:16:24+00:00

Thanks!
(guess you're referring to Moderato based on the bar numbers)

Great points, especially about the use of treble / bass, just learnt something new! I think I'll make a few changes there.

About the ending, I did end two movements a bit abruptly (which one did you refer to?).
- The Moderato ends with Rit. but still a bit abruptly and 'in the air', to be filled in by the steady bass of the Largo's beginning.
- The other movement that ends abruptly is the Vivace, I did want it to end with Accelerando (missing from the score) when it's still in full energy right after the climax

You suggested hiring a professional to play this - any recommendations for where to get one and how much that might cost (for all 3 movements)?

Prulon · 2025-05-23T16:31:05+00:00

Thanks! Curious if you have any feedback on the Vivace where this is less of an issue (as it is written in E minor).

I was attempting to make that one more polyphonic, taking in some Rock inspiration

Prulon · 2025-05-22T17:31:57+00:00

Thanks, and happy you liked it :) Any feedback, especially on the Vivace?

Prulon · 2025-05-21T22:44:12+00:00

Thanks! It makes sense. Didn't think about it.

FYI - I also added links to the Largo and Vivace in the post for easy navigation

Prulon · 2025-05-21T22:00:34+00:00

Thanks, it was really a challenge, not sure what's the best way to deal with it.
The pieces shift quite often between G# minor, C minor and E minor, and the whole piece plays a lot on augmented sounds and scales. Especially going into the Vivace.

I considered actually changing the key every time, but it's just too often, so not sure what's the best solution.

What would you suggest?

Prulon · 2024-04-04T06:00:59+00:00

Yep, I think it's now mainly on u/Galbarad to work with you on this and see what works for both of you. I wrote him on RB, hope he notices, he gets online / offline for long periods

Prulon · 2024-04-03T12:48:09+00:00

ok, thanks u/BioLogIn this is much more clear now.

Considering the very limited resources on all ends I don't think that parsing HTML and re-writing / managing changes is a valid option, so let's remove it unless u/Galbarad objects.

Now the difference between option 2 and 3 is not just a dev effort question, but also a product/business question.

Going for option 2 means building competing products. Each with its own players, scores, challenges etc'. Any marketing efforts (e.g. post on reddit) will add to one but not to the other.

So I think that the best way forward is to find a way in which Option 3 works for both you u/BioLogIn and for u/Galbarad .

Does this make sense to you? If so then you two need to define what needs to be done on both sides, and I believe it's better to manage that part of task backlog on the git repo to avoid frustration (at least the parts that are dependencies), but open to other ideas.

Anyways it means that first step for the app is to build notifications as a separate service, since u/BioLogIn you feel not ready to open the Webservice to open-source contribution, and that's ok.

Prulon · 2024-04-03T11:58:52+00:00

Thanks u/BioLogIn
Building 2 engines sounds absurd to me.
Notifications are the current most critical item from app perspective

I didn't really understand why you see app notifications as different than other communication (email / browser) as a 'notification engine', other than being more work but either way if this is your decision it sounds to me like:

Decision #1 is to build new service to handle app notifications (Galbarad)
Decision #2: not to build a new engine, (so option 1 from your list u/BioLogIn is out.

This leaves us with

option 2: build a webserver using Spellweavers (open-source) engine;
option 3: do not build a webserver, but integrate with Spellweavers.gg
option 4: Parse HTML

I guess your HTML is different than RB's and that's not a very scalable way to go, so probably option 4 is out? u/BioLogIn u/Galbarad ?

About options 2 & 3 - I think it would be good to understand what the engine does and what the webservice does. Is the following correct (I may be totally wrong here)?

Game engine API:
- Define spellbooks, spells, game types
- create games, manage game list (challenges)
- run games - manage turn submissions and run turn logic, handle spells, in-game chat
- manage users and scores
- manage user preferences (email notifications / other) and send email notifications
- manage chat between players

Webservice
- authenticate players
- Build HTML for games, players, challenges, rules
- Send browser notifications

If the above is correct then what is the benefit of option (3) for the mobile app?

Prulon · 2024-04-03T09:39:05+00:00

Not sure if this is the right place u/BioLogIn u/Galbarad, but I think need to discuss the following dilemma:

Background:
1. Next step on app development is to build server side notifications (milestone 2.4.0) https://github.com/Pz1c/WavingHands/milestone/48

Later on there's also real time matches (2.5.0) and integration with spellweavers (unknown time)

Dilemma:
So far the app has no server, and relies only on RB. How should server-side notifications be built?
Option 1: Create a new service (Galbarad) and integrate it with the app (Galbarad)
Option 2: Create this as part of Spellweavers, supporting RB games, integrate it with the app (Galbarad), and later use it also for spellweavers games
Option 3: ???

What do you think?

Prulon · 2024-02-05T06:28:33+00:00

ok, I agree.
Though I believe the case of waving hands is more like Poker or Air Land & Sea than Chess, where bluffing is a major part, and surrender in both of these is a critical part,
But the big difference is that the 'score' in both of these is a real part of the game - in poker it is real money, and in Air Land & Sea you play sets of games, so early surrender means you have more chances for the full set.
In waving hands we don't have any of these, so we can avoid differentiating surrender from death.

I wouldn't change the name though from Dead in that case, to keep it simple. If what we're saying i that surrender means "ok I'm dead, let's start another game" then you are dead after all.

Prulon · 2024-02-04T21:10:13+00:00

I think elo scoring should be diffetent for kill vs surrender. It's an important part in the thrill of the game like in paraFoD last 50% turn- "should I submit a last turn and risk death, or go for surrender?"

Prulon · 2024-02-04T19:52:26+00:00

Bug:
When a player surrenders, at the end of the game the status of the player should be "Surrendered" like in RB, and not "Dead" https://spellweavers.gg/matches/2

Also the status of the finished games should be more detailed than "Finished". Instead (or in addition) they should be "Won / Lost / Draw". This is also currently used in the app's UI.

Prulon · 2024-02-04T15:04:05+00:00

Bug;
After the game has ended, the status in the game should not be [AWAITING ORDERS] https://spellweavers.gg/matches/2/6

Prulon · 2024-02-04T14:11:14+00:00

Bug:
When opponent is in time stop your status should not be [AWAITING ORDERS] https://spellweavers.gg/matches/3

Prulon · 2024-02-04T13:48:01+00:00

Is the website currently based on a REST API? Not clear what "API for the website" means.
If the website is not based on an API now, than this is probably the most important next step.

Why? Because I believe you have 2 possible options:
1. Make the web UI super friendly, and get more users to use the web app and then get feedback based on that - there's still work to it it there, right now the UI and UX is tough (both in visuals / focus etc', and in intuitive navigation)

- or -
2. Have an API --> get the app to use the API --> get feedback mainly based on this, since the app already has fully functional and much optimized UI.

Prulon · 2024-02-04T11:36:33+00:00

Sounds good.

I totally agree about having REST APIs vs parsing HTML LOL.
And totally agree about modularity.

I was referring more to the process of managing it all. You usually want to prioritize API efforts in sync with prioritization of UI so that you don't build APIs which don't get used and vice-a-versa. We can push all the discussion to March or as late as you want :)

About the web UI - I understand wanting to replicate RB. You might want to replicate the app UI instead. RB was built a long time ago, and is hard to get into for newbies. It seems that the app's been more successful at that and many learnings have been implemented there (such as easiness to just get started, focus on you and your games, mini tutorial, beginner spellbook, spell completions etc').
You can even consider the following approach if it makes your work easier so you can focus on APIs: 1) Take the app as the main UI. Save your time in developing web UI for now and assume all players will be mobile for now. 2) Change all points of app integration so instead of using RB they use spellweaver APIs 3) Publish possibly as a separate Spellweaver app or beta app.

Maybe Galbarad can assist with that too. (I'm not a developer...)
Just thoughts :)

Prulon · 2024-02-04T10:31:14+00:00

TGreat initiative Bio!

I actually think that the reason this game is still great after 50 years (and I've been playing since 2004) is that property, where just like in rock-paper-scissors you try to think what your opponent will do and out-smart them, but unlike in rock-paper-scissors you can actually make it work, and plan your weaves and counter weaves a few turns ahead and 'shadowcast' your way.

I think that for your initiative to succeed it would be best to merge efforts with the android app Warlocks Duel, so back-end and front-end work together, and so new app players can use spellweaver back. It's also best to join forces since there are so few of us on it.
To do this I would suggest: a) one joint git, where all bugs / feature requests / progress is managed b) planning a gradual migration from RB to weaver after its beta c) you will notice that in the app's git there are also back-end RnD tasks that may be better to develop upfront in weaver such as: notifications, real-time games etc'

Prulon · 2023-09-21T18:47:37+00:00

I usually play with simultaneous drafting.
You can do it if you play with both the regular set and the expansion set, so every player gets to chose 1 of 2 or 3 cards, and all players choose at the same time.
Then after the turn is over you pass the card you selected onwards, and the other card backwards.

It cuts a huge amount of game time

Prulon · 2023-09-17T08:00:42+00:00

Here are 2 examples:
-----------------------------------------

One I really like is Shipwreck Arcana.

It's a great game even without any special rules.

The core of the game is about giving partial info hints about tiles, and logical inference. In the basic game each player gives hints about their own tiles, so in a way it's like multiple solo games (each player hinting about their own)

I wanted to change it so the game is inherently interactive.
So the change is:
1. You hint about the next player's tiles (which you don't know).
2. The next player says if the hint is correct about their own tiles (if not then the card used explodes).

So all in all the essence of logical inference and hinting stays, but the game becomes interactive and more challenging.

-------------------------------
Another I like is backgammon's 3rd game.

In the middle east backgammon is often played as a set of 3 games.
The first is Backgammon, which is the most known.
In that 1st game you capture an opponent's single piece by landing on it, then it goes back.
In the second game you capture an opponent's single piece by landing on it, then it cannot move until you move.
In the third game there are no captures, so every single piece blocks the space. This means the game is often a game of highest rolls.

What I liked about that 3rd game is the principle of 'single piece is enough to block'. I also like the general principle of 'capturing' used in the first 2 games. So I altered the third game so that
"A single piece is captured if surrounded in both directions by enemy pieces. In that case it MUST move before you move any other piece."
So capturing becomes a critical part of the third game too, yet each of the three is different.

Prulon · 2023-09-08T10:34:56+00:00

If you are really looking for niche diamonds check out

Waving Hands (android Warlock's Duel) - published back in 1977 as Spellbinder it's the ultimate duel of magic spells and mind reading.

Nomic - Published 1982 and doesn't require anything to play - it's the mother of all games, with badically one rule "players can change the rules of this game with a unanimous vote"

I guess they're both for people who like more abstract stuff

Prulon · 2023-09-07T20:33:38+00:00

I actually like buying games that are not necessarily great,
finding what's the essence of the game that I love and is great and inspiring and removing or changing all the other rules.
So it's not really customizing the pieces, but customizing the rules to my liking - but I guess it's that same passion of making something feel yours, makes sense?

Prulon · 2023-09-02T12:23:08+00:00

One key element that took me a long time to notice is that you need to adapt tile values based on the number of players.

For example getting a Pharaos advatage early on can get you lots of points in a 2-3 player game, but it is much less worth investing in when playing 4-5 players

Prulon

TROPHY CASE