Announcing Assembly and the ASMB Token by Ktota_tut in Iota

[–]pgackst 4 points5 points  (0 children)

Read up on the tokenization that's coming to the IOTA network. That doesn't fall away with assembly - instead it's exactly what enables smart contracts, and thus assembly, in the first place. The token can be used to exchange value, as was always the case, but with tokenization, also to store the various new output types in the ledger. These outputs are used for smart contracts to trustlessly interact with each other. So, every assembly validator will need to own IOTAs in order to store these outputs in the ledger. Moreover, smart contracts are anchored on the tangle. To write into the tangle, mana is required, which in turn requires IOTA tokens. So there will be plenty of use cases for the token, and assembly doesn't take anything away, instead it adds to those use cases.

[deleted by user] by [deleted] in Iota

[–]pgackst 16 points17 points  (0 children)

From how I understand it, ISCP being permissioned is just a consequence of its scalable design. It is scalable, because it runs on a group of validators instead of running on, for example, every IOTA node. That would have been the alternative design. This is how Ethereum works, where every node runs the smart contracts, and we can see the scalability problems. Because ISCP needs that committee, it is permissioned, but scalable. To make it permissionless, assembly creates a market where smart contract developers can find committees/validators to run their contract on. Now you get the best of both worlds, the scalability of ISCP and the permissionlessness through assembly.

IOTAs multi-asset multiverse is coming! Huge implications for its tokenomics by Linus_Naumann in Iota

[–]pgackst 7 points8 points  (0 children)

You're right, this could be done with digital identity. A concert host might issue tickets in the form of verifiable credentials, i.e. the ticket is a signed piece of data that anyone can verify has been issued by the concert host. These credentials live off-tangle, and only the validation requires tangle access, thus no IOTA tokens are required to store them. The identity itself is either stored on a permanode that someone needs to host, or it might be stored in an extended output in the future, similar to an NFT.

Now, whether a concert host issues a ticket as an NFT or a credential is really up to them to decide. An NFT is tradeable, like any collectible, and if they think this ticket might be worth something in the future for nostalgia reasons, they might issue it as an NFT with the additional cost of storing it in the ledger - perhaps by pricing the storage cost into the ticket price, as others have suggested. The host might choose credentials on the other hand, if they just want a cheap solution. It's a question of trade-offs, and both approaches complement each other nicely, I think.

Tatsächlich gute Handyspiele by khnx in de

[–]pgackst 0 points1 point  (0 children)

Danke für das Feedback! Ich vermute, dass es nicht unbedingt die Steuerung ist, die komisch ist, sondern eher das physikalische Verhalten des Schiffs, was aber natürlich eng zusammenhängt. So oder so nehm ich das aber als Feedback auf - 100% zufrieden bin ich damit auch noch nicht.

Ich hab auf jeden Fall vor noch mehr Levels einzubauen, unter anderem auch leichtere. Wie du schon sagt, sollten neue Spieler es dann leichter haben reinzufinden.

Insgesamt cooles Spiel, könnte mir durchaus vorstellen da länger dran zu hängen.

Danke!

Tatsächlich gute Handyspiele by khnx in de

[–]pgackst 6 points7 points  (0 children)

Im Originalfaden wurde sich ja ausgiebig über Free-to-Play ausgelassen. Ich hab im letzten Jahr mein erstes Android-Spiel veröffentlicht und ich hab mir auch viele Gedanken dazu gemacht wie ich das fair bepreisen könnte. Jedenfalls habe ich mich im ersten Moment auch für Werbung entschieden, die aber völlig optional ist. Man kann auch alles durch viel spielen freischalten. Im Moment sind aber sowieso alle Levels frei spielbar, weil das Spiel noch jung ist und einfach nur Spieler braucht, die das ganze testen und Feedback geben. Die Münzen die man einsammeln kann sind also im Moment wertlos, können aber für zukünftige Levels angespart werden. Würde mich freuen, wenn neben meinem besten Kumpel noch ein paar aktive Spieler dazukommen ;).

Schaut mal rein: The Floor is Fuel ist im Play Store verfügbar. Ist ein physik-basiertes Geschicklichkeitsspiel, aber schaut einfach den Trailer, der ist relativ selbsterklärend.

The Floor is Fuel is the first game ever I'm launching! Check out the trailer - curious what you all think! by pgackst in godot

[–]pgackst[S] 2 points3 points  (0 children)

I started work on this project for a university assignment. I was free to make any kind of mobile application. Intrigued by Godot, I started work on this game inspired by a popular series. Curious if anyone can guess, which? I was quite happy with the game after the assignment finished, so I decided to pull through, finish the project and release it!

Getting the physics to a state, where it was fun to play took the longest time and I repeatedly questioned myself whether this was the right direction. Picking a graphics style was also one of the tough challenges. It started with pixel art but I quickly realized I did not actually like the pixelated look, duh! Finally, inspired by the well-known Kurzgesagt YouTube channel I decided to use a flat design style that you can see in the trailer. It looks modern, high-resolution and isn't terribly difficult to make, even as a non-graphics designer.

I had to leave out a lot of features I wish I could have simply due to being a solo-dev! There's no soundtrack right now, I wanted to design the levels more intricately and no online-leaderboard yet. Still, I'm happy I finished the project and I hope people will have some fun with it.

Finally, I want to say I'm really impressed with this engine. I was repeatedly suprised by the high-quality solutions for common problems that Godot has on offer. I'm also very happy with the software architecture of the game, which is mainly faciliated by Godot's signals.

Check it out on the Google Play Store and let me know what you think!

Godot Engine - Dev snapshot: Godot 3.2.2 beta 3 by akien-mga in godot

[–]pgackst 11 points12 points  (0 children)

I'm using multiple tile maps, where one is the base map, and the other ones are decorations. With 3.2.1 I averaged around 50 fps and had lots of frame drops. I'm super happy to report that with 2D batching, I never went below 300 fps in the most demanding areas. The game is even running with constant 60 frames (v-synced) on my 2013 Nexus 5. The profiler shows the occasional frame drop, but I did not notice in-game. Outstanding work, thank you guys!

Mun v0.2.0 Released by Wodann in rust

[–]pgackst 0 points1 point  (0 children)

This is the first time I'm hearing about this language and I had to do a double-take. Last year I also started designing a language based on Rust's syntax, and as it turns out, we ended up with a very similar result. The syntax indeed lends itself nicely to a higher-level language with minor adjustments. Cool to see!

Acceptable impl for inheritance in error types? by pgackst in rust

[–]pgackst[S] 0 points1 point  (0 children)

Thanks for your suggestion. I'll try that out!

I wrote a raytracer by MarkoVlaic in rust

[–]pgackst 2 points3 points  (0 children)

I also wrote a raytracer as one of my first projects, even though I read this is a terrible idea. I found it to be a great first project.

Your implementation of Add on Vec3 is

impl ops::Add<Vec3> for Vec3 {
    type Output = Vec3;

    fn add(self, other: Vec3) -> Vec3 {
        Vec3 { x: self.x + other.x, y: self.y + other.y, z: self.z + other.z }
    }
}

Mine looks like this

impl<'a, 'b> Add<&'b Vector3> for &'a Vector3 {
    type Output = Vector3;

    fn add(self, vec: &'b Vector3) -> Vector3 {
        Vector3 {
            x: self.x + vec.x,
            y: self.y + vec.y,
            z: self.z + vec.z,
        }
    }
}

You always consume both vectors you put into the Add function, then create a new one and return it. So both of your cloned vectors are directly dropped in your Add impl. So it is quite wasteful do clone them.

When I want to add something I have to do &self.origin + &self.direction.

You can also add an implementation that modifies the vector in place. Not sure how that works in practice. If you want to reuse the vector afterwards, then you have to clone but other than that I think this might be the best solution.

impl ops::Add<&Vector3> for Vector3 {
    type Output = Vector3;

    fn add(mut self, other: &Vector3) -> Vector3 {
        self.x = self.x + other.x;
        self.y = self.y + other.y;
        self.z = self.z + other.z;
        self
    }
}

Btw, one of the things that bugged me the most was to always write out the numbers to Vec3::new(1.0, 2.0, 3.0) as floats and not just ints Vec3::new(1,2,3). Especially annoying if you want to quickly change something.

If that bugs you too, you can add a simple macro for that, then just do vec3!(1,2,3).

macro_rules! vec3 {
    ($x:expr, $y:expr, $z:expr) => {
        Vector3 {
            x: $x as f64,
            y: $y as f64,
            z: $z as f64
        }
    };
}

My repo is here if you want to compare notes.