Open jrtechs opened 4 years ago
The topic of branching strategies was brought up yesterday so I'll though my two sense in. I think we should have 4 branches, one per person, then a features branch to merge each of our changes into before merging to master.
Alright, I'm going to kick start some development tonight.
Pertinent Links:
I'm going to set up a main "develop branch" for Fractionauts and see if I can get the template rolling on that. We can then branch off of that for each feature we do.
The development has started :partying_face:
Everything is happening on this branch: https://github.com/ritjoe/sugarizer-lite/tree/fractionauts-dev
I created a basic sugar activity and configured the icon and name.
I'm currently getting this issue when I launch sugarize:
[13632:0423/213623.951552:ERROR:buffer_manager.cc(488)] [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error from previous GL command
Sugarize opens but it is just a plain white screen. I have a suspicion that a config file might be incorrect, but, I'm not going to toss out the possibility of an environment issue.
@zethra what was that game library that you wanted to use? It sounded like that may be a good route to go for this.
fyi the PhysicsJS activity is a good example of a webgl activity. It's pretty simple and uses Pixi.js, some static assets.
I'd like to try using Godot if that's okay with Ya'll. I think it'll be easier than writing JS by hand.
@zethra I think Godot would be fine. Did you happen to write up anywhere how we transfer a Godot project into a sugarize activity?
Take a look at this https://write.as/zethra/godot-sugarizer-profit
It's not a tutorial exactly but it's a start and links to a (hopefully) working example.
Sweet! That looks easy to do. All we really need to do is copy in the template game from godot to the activities directory that I already created for Fractionauts and then modify that build script you wrote.
In my proof-of-concept I had the Godot project in a separate repo and how did as a git sub-module. Not sure if we want to do that or just have it in the main repo for this. What do you think?
On Apr 26, 2020, 10:56, at 10:56, Jeffery Russell notifications@github.com wrote:
Sweet! That looks easy to do. All we really need to do is copy in the template game from godot to the activities directory that I already created for Fractionauts and then modify that build script you wrote.
-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/ritjoe/sugarizer-lite/issues/17#issuecomment-619565229
Those who want to use Godot can use Godot, and those who want to use Pixi or whatever use, can use that.
Obviously that leaves fewer people to work on each implementation, but please remember that you can go to those who described the activity for code review and other feedback, and that that sort of collaborative work is also encouraged so long as it's demonstrated here in the issues, and that demonstrated progress is at least as important as having a final product. Your charge is to move us towards an implementation, but no one will be penalized for not being able to carry the project over the finish line alone.
Not sure but I think at that point we'd want separate issues for a Godot implementation and a Pixi implementation.
@zethra I think it would be easier for development in this class to embed the repo into this project rather than doing a linked repository
Yeah, if you can put it in its own subdirectory that's probably separation enough for our immediate purposes.
If that has unfortunate unanticipated side effects there'll be plenty of time to regret it later ;-)
@iclare to follow-up on involving the describers, I'll just note that consulting:
https://github.com/ritjoe/sugarizer-lite/wiki/final-projects-20200414
one sees @ymoullec and @iggyvolz have that task, which was started in
https://github.com/ritjoe/sugarizer-lite/issues/9
so it would be fair to seek input from them as you went along.
Same goes for @jrtechs and @zethra for Godot, just that the benefit of doing so is less accute if there is more than one implementor.
@ritjoe what do you mean when you say " the benefit of doing so is less accute if there is more than one implementor."?
On Sun, Apr 26, 2020 at 10:56:36AM -0700, Jeffery Russell wrote:
@ritjoe what do you mean when you say " the benefit of doing so is less accute if there is more than one implementor."?
If two of you are working with Godot but Ian is the only one working with Pixi (or Canvas API or p5js or whatever) then he'll not have another developer so closely involved to bounce ideas off of, to review PRs, etc. unless he seeks feedback more widely.
(I see I put and extra 'c' in there, it's "acute")
I've been digging around the rabbit hole of Godot the last hour... or two. It's quite amazing how high-level game engines have gotten-- I used Unity for a hot second in high school. I've also done a fair bit of canvas games in high school. However, I'm not really versed in any game engine currently. Fully learning any of these game engines or libraries will probably take at least a week or two to do. But, even within Godot, we have to settle on a language to use.
Although Godot supports a visual programmer, C++, and RUST, I think we should use c# because it is the more "common" programming language.
Few notes:
I installed Godot using steam-- this was very painless. However, that means that I can't run "godot" in the command line so the script @zethra made would have to be done manually for me -- but, is possible.
I'm pretty sure c# is not supported for compiling to wasm, which is required for our use case. I think using gd script will be fine. It very similar to python from what I've seen.
@zethra thanks! Good to know. I'm going to plow through this tutorial today/tomorrow:
https://www.youtube.com/watch?v=KtxPGpUc1Ho
I think that this will make me "dangerous enough" to at least start importing our assets and associating actions when they are clicked on.
Quick update: I booted up godot and imported some of the assets. Right now I'm just working on the main game screen. This is what it looks like:
I'm going to try to get this exported to run in sugarize tonight.
I got everything in our repo right now so we should be good to start doing more serious Godot development. I ran into one quirk. The preview of the game is clipped when ran with the sugar environment to the top left corner. I'm thinking this is CSS or something else. I will investigate this more tomorrow after my PDM final.
Another development thing worth mentioning to everyone working on this: do not check in the Godot export into version control. The binary wasm file is about 20 MB.
I fixed the scaling issue so the entire project is viwable and playable in sugarize. Today I plan on importing more assets and associating some action to clicking on the fuel levels.
@jrtechs @zethra Do you see any tasks I can get started on without blocking you? I'm just getting up to speed with Godot right now.
Hey, all you cool cat and kittens watching this issue and intensely reading my ramble about GODOT and fractionauts! I am pleased to proclaim that this game has all the necessary assets and scenes created and is in a quasi functioning state. Right now when launched you are loaded into the main fractionauts screen and can click on the start button. From there you are sent to the main game scene where you can either click on a button sending you back to the main screen or click on the launch button sending you to the final scene. On the final scene, you can click on a button sending you back to the home page.
Things left to do:
This has been a slow process because I came into this knowing nothing about Godot, however, it has been remarkably easy to pick up and learn.
@jrtechs this looks great! I should finally have more time to work on this now.
@iclare I'm going to look at this again tomorrow. @iclare you can start looking into how we can add text to the scenes for the game. We need to add instructions on the main menu and add text for the fractions above each fuel tank and the spacecraft. Then proceeding from there we need to start working on adding game logic to start dynamically changing the scene for each level. But, for the MVP on Monday, I think it would be a good goal to just have one hardcoded level done.
@zethra @iclare did you make any progress on development? At this point, I think we should wrap it up and start creating some final documentation for this so we can have closure with the class. I already put the running information in the readme file, we just need to now add information on what is functional and plans for future development.
@jrtechs I'm going to be working on the game tonight. If you have anything you haven't pushed, please do.
I created my own branch to work off of zethra/fractionauts-dev
@zethra sounds good. Since I'm starting working full time and put in a bunch of effort up-front, I'm hanging my hat on this project.
This issue is going to be used to discuss the development
Members