Content pfp
Content
@
0 reply
17 recasts
17 reactions

Myk.eth pfp
Myk.eth
@myk
What is the most challenging aspect of building onchain games?
6 replies
0 recast
12 reactions

Lev1tate_1 pfp
Lev1tate_1
@lev1tate1
I'll answer in one word Economy 99% of the time, the token kills the project.
1 reply
0 recast
1 reaction

YuriNondual pfp
YuriNondual
@yurinondual
Another thing (case specific): if this is not a FOCG, but you need user to sign a tx at the end of the session to store the game results on-chain, then you would need to validate the user session somehow to prevent abuse. We have built something like that for /skybreach that uses combination of SIWE, jwt and redis. Basically there's a server involved to record session start, then session end, validate it, then sign results with pk, return it to client and then client can pass it together with r,s,v to contract so it could validate further and store. Again it's very case specific, but it was quite time consuming thing to build securely.
0 reply
0 recast
1 reaction

temitopeohassan.base.eth pfp
temitopeohassan.base.eth
@temitopeohassan.eth
i’d say value proposition design for a couple of projects i’ve seen the only value proposition for the game is for tokens and not the actual game experience basically doesn’t address the “why do people play games” question
0 reply
0 recast
0 reaction

iSaber💎🎩🍖 pfp
iSaber💎🎩🍖
@i-saber
Building onchain Games🤷🏼
0 reply
0 recast
0 reaction

YuriNondual pfp
YuriNondual
@yurinondual
Another thing: The whole paymaster thing is never easy no matter how many guides and tutorials are created. It's just the way it is with a current standard. It doesn't help also how many vendor locks you accept when implementing sponsored txs. Just feels dirty to implement and I am trying to stay away from it as long as possible, although this would allow for a superiod non-web3 user onboarding
0 reply
0 recast
0 reaction

YuriNondual pfp
YuriNondual
@yurinondual
A lot of ux (batched txs, user onboarding) can be solved with embedded or smart wallets, but you want to allow users to use their existing wallets too. I know solutions like Privy's account linking exists, but so far I am a bit wary of centralised embedded wallets. I don't know yet what could be the solution except for maybe an sdk that can abstract and unify dev-ex when dealing with different types of wallets (for EOA it would use erc7702 perhaps, and for smart wallet something more appropriate?)
0 reply
0 recast
0 reaction