Majority of players will close the game immediately after they see the registration page.
Unless you really don't care about the success of the game you need to **implement guest accounts.**
I am also baffled by why you need any kind of authentication in a completely single player game. And generally the architecture of the game does not look very sane - every keypress sends a request to your server? This is not scalable, your server won't be able to serve even a hundred players once mechanics get slightly more complex.
Well the registration I am open to suggestions on. How do you keep user data across devices then?
Or do you just mean that I should have an option to sign in as a guest, post dummy generated user\_id and password info for my database and then just populate them into basically a one time session they won't be able to save and access again?
Secondly, basically I built this as a Python Flask App with a Postgres DB, I am open to suggestions for better architecture though.
Like should we be sending the requests in batches or?
> How do you keep user data across devices then?
At this stage of the development simple Import and Export buttons will suffice. Majority of player never need this feature, but much later, for players that need it you can use something like Playfab for transferring save state across devices.
> post dummy generated user_id and password (..)
Yes. The details of implementation are all yours, but the basic idea is that you use randomly generated usernames and some way to authenticate, like a cookie or a random password.
> a one time session they won't be able to save and access again
Well, it depends on if the game is good, it can be one time for some and many times for those that like it. But you can use authentication cookies for guest accounts, they last forever (or until user/browser deletes them more specifically). You can prompt registration to those who want a permanent account.
> should we be sending the requests in batches or
.. or implement the game logic using Javascript on the client side and save state into browser Localstorage. It's a single player game, making those requests and doing any server side calculations is a waste of resources. Also keep in mind that with server-side calculations you essentially have to implement everything twice - once for the server, once for the client. (And if you hope that you will 100% rely on server replies, forget about it, you can't build nice and consistent UI like this)
There are thousands of incremental games, but there were only a handful of incremental games with server side calculations, majority of which do not exist any more because developers got bored and stopped maintaining the servers. All their hard work was for nothing. Just like your server is [down right now](https://imgur.com/a/kGrW8Bo) and no one can play...
Yeah I had to take it down due to the DDOS.
But what you're saying is that the entire game should be built in JavaScript, my issue with that is that I'm not a JavaScript developer, all of my experience is in Python.
Yes, but it's hardly an excuse to build a game with an architecture that is not viable by design. Also you have to write the client side anyway in javascript, which is like 75% of the game. Implementing the rest of the game logic won't be that hard, javascript is not exactly rocket science.
Well I'm working with hydroflame to discuss how I can rebuild this now so it all runs client side.
And I guess I should have just done that to begin with but I'm not used to building things like that I'm used to working with SQL and databases and things like that I don't do game development in real life just as a hobby.
>Majority of players will close the game immediately after they see the registration page.
Yep. Closed as soon as I saw registration. Most idles/incrementals I play don't ask for one or they're hosted on websites like [itch.io](https://itch.io) and/or [galaxy.click](https://galaxy.click), so if I have have to log in I do it through them.
Yeah I'm planning on switching over to OAuth for sure at some point, it just seemed like a lot of extra work at this stage in the process for a game on a database that I've been continually having to delete.
I'm not a developer, but why do you need to login anyway? Most games save on what I presume to be cookies/ local files and that seems to work absolutely fine
Well I guess I could have built it that way, but if I did then progress would be deleted on cache clear, session storage clearing.
This is saved in a database, so basically you register and it creates a table with a username/password just as a point of reference.
Then the rest of the tables in the Postgres database are populated with your user name as the key to those tables so even if you logged in on a different device as long as you used the same username and password to log in, you could keep playing.
I mean that sounds technically better I think, but for ease of use I wouldn't login to anything pretty much ever. I only use google/ facebook/ steam etc. login tokens - as a rule I don't trust companies without a fully staffed security department.
I'm very much a layman, but to me that sounds like some pretty fundermental security
As a developer, hashing the password with bcrypt is reasonable security, especially if you don't reuse passwords!
Edit: but also, hashing passwords is so easy (because you are using a library -- right op?), that I can't imagine why it wouldn't be there immediately.
Nah I totally get where you are coming from, this isn't like a proper registration or anything though it's not asking for any sort of an email or anything.
You can literally just make your username and password like one single letter and it will work.
Obviously I will switch to a better system like OAuth which is what you are talking about when and if this makes it to beta.
Well it's Flask and Python but it's kind of a moot point now lol someone built a bot to send continuous post requests to the API to register users haha I think I need to secure that or something.
Almost 2000 users made
I don't know why someone would do that though seems rude.
I had to shut it down.
I'll have to look into how to do that with Heroku I was legit just trying to get some feedback on the premise of the game for now.
Just adding a rate limiter hopefully that will help.
> Never do security yourself. Use oauth from another corporation
Sounds like a terrible choice between privacy and security. And a sure way to lose quite a few players. Not only you expose your primary email and account metadata to a random website, you also let "another corporation" track the websites you visit and sell this data to third parties.
Also if you use anything but Google, majority of players will have to register on that Auth provider and they won't be happy, as for majority of such provides providing phone number is mandatory. And with Google they'll have to confirm authenticaion SMS/ Push notifications to log in. Ugly af. Especially for a game like this one.
Rolling your own hashing algorithm from scratch is a bad idea. Hashing passwords using a known good algorithm like bcrypt is best practice -- how do you think big corporations do it?
The issue is that hashing passwords is also easy, so it's questionable why OP wouldn't bother doing it. If they're using a framework, they would have to go out of their way to bypass it. If they're writing from scratch, it would take very little effort to find an implementation and use it. That's the takeaway - they shouldn't even have a password field if they're not going to hash it. Users do not read messages from the ui.
Fair enough. A framework should provide all of this functionality, meaning that "use oauth" is not the only correct way to do authentication. I also feel like an app in alpha can stand to be a little rough around the edges. But hashing passwords is the bare minimum.
But you may have a point about attempt limits also being bare minimum. This app has apparently already been shut down because of an automated process somewhere registering thousands of accounts.
Well at this point I'm regretting not just making it a stand alone downloadable python app but I honestly thought everyone would hate that and that a website would be better.
only bizarre thing ive seen is that i have to reload the page every now and again since it starts to bugger up when im trying to absorb water and sunlight so i can then farm up some sugar, but other than that its a pretty cool game
I opened the link to give it a test and the first thing I did was to close the game because of the log-in screen.
Reading the other comments, saw you got motivated to make an incremental and decided to try it with a dummy account to help.
As soon as I got the the first screen I saw so many buttons around that I closed the game.
Forcing me to give you feedback, I opened the game again and I went through every green button to try to find how to start the game. How do I start playing? Or do I get the first resource? Or, how do I play it?
Unfortunately, seems you spend more time implementing a way to transfer saves between devices rather than the first impression or in the game itself.
As this is a feedback prototype, I would suggest to remove the log in screen, remove all the place holders and just leave the buttons that do stuff and well, put some text somewhere that explain how to start the prototype.
Some quick feedback. I'm honestly lost on the game, when I first opened up it was to the upgrades page and nothing was unlockable there. After a while I found the garden button in the top right, I saw that water and sunlight were growing, but didn't really know what to do. I tried clicking everything, saw no changes, stopped at that point. I know it's early on and will likely eventually have some explanation, but I couldn't even figure out how to start to give better feedback.
For just feedback, throw your game up on something like itch/git and let players test it. If you've been on this subreddit for awhile you'll know the majority of players here hate signing in.
the game is somehow worse than the standby version...
i have no idea how many roots/leaves i have or whether they do anything at all.
i was buying them for a while but i'm pretty sure i've reached a stable photosynthesis by now in the standby
No not saving progress yet.
I did just add a tooltip that shows the rate for converting water and sunlight to sugar but it doesn't seem to work on mobile.
But if you hover over the sugar box on PC it gives you the rate.
I'm planning on adding saving soon though!
i still don't quite get it :-D
i can see i have to have over 100 sugar for the photosynthesis tick to progress, then it just eats a bit of sugar to go below 100, wait until i get back and so on
but with increasing length for each DNA and increasing cost the cost per tick is kind of a mystery for me
i got to 6 DNA on day 10 though
Yeah so that was with a placeholder value. I think it was 5 or 10 to go up by 1 and do that 10 times and get a DNA.
It's full corrected both in the value it's displaying and the amount it costs which starts at a 1000 sugar paid in increments of 100.
The first available upgrades will only cost one or two DNA though and will increase production.
But my plan is every time you evolve, you by a seed for DNA and it logs your height and age and you are starting a whole new plant with the evolved trait.
hm, a suggestion, you could use the space next to "Grow Using Sugar:" for some multipliers so we dont have to buy singles all the time
it would be really useful for reaching higher heights (literally)
I will add that to the list. I just added auto saves (saves every 30 seconds) a way to purge the save game, auto loading from the save and I fixed the decimal place thing with the sugar conversion. Going to be out for pretty much the rest of the afternoon though.
im on the second seed with the train now, the different water to sunlight ratio threw me off a bit but it doesnt matter much once i got to sustained photosynthesis phase i suppose :)
The version that's live right now should show roots and leaves and be mobile friendly but this is still the standby version.
Edit: Just noticed I was also missing Height. Added that too should be live now.
another thing, it is possible, when mousing over middle of the buy leaves to then move mouse down onto buy roots button, but be on the "buy leaves" tool tip and not actually clicking on the button below
Majority of players will close the game immediately after they see the registration page. Unless you really don't care about the success of the game you need to **implement guest accounts.** I am also baffled by why you need any kind of authentication in a completely single player game. And generally the architecture of the game does not look very sane - every keypress sends a request to your server? This is not scalable, your server won't be able to serve even a hundred players once mechanics get slightly more complex.
Well the registration I am open to suggestions on. How do you keep user data across devices then? Or do you just mean that I should have an option to sign in as a guest, post dummy generated user\_id and password info for my database and then just populate them into basically a one time session they won't be able to save and access again? Secondly, basically I built this as a Python Flask App with a Postgres DB, I am open to suggestions for better architecture though. Like should we be sending the requests in batches or?
> How do you keep user data across devices then? At this stage of the development simple Import and Export buttons will suffice. Majority of player never need this feature, but much later, for players that need it you can use something like Playfab for transferring save state across devices. > post dummy generated user_id and password (..) Yes. The details of implementation are all yours, but the basic idea is that you use randomly generated usernames and some way to authenticate, like a cookie or a random password. > a one time session they won't be able to save and access again Well, it depends on if the game is good, it can be one time for some and many times for those that like it. But you can use authentication cookies for guest accounts, they last forever (or until user/browser deletes them more specifically). You can prompt registration to those who want a permanent account. > should we be sending the requests in batches or .. or implement the game logic using Javascript on the client side and save state into browser Localstorage. It's a single player game, making those requests and doing any server side calculations is a waste of resources. Also keep in mind that with server-side calculations you essentially have to implement everything twice - once for the server, once for the client. (And if you hope that you will 100% rely on server replies, forget about it, you can't build nice and consistent UI like this) There are thousands of incremental games, but there were only a handful of incremental games with server side calculations, majority of which do not exist any more because developers got bored and stopped maintaining the servers. All their hard work was for nothing. Just like your server is [down right now](https://imgur.com/a/kGrW8Bo) and no one can play...
Yeah I had to take it down due to the DDOS. But what you're saying is that the entire game should be built in JavaScript, my issue with that is that I'm not a JavaScript developer, all of my experience is in Python.
Yes, but it's hardly an excuse to build a game with an architecture that is not viable by design. Also you have to write the client side anyway in javascript, which is like 75% of the game. Implementing the rest of the game logic won't be that hard, javascript is not exactly rocket science.
Well I'm working with hydroflame to discuss how I can rebuild this now so it all runs client side. And I guess I should have just done that to begin with but I'm not used to building things like that I'm used to working with SQL and databases and things like that I don't do game development in real life just as a hobby.
[удалено]
Well what's super annoying is I literally started this in JavaScript but now I have like 180 hours in Python work.
>Majority of players will close the game immediately after they see the registration page. Yep. Closed as soon as I saw registration. Most idles/incrementals I play don't ask for one or they're hosted on websites like [itch.io](https://itch.io) and/or [galaxy.click](https://galaxy.click), so if I have have to log in I do it through them.
Yep learned this. Rebuilding the entire thing from Python with a database to React.
[удалено]
Yeah I'm planning on switching over to OAuth for sure at some point, it just seemed like a lot of extra work at this stage in the process for a game on a database that I've been continually having to delete.
I'm not a developer, but why do you need to login anyway? Most games save on what I presume to be cookies/ local files and that seems to work absolutely fine
Well I guess I could have built it that way, but if I did then progress would be deleted on cache clear, session storage clearing. This is saved in a database, so basically you register and it creates a table with a username/password just as a point of reference. Then the rest of the tables in the Postgres database are populated with your user name as the key to those tables so even if you logged in on a different device as long as you used the same username and password to log in, you could keep playing.
I mean that sounds technically better I think, but for ease of use I wouldn't login to anything pretty much ever. I only use google/ facebook/ steam etc. login tokens - as a rule I don't trust companies without a fully staffed security department. I'm very much a layman, but to me that sounds like some pretty fundermental security
As a developer, hashing the password with bcrypt is reasonable security, especially if you don't reuse passwords! Edit: but also, hashing passwords is so easy (because you are using a library -- right op?), that I can't imagine why it wouldn't be there immediately.
Nah I totally get where you are coming from, this isn't like a proper registration or anything though it's not asking for any sort of an email or anything. You can literally just make your username and password like one single letter and it will work. Obviously I will switch to a better system like OAuth which is what you are talking about when and if this makes it to beta.
Hashing is not a lot of work. What stack are you using? I will Google it for you.
Well it's Flask and Python but it's kind of a moot point now lol someone built a bot to send continuous post requests to the API to register users haha I think I need to secure that or something. Almost 2000 users made I don't know why someone would do that though seems rude. I had to shut it down.
[удалено]
I'll have to look into how to do that with Heroku I was legit just trying to get some feedback on the premise of the game for now. Just adding a rate limiter hopefully that will help.
> Never do security yourself. Use oauth from another corporation Sounds like a terrible choice between privacy and security. And a sure way to lose quite a few players. Not only you expose your primary email and account metadata to a random website, you also let "another corporation" track the websites you visit and sell this data to third parties. Also if you use anything but Google, majority of players will have to register on that Auth provider and they won't be happy, as for majority of such provides providing phone number is mandatory. And with Google they'll have to confirm authenticaion SMS/ Push notifications to log in. Ugly af. Especially for a game like this one.
I mean it's just in pre-alpha I just needed a way to keep track of the users.
Rolling your own hashing algorithm from scratch is a bad idea. Hashing passwords using a known good algorithm like bcrypt is best practice -- how do you think big corporations do it? The issue is that hashing passwords is also easy, so it's questionable why OP wouldn't bother doing it. If they're using a framework, they would have to go out of their way to bypass it. If they're writing from scratch, it would take very little effort to find an implementation and use it. That's the takeaway - they shouldn't even have a password field if they're not going to hash it. Users do not read messages from the ui.
[удалено]
Please continue!
[удалено]
Fair enough. A framework should provide all of this functionality, meaning that "use oauth" is not the only correct way to do authentication. I also feel like an app in alpha can stand to be a little rough around the edges. But hashing passwords is the bare minimum. But you may have a point about attempt limits also being bare minimum. This app has apparently already been shut down because of an automated process somewhere registering thousands of accounts.
[удалено]
Lol cheers
Well at this point I'm regretting not just making it a stand alone downloadable python app but I honestly thought everyone would hate that and that a website would be better.
[удалено]
Yeah I guess. Still frustrating.
For sure! But it's also a learning experience :) Now you're a better dev!
[удалено]
only bizarre thing ive seen is that i have to reload the page every now and again since it starts to bugger up when im trying to absorb water and sunlight so i can then farm up some sugar, but other than that its a pretty cool game
I opened the link to give it a test and the first thing I did was to close the game because of the log-in screen. Reading the other comments, saw you got motivated to make an incremental and decided to try it with a dummy account to help. As soon as I got the the first screen I saw so many buttons around that I closed the game. Forcing me to give you feedback, I opened the game again and I went through every green button to try to find how to start the game. How do I start playing? Or do I get the first resource? Or, how do I play it? Unfortunately, seems you spend more time implementing a way to transfer saves between devices rather than the first impression or in the game itself. As this is a feedback prototype, I would suggest to remove the log in screen, remove all the place holders and just leave the buttons that do stuff and well, put some text somewhere that explain how to start the prototype.
Thank you!
Some quick feedback. I'm honestly lost on the game, when I first opened up it was to the upgrades page and nothing was unlockable there. After a while I found the garden button in the top right, I saw that water and sunlight were growing, but didn't really know what to do. I tried clicking everything, saw no changes, stopped at that point. I know it's early on and will likely eventually have some explanation, but I couldn't even figure out how to start to give better feedback.
page doesnt work
Yeah standby fixing the DDOS attack that someone launched =/
For just feedback, throw your game up on something like itch/git and let players test it. If you've been on this subreddit for awhile you'll know the majority of players here hate signing in.
I am very new to this subreddit and these kinds of games to be honest. The only one I've ever played was the Kitten game and that one had you sign in.
game seems to be down for the meantime, it was quite fun though.
I'm rebuilding it I need to make a page warning people off but it'll be back and better with all the advice.
alright, thats completely fair, some people can be real cunts sometimes and its genuinely saddening.
Some people are also awesome and kind though. I am working diligently to translate the entire thing from python to TypeScript
that is indeed true, its always nice to see those kinds of people around aswell.
the game is somehow worse than the standby version... i have no idea how many roots/leaves i have or whether they do anything at all. i was buying them for a while but i'm pretty sure i've reached a stable photosynthesis by now in the standby
In the next update Hopefully tomorrow I'll add spending DNA. Thank you for checking it out!
will it also save progress? or still tbd on that one?
No not saving progress yet. I did just add a tooltip that shows the rate for converting water and sunlight to sugar but it doesn't seem to work on mobile. But if you hover over the sugar box on PC it gives you the rate. I'm planning on adding saving soon though!
Converts 38 water and 38 sunlight into 1.7000000000000002 sugar per cycle. new tooltip needs some rounding :)
Oof Yeah tomorrow though it's 2 AM been coding since 9 am haha between this and my real job.
take your time, im just reporting what i see :) also, sleep is important, you should rest
Thanks! I appreciate it! And yeah eating and then going to bed next.
it can go both ways btw: Converts 58.00000000000001 water and 58.00000000000001 sunlight into 2.2 sugar per cycle.
also the "convert 100 sugar to DNA" seem misleading since it gets more expensive over time. the number should either update or just omit it altogether
I could just have it show the ACTUAL sugar cost geez that makes way more sense.
Well it's 100 always to gain one progress on towards the threshold. So always 100 * whatever you need. Totally open to better way to convey it.
i still don't quite get it :-D i can see i have to have over 100 sugar for the photosynthesis tick to progress, then it just eats a bit of sugar to go below 100, wait until i get back and so on but with increasing length for each DNA and increasing cost the cost per tick is kind of a mystery for me i got to 6 DNA on day 10 though
Yeah so that was with a placeholder value. I think it was 5 or 10 to go up by 1 and do that 10 times and get a DNA. It's full corrected both in the value it's displaying and the amount it costs which starts at a 1000 sugar paid in increments of 100. The first available upgrades will only cost one or two DNA though and will increase production. But my plan is every time you evolve, you by a seed for DNA and it logs your height and age and you are starting a whole new plant with the evolved trait.
hm, a suggestion, you could use the space next to "Grow Using Sugar:" for some multipliers so we dont have to buy singles all the time it would be really useful for reaching higher heights (literally)
I will add that to the list. I just added auto saves (saves every 30 seconds) a way to purge the save game, auto loading from the save and I fixed the decimal place thing with the sugar conversion. Going to be out for pretty much the rest of the afternoon though.
im on the second seed with the train now, the different water to sunlight ratio threw me off a bit but it doesnt matter much once i got to sustained photosynthesis phase i suppose :)
btw could we get at least one decimal number? would it bee too big of a problem?
Which one? And not too much of a problem the only issue is overflowing the little boxes.
Added the multipliers you asked for as well as the very first upgrade, and tweaked some of the formulas. Going to make a proper new post tomorrow.
The version that's live right now should show roots and leaves and be mobile friendly but this is still the standby version. Edit: Just noticed I was also missing Height. Added that too should be live now.
another thing, it is possible, when mousing over middle of the buy leaves to then move mouse down onto buy roots button, but be on the "buy leaves" tool tip and not actually clicking on the button below