Ry-E / Genesis

Discription? Excellent question.
0 stars 0 forks source link

How do we build our game? #2

Closed Ry-E closed 2 years ago

Ry-E commented 2 years ago

2D MULTIPLAYER GAME?

So how do we do this? What do we need? Any other details we need to figure out before we can start loading up on to-dos?

Thinking about angles, I do think we should try and slowly expand on this universe by adding rpg-ish elements to a base world, which would have an overhead zelda style angle (right?), do you guys think we could go use the same assets inside a side-view platformer like smash bros? It would be cool if we could go from traditional smash bros view when battling to zelda view for the open world using the same assets. I haven't looked into it but I feel like it would be possible to use the same assets and just change the camera angle? or should we just try and build a smash bros-esque game with a zelda view?

Ry-E commented 2 years ago

Things we might need in place for the development/release of game:

  1. a game
  2. landing page
  3. blog for updates?
  4. ?

Maybe we should discuss a tech stack? yikes.

The current state of web3 gaming is almost entirely web-based to my knowledge. I know Gods Unchained has a downloadable software tho so maybe we could try that route

Ry-E commented 2 years ago

Also well need to figure out how we will organize development using this repo. idk the best workflow but just to start maybe a development and production branch with a system for adding feature branches as need?

maybe we should try and agree on a best practices for implementing new code, thorough comments, maybe an agreed upon code style, variable name conventions, valuing efficient vs readable code, ... tabs vs spaces!?!?!? obvi tabs

bhowl commented 2 years ago

I am all for basecamp:overhead and smash:side. fucking dope. I think if the game is completely 2D then they would be separate assets but not that hard to pull off - One would be the top of the character's head and the other would be them from the side (might need additional assets for walking, punches and kicks, etc).

If we make the main characters 3D assets then we could probably use the same asset for both views - just change the camera angle.

Tools: 3D digital content creation (dcc): Blender 2D DCCs: Gimp/Adobe/Procreate Audio DCCs: Ableton Integrated Development Environments (IDEs): Visual studio code I'll have to research more for actual tech stack Real-time Engines: Unity

I've seen the Wiki tab within github is used to roadmap. Idk if that's meant to be used at this stage or more later on but we could start putting ideas down there as well. Actually i think that might be a good place to put Best Practices

bhowl commented 2 years ago

I think a good goal to start might be creating the overhead view. We could aim just to have a flat 2D land and load our characters into the map so that we can control them and move them around with the keyboard or controller or whatever.

Ry-E commented 2 years ago

Oh the wiki tab is perfect, nice.

and idk I think we might actually be able to swing side view assets in a top-down game if we use the right angle. check these out:

Northern Guilds: 1*ANVoyL6lcIYGA68vmQANLw

Stardew Valley Stardew-Valley-2-2000x1270-1-696x442

Earthbound Returns Eartbound_Returns

it would only be two more angles per asset if we had to do both views but if we could cut a few corners and have it still look niceI think it might be worth it

Northern Guilds has the potential to be a badass game, but they just started working on it. It's blockchain-based tho and play to earn so we should monitor their progress and use them as a case study as we develop.

Unity might be the best idea but I also would totally be down to using something like Pygame, PixiJS, phaser.js, or processing. Or perhaps even some other graphics library that starts with a P. Ive been messing around with game mechanics in p5.js and I think that might be a good place to prototype stuff too, at least for js users lol

I do think a roadmap now is a good idea, at least a rough one. We can decide on a minimally viable product and figure out the main steps there, and then just start iterating

and yeah that sounds like the coolest and simplest thing we could do right away

bhowl commented 2 years ago

Oh yeah 2D assets from the side totally works and I like the look. I was imaging only top of head for some reason.

I will look into P graphics libraries lol.

JS sounds good to me tooo0

Yeah just like a rough road map to have some vision to guide us. Flesh it out as we progress

howl0893 commented 2 years ago

Northern Guilds looks like it's gonna be awesome! I wonder if they mention their technologies used anywhere? Little demo if you haven't found it already: https://play.northernguilds.com/

Pretty much the only thing you can do so far is eat shrooms and run around, nice lol

They tweeted about building their own native engine:

& they are already trading NFTs before the game has been released from 0.034 ETH to 100 ETH, damn. https://opensea.io/collection/northern-guilds-guild-of-thor


So adding to the things we might need in place for the development/release of the game:

  1. NFT collection
  2. Social media promotion

Unity seems like the most powerful - bang for your buck - option, and probably would be the easiest getting onto different gaming consoles, buuut also might be the steepest learning curve. Also not sure how difficult the blockchain integration would be with Unity. I know they have some plugins, but I imagine the support would be limited compared to a pure JS or python library.

Hard to choose one without experience using any of em, I'll start tryin em out too.


For best practices, we should try to follow the official style guides as close as we can for whatever language we are using. For example, python has PEP 8 and javascript has MDN and a google style guide. Not sure what the differences are for those JS style guides. I honestly don't even reference those sheets that often, usually just google JS naming convention for classes or something real quick and then MDN or google will be the first search result.

howl0893 commented 2 years ago

Just found a pretty thorough Zelda style tutorial for pygame: https://www.youtube.com/watch?v=QU1pPzEGrqw https://github.com/clear-code-projects/Zelda

& a smash bro example GitHub: https://github.com/justinbridouille/smash-bros

I ran it on my system, might be some good starting points if we were to opt for pygame:

image

Ry-E commented 2 years ago

I know, the demo is hilarious, just run around and trip balls haha. and yeah the people who created it are probably already retired from the nft collection, with literally the only functionality in the game is running around and eating shrooms, and their assets are already worth hundreds of thousands of dollars. redonkulous. that could be us. it will.

even tho I don't know python I've heard cool things about pygame and would like to try it but the only thing is what our plan is going to be for release. Are we going to want it in the browser? or downloadable software? Im not sure why nearly all web3 games are browser-based, there must be something keeping them back from releasing on steam, or as an app download. The only example I know is gods-unchained, which you download, and i know they have a mobile app in the works so they definitely have something figured out. but it is still pretty rough UX and you do have to constantly use the browser too to collect coin rewards and monitor your stats.

if you guys haven't yet you should check it out though, it has been filling my MTG void while simultaneously netting me some decent pocket change rewards weekly. They currently have an option to vs a friend but its only 1v1 right now although i think they might try and add more modes eventually, as they are still in beta too.

its FTP and PTE as well and i think we should also study their play to earn model and use them as a case study as they progress as well. Buidling a reasonable game economy is probably going to one of the hardest parts and i feel like gods unchained (GU) has done a pretty decent job at that. their current beta system involves an initial release of new assets, followed by a testing phase where assets features can still be modified, and then eventually they lock the release and the cards stats are forever engrained into the blockchain. They also have a CORE set of cards that can always change but will never be mintable. They continue to try different pte strategies and currently they have the WEEKEND RANKED event where every weekend your record for the first 25 games you play can earn card packs + $gods tokens depending on how many wins you have and what rank you were going into the weekend. lower quality card packs will have mostly non-nft cards in them but the higher quality ones do, and you sell them for more $gods, and then use those to buy better cards for your deck. Ive been able to buy a couple of cards most weeks and it feels like a cool system. Also..depending on the card too, if you have duplicates, you can combine them to mint an nft version of the same card. but yeah there's a lot, you guys should poke around.

okay back to the tech stack. I know pygame is cross-platform which is cool but i don't think pygame runs in the browser. If we want it in the browser we could find a way to compile it into js but that would be added complexity.

I wish we could use the game engine northern guilds is building, maybe we work on a nice demo and then rebuild it once they hopefully release the engine publicly lol.

Part of me feels like we should just focus on browser initially, its the simplest way to get a lot of accessibility quickly, and then if there is enough interest from the community we can build out native ports. I also like the idea of using python tho too cause I know matt, you, have the most coding chops and it would be nice to rest the weight of the entire game on your shoulders.. lol. but seriously i think having our codebase in the language our top programmer is most comfortable with would be beneficial. But then again I'm sure you would have little problem quickly becoming proficient in javascript too (if you arent already), which would make it easier for me and brad. so idk guys.

Could a python backend with a js frontend make sense in this situation?

bhowl commented 2 years ago

Northern Guilds is great haha #goals. I've added some of what you said to the wiki Matt. Also those are good github links - definitely should reference those! How does the ethereum stack intermingle with the game's stack? (maybe this is a separate issue on its own)

I played God's Unchained for a stint about a year ago before Immutable X. They were teasing coming out with X which you probably know but is supposed to be some great layer 2 ethereum solution. and their dev team is reputable. I think they've teamed up with GME actually, not completely sure about the details of that. I still have it downloaded, I'll have to check it out again. I haven't seen the mint store yet.

echo "I also like the idea of using python tho too cause I know matt, you, have the most coding chops and it would be nice to rest the weight of the entire game on your shoulders.. lol. but seriously i think having our codebase in the language our top programmer is most comfortable with would be beneficial."

If we can do Browser then eventually make a somewhat smooth transfer to application then I'd say we go with that. Browser seems easier because I am most familiar with front-end web application stuff but I am also willing to learn. I'm sort of ignorant of details toward program applications as far as experience goes... so I'll continue to read up on that front.

howl0893 commented 2 years ago

I'm pretty sure we could actually hack our way to running pygame in the browser... but that definitely isn't an ideal route for an in-browser game. Which I agree, we should focus on at first. You guys are gassing me up too much lol. Most of my coding experience is with external hardware. I still have a lot to learn too! I have been working with javascript more and more lately for a project at work though. I am starting to feel more proficient. & that one seems like it makes the most sense to use! We just gotta figure out which JS graphics library to use.

& as I type this I joined the Northern Guilds discord & found in this article they mention they use PixiJS. So maaybe we found our winner haha.

I am in favor of using a python backend, js frontend. Even if it's just via API calls I think having python tools will be worth it and might give us some flexibility down the road. I can set up the backend & then show y'all how it works. Once it is set up it should be pretty routine to use (in theory).

I signed up for God's unchained a while ago but never got around to playing. I'll check it out. Sounds dope. I relate to the MTG void you speak of.

Ethereum stack is a good question & might deserve its own issue. Not sure where to begin on this one just yet.

howl0893 commented 2 years ago

Brad, my thoughts on your wiki question:

landing page (is landing page like Northern Guilds demo/different from website?)

I am thinking yes, they'll be different. landing page for info about the game, social links, a blog, & hopefully a link to play the game... Maybe since they don't have an official release for the game they haven't included a play game button yet.. I feel like they should have that anyway though

bhowl commented 2 years ago

nice article Honestly, PixieJS is kind of mindblowing me right now, so lightweight. I think it's a great choice. 10:4 on landing page

howl0893 commented 2 years ago

Yeah, it is pretty crazy, a little intimidating it is so lightweight.

Also wanted to link the tools mentioned in that article for what they use for asset creation: Tiled, Aseprite, and Photoshop

https://de.humblebundle.com/downloads?key=7yzwuW7zkZnnu8ZK

howl0893 commented 2 years ago

Some useful PixiJS references

platformer: https://github.com/letumfalx/TheLostAdventurer

overhead: https://github.com/Reynau/the-game

Ry-E commented 2 years ago

Yeah im thinking we'll end up with something like ourXgame.com for the landing page and app.ourXgame.com for the actual game.

Ill start a new issue for incorporating ethereum, definitely a pretty complex topic.

Do you guys think well need different servers for the landing page and the actual game? I'm sure we could build a server that handles everything but would it be better to have some separation of concerns? I'm curious how companies manage all the different kinds of traffic they get. i recently was reading about proxy servers and I'm curious if this would be a decent use case, i could be way off tho lol. Everything could be sent to the proxy, and then the proxy send the request to the appropriate server. I'm sure we could implement that later though if it actually helped.

what about databases? you guys have any preferences here? or is a DB included in your backend set up matt?

That northern guilds article has so many helpful gems in it! I noticed they clarified they are using Orthographic projection, which has to do with the angle of assets, and i think we need to decide on the exact design parameters we want to use.

So we have a pretty good general idea of how we are going to do this:

2d, pixel-art ...?(not sure if we agreed on this but it has my vote), top-down + side view elements), PixiJs engine, python backend, Asesprite or alternative)

I think it might be best if we branch off into a few more specific topics, maybe we can close this soon.

Wikis looking dope brad!

howl0893 commented 2 years ago

A proxy server is a good idea & may be needed eventually. Not really sure what the threshold traffic is for when you need a proxy server. But it's also good for security - putting in a middleman between your client and server. I think we can hold off on implementing that for a little while though. I don't think adding it in at a later time would be too difficult or add many changes to the frontend or backend.

I have used MongoDB the most & that was going to be the one I used with the python backend. But that is a centralized database... and I kinda want to be completely decentralized. Not really sure of all the options for decentralized storage. On first thought, my mind goes to IPFS and filecoin.

Also, I take back being in favor of a python backend... I am good with using whatever makes more sense. After looking around a bit, it doesn't look like a lot of web3 libraries have a python API. I am seeing a lot of rust and go... I would be down to try one of those. Supposedly go is easy to learn.

I am down for pixel-art. That seems like the easiest asset creation starting out.

Ry-E commented 2 years ago

id be interested in using go, ive heard good things.

I found this article that goes into storage with ipfs pretty well, IPFS Gaming Storage

I do like the idea of being entirely decentralized, it sounds like it might get prohibitively expensive the more we are storing and accessing though. Seems like IPFS could potentially help us strike a nice balance, but i haven't looked into alternative options

Ry-E commented 2 years ago

There is also hosting to work out, if anyone has any preferences. we could probably start with a free service and then upgrade to paid once its necessary? We should be able to start for free with GCP and firebase or heroku, Im not sure about AWS, i think we can get a year free and then its based on traffic after that. maybe there is some decentralized solution we could look for.

Ry-E commented 2 years ago

Im just going to lay down a potential tech stack and we can either start working on stuff or critique it

I think we might be able to start with essentially everything centralized as we flesh things out and then we can introduce/replace things with decentralized services as we see fit.

Game frontend / asset design : PixiJS + Aseprite

Backend: Go + MongoDB + PostgreSQL + Ethereum + IPFS (I like MongoDB , especially to start with cause we can be more flexible in designing the data and then i think we might need a relational db at some point but we can add that once we have a better idea of the types of relationships are data will have. I think Postgresql would be a good db for that stuff. Any other opinions on this matter are appreciated)

Hosting: GCP / AWS (a note on hosting - Hosting should probably influence how we design our workflow. I'm thinking hosting will work by us just connecting a specific branch of our repo to the hosting provider. I know its possible for us to have the server + front end being hosted in the same project but i think services usually hosts their frontend and backend separately using completely different repos. It would be nice if we could keep everything in one repo though, so i wonder if we could have two different streams of branches going on in our repo. like a development front end, production frontend, development backend, and production backend. and then we can host separately both production branches. We just have to commit to the appropriate branch. I don't know if this is a good idea or not tho, i wouldn't be surprised if it is actually recommended to avoid such practices)

howl0893 commented 2 years ago

This sounds good to me. Enough to start working and pivot as needed.

Fiber looks like a good backend framework: https://github.com/gofiber/fiber

I don't know a whole lot about hosting, but I have heard good things about Heroku Nginx and Netlify. Have you heard of those?

I would vote for keeping the backend and frontend in the same repo until we find a reason to separate them... which I think you're right hosting might be that reason. I like the idea of having dev/production backend/frontend branches if we could pull that off

bhowl commented 2 years ago

I like pixel art idea.

We could maybe use OrbitDB (decentralized) which is built on top of IPFS. I think it has pretty good documentation. OrbitDB field manual GitHub

the actual manual.pdf

Although OrbitDB doesn't seem like the best option for our use-case so it might be a headache

bhowl commented 2 years ago

You can start an IPFS node easily from the command line, pretty cool. I think hosting the app on IPFS would be sweet but definitely will want to host it normally as well. Oo and it looks like IPFS is integrative or something with the Go programming language

bhowl commented 2 years ago

Yeah all sounds good... could we close this issue and break into sub-issues. Hosting is an issue on its own.

I added this to wiki for now: Game frontend / asset design : PixiJS + Aseprite Backend: Go + MongoDB + PostgreSQL + Ethereum + IPFS

Fiber could be a good framework

I am thinking we may want to make a discord and have a thread for each of the tools we use so we have a place to talk tool specific stuff in an organized way. Or make an issue for each of them in github? idk

bhowl commented 2 years ago

Also probably good practice to transfer anything valuable from #issues to #wiki before we close - so in this case the projected tech stack and we can go on to define it better in another issue.

bhowl commented 2 years ago

I'm loving what I'm reading as I jump into Golang - great documentation on their site! I noticed Brian Kernighan from the infamous The C Programming Language textbook (also goes by just K&R for authors Kernighan and Ritchie, the latter being the creator of C) wrote a book for Golang - The Go Programming Language. Thought you guys might be interested in picking up a copy of both texts on libgen.rs