Misions in Sarmatia Mundi App

In the last post I described our communication system (czat i prywatne wiadomości). After publishing it, I had a very interesting exchange with Hive account@gtg, as a result of which I added a warning to the messages: if you lose your memo key, a thief will gain access to the entire message history. Therefore, this system should only be used for non-sensitive communication (the app is meant to be a kind of game, so in principle, no one should even think of sending sensitive messages there anyway). I also added online activity indicators so users know who is currently online. In the plans: adding a blacklist to the inbox and other convenience features.

Today, however, I’ll show you the next important stage in the development of our app — the Missions module.

Types of Missions

Missions can be extremely varied, and I’m sure I haven’t foreseen all the possibilities (there will be room for app updates :)). Still, I tried to include the options that seemed most important to me.

First and foremost — the reward issue. The app currently supports 3 types of rewards:

• Barter: A descriptive reward with no payment guarantee, but a simple rating system for the mission issuer is provided. The account that took on the mission, completed it, and received acceptance of completion will be able to give a simple note: whether the issuer fulfilled the payment or not.
• Tokens: Both native ones (HIVE, HBD) and those from Hive Engine. Payment is guaranteed through a mechanism similar to a smart-contract escrow (a trusted intermediary — the app’s account).
• Merit Points: Points that will be used to create rankings and more within the game layer of the app. Only admins can award these.

What else can we set?

• How many people can take on a given mission. In the case of a token reward, this must be a finite number; in the case of barter, it can be unlimited. We can also add exclusions so that selected people cannot take on the mission.
• We can set the duration of the announcement. This is useful because sometimes completing a mission after a certain date no longer makes sense…
• We also have to set the time within which we declare we will review the correct completion of the mission.
• The final element is an optional pin on the map. The map will be an important part of our app, so we can, for example, commission an article about a battle that took place in a specific location. Such a mission will be visible both on the list and on the map.

Adding options looks like this:

Process

I consider the proper process to be the most important thing in this kind of system, so that it provides maximum fairness and transparency. That’s why completing a mission in our app can be a multi-stage process.

The first step is, of course, creating the mission. Any logged-in user can do this, although the admin has a few extra options. The mission itself is a post on the blockchain. All additional mission attributes are stored in the post’s json_metadata. After publication, the mission appears on the list:

The next step is, naturally, accepting the mission by a user. If the mission was intended for single use or the last available slot has been taken, it becomes locked for other users after acceptance. After completing the mission, you go into it in the app, click the “Report Completion” button, then enter a descriptive justification and/or a link. And you wait for the issuer’s approval:

At this point, there are two paths. Either the issuer accepts it — and then the token reward is automatically sent to the person who completed the mission (or the issuer makes the barter payment). Or the work is rejected (optionally with a justification).

However, that’s not the end, because the person who completed the mission can either accept the “verdict” or appeal it. In the appeal, they can also add a justification.

The appeal is resolved by an admin, who can either side with the person who completed the mission (in which case the automatic payout occurs, or the issuer is honor-bound to do what they committed to — if they don’t, they receive a negative rating) or side with the issuer. And that concludes the mission process.

Every subsequent step is recorded in the comments under the mission post, so the entire course is fully transparent.

Adding a Mission vs. the Hive Feed

As mentioned, a mission is a post, so it also has the standard text editor, title, tags, and beneficiaries. Due to the nature of this post, we added an automatic system that sets the Hive account@null account as the default beneficiary (though it can be removed). Sometimes the mission itself can be valuable content worthy of upvotes and a Hive community reward. However, we added one more feature — internal tags. This solution allows good filtering on the mission list on one hand, while on the other it prevents cluttering the actual post tags if the mission doesn’t need wider publication or if it would be closer to spam than valuable content.

Statistics

Statistics are a nice thing — I like them. That’s why we added a tab on the user’s account where they can check the history of both missions they’ve taken on and those they’ve commissioned. When you open them, you’ll see the full history of the mission process.

The history is saved to an off-chain database so we don’t have to query the blockchain every single time.

And that’s all for today. I hope you like the mission system — feel free to share your thoughts in the comments :)

---

Moduł Misji w Sarmatiamundi

W ostatnim poście opisałem nasz system komunikacji (czat i prywatne wiadomości). Po publikacji odbyłem bardzo ciekawą wymianę zdań z Hive account@gtg w efekcie czego dodałem ostrzeżenie przy wiadomościach iż w wypadku utraty klucza memo, złodziej będzie miał dostęp do całej historii wiadomości, więc można używać tego systemu tylko do niewrażliwej komunikacji (aplikacja ma być swego rodzaju grą, więc co do zasady raczej nikt nawet nie będzie miał pomysłu by przesyłać tam wiadomości wrażliwych). Dodałem także oznaczenia o aktywności, by użytkownicy wiedzieli kto jest on-line. W planie dodanie do skrzynki blacklisty i inne ułatwienia.

Dziś natomiast pokażę kolejny ważny etap tworzenia naszej aplikacji, a więc moduł Misji.

Rodzaje misji

Misje mogą być różne, najróżniejsze i z pewnością masy możliwości nie przewidziałem (będzie miejsce na aktualizacje aplikacji :)) ale postarałem się dodać opcje które wydały mi się najważniejsze.
Przede wszystkim kwestia nagroda. Aplikacja dopuszcza obecnie 3 rodzaje nagrody:

• Barter: nagroda w formie opisowej, brak gwarancji wypłaty, ale przewidziany jest prosty system oceny zlecającego misję (konto które się podjęło misji, wykonało, dostało akcept wykonania będzie mogło dać prostą informację: zlecający wywiązał się lub nie wywiązał z wypłąty)
• Tokeny: zarówno natywne (HIVE, HBD), jak i te z Hive Engine. Gwarancja realizacji zapłaty poprzez mechanizm jak w smart-contract escrow (zaufany pośrednik - konto aplikacji)
• Punkty Zasług: Punkty, które będą służyć do tworzenia rankingu i nie tylko w warstwie grywalnej aplikacji, te mogą przyznawać tylko admini.

A co jeszcze możemy ustawić?

• ile osób może się podjąć danej misji, w przypadku nagrody w formie tokenowej musi to być skończona ilość, w przypadku barteru może być nieskończona. Możemy też dodać wykluczenia, tak aby wybrane przez nas osoby nie mogły podjąć się misji.
• możemy również ustawić czas trwania ogłoszenia. To przydatne, bo czasami wykonanie misji po jakiejś dacie przestaje mieć sens...
• musimy także ustawić czas, w jakim deklarujemy rozpatrzenie prawidłowego wykonania misji.
• ostatnim wreszcie elementem jest opcjonalna pinezka. Mapa będzie ważnym elementem naszej aplikacji, dlatego możemy zlecić np napisanie artykułu o bitwie która odbyła się w jakimś konkretnym miejscu. Taka misja będzie widoczna zarówno na liście jak i na mapie.

Dodawanie opcji wygląda tak:

Proces

Za najważniejsze w tego typu systemie uważam właściwy proces tak aby zapewniał maksimum uczciwości i przejrzystości. Dlatego też przebieg wypełniania misji w naszej aplikacji może być wieloetapowy.
Pierwszym krokiem jest oczywiście ustanowienie misji. Może to zrobić każdy zalogowany użytkownik chociaż admin ma trochę dodatkowych opcji. Sama misja jest postem na blokchainie. Wszystkie dodatkowe atrybuty misji są w json_metadata postu. Po publikacji misja pojawia się na liście:

Kolejnym krokiem, jest oczywiście przyjęcie misji przez użytkownika. Jeśli misja była przeznaczona do jednorazowego użycia, lub zostało ostatnie użycie, po podjęciu misji jest ona zablokowana dla innych użytkowników. Po wykonaniu misji, wchodzimy w nią w aplikacji klikamy guziczek zgłoś wykonanie i następnie wpisujemy uzasadnienie opisowe i/lub link. I czekamy na akceptacje zlecającego:

I teraz mamy dwie ścieżki. Albo zlecający akceptuje i wtedy nagroda tokenowa automatycznie idzie do wykonującego misję, lub zlecający wykonuje inną zapłate (barterową). Albo następuje odrzucenie pracy (opcjonalnie z uzasadnieniem.

To jednak nie koniec, bo wykonujący może albo przyjąć "werdykt" albo się odwołać. Przy odwołaniu również może dodać uzasadnienie.
Rozstrzygającym odwołanie jest admin i może on albo przyznać rację wykonującemu (i wtedy następuje wypłata automatyczna, lub zleceniodawca jest zobowiązany honorem aby zrobić to do czego się zobowiązał - jeśli nie zrobi dostanie negatywną ocenę) albo zlecającemu. I na tym kończy się proces przebiegu misji.
Każdy kolejny krok jest zapisywany w komentarzach do postu-misji, więc przebieg jest w pełni transparentny.

Dodawanie misji, a feed hive

Misja jak było to wspomniane jest postem, więc ma też standardowy edytor tekstu, tytuł, tagi, beneficjenci. Ze względu na charakter tego postu dodaliśmy automat ustanawiający konto Hive account@null jako domyślny beneficjent (ale można go usunąć). Czasem misja sama w sobie może być wartościową treścią godną upvotów i nagrody społeczności hive. Dodaliśmy jednak jeszcze jeden dodatek - tagi wewnętrzne. Takie rozwiązanie ma z jednej strony umożliwić dobre filtrowanie na liście misji, a z drugiej nie zaśmiecać tagów z faktycznymi postami, jeśli misja nie wymaga by ją gdzieś szerzej publikować, czy miałaby charakter bliższy spamowi niż wartościowej treści.

Statystyki

Statystyki to fajna rzecz, ja ją lubię. Dlatego dodaliśmy na koncie użytkownika zakładke gdzie może sprawdzić historię zarówno podjętych misji jak i zleconych, a wchodząc w nie będzie widział historię procesu misji.

Historia, zapisuje się do bazy of-chain, żeby nie trzeba było za każdym razem odpytywać blokchainu.
No i to tyle na dziś, mam nadzieję, że system misji się Wam podoba, podzielcie się refleksjami w komentarzu :)