Picking back up the project

[Zayelion]

DN is trying to move to the mobile space and ditch Flash. I wrote up a connector in nodejs it's going to be changed over into web-sockets once it is functional with BLS's help I was wondering if I could get your help with the project.

[simonlindholm]

I could probably help a bit (especially with this particular code base, and with reviews), but I haven't played YGO for the last couple of years now, so I don't know how involved I would be.

What is the plan, more concretely? Making a web app for mobile? (The UI would certainly need to be rewritten, but I suppose that's a good thing and the code is modular.) Any native Android or iOS things? What's the relation between this and YGOPro?

[Zayelion]

My team is working on a YGOPro browser client we where thinking of doing a manual system also but after looking at the social aspect and figured it would be a bad idea because DN has set an extremely bad precedent that would be very difficult to overturn.

During the sim summit BLS moved the DN client interface to a yet to be specified open licence, and showed the ygopro developers how to connect to DN similar to how your code does. @matteoserva had already figured out much of the protocol and was studying it. The ygopro devs moved a branch of the last closed source variant of their server software to open source, and we talked about information standards currently in development on on of SD's gits.

Compared to some of the other sim owners BLS came off as a good guy, he's not going around DDoSA'n ppl like some other owners and devs, so we agreed to help out if only for the learning experience and so I could grow my staff some with js and css specialist.

Phase 1 is to take your project and move it over into a node-webkit browser. Phase 2 is to get the XYZ and pendulum zones working. Phase 3 is getting BLS to write the websocket connections and move an iteration of the code to the browsers that is functional for at scale testing. Phase 4 is reskinning the thing. Phase 5 is implementing new features. Phase 6 is teaching the userbase how to interact with an open sourced culture.

After YGOPro being out for 2 years users have split into camps and the lines are very well drawn at the user level. After everyone taking a look at everyone else we decided on mutual existence and limited assistance. Specific types of users go to specific sims for specific reasons.

DN only has 3 "devs" and its administration has no true understanding of how developers work they confuse them with moderators and judges. This puts it at a disadvantage and is not fair so we are assisting while also developing out own browser based system.

For both applications no specific OS beyond browser is planned.

This will solve some of DN's funding issues and allow it to purchase better servers and change the ad placement while adding more conventional advertising solutions. This solves some social issues.

[simonlindholm]

Did some reading, and I think I understand what you're saying and how things fit together. Some comments and questions inline:

My team is working on a YGOPro browser client

For mobile, desktop, or both? Come to think of it, same question for this project.

During the sim summit BLS moved the DN client interface to a yet to be specified open licence [..] The ygopro devs moved a branch of the last closed source variant of their server software to open source

That's fantastic!

Compared to some of the other sim owners BLS came off as a good guy, he's not going around DDoSA'n ppl like some other owners and devs, so we agreed to help out if only for the learning experience and so I could grow my staff some with js and css specialist.

So, basically it's a separate project. Will there be any code sharing?

Phase 1 is to take your project and move it over into a node-webkit browser.

Why node-webkit, when the flash-based communicator is already fully working? Does it help with mobile stuff, or...? Similarly, I don't understand where node-webkit comes in for https://github.com/SalvationDevelopment/YGOPro-Support-System. Why not just use a regular website?

Phase 2 is to get the XYZ and pendulum zones working.

Together with understanding and updating for the newest protocol version, which might be most of the work when the UI is not important (I think XYZ was almost working). I guess within the same phase one might also want to implement (with placeholder UI) dueling (not just watching, which is what's supported right now because I ran out of time) and logic for duel states etc.? It seems pretty fundamental to the UI.

Phase 5 is implementing new features.

(deck construction and profiles comes to mind)

This will solve some of DN's funding issues

Huh, it surprises me that the ads they already have aren't enough. I'm not entirely sure what you refer to here.

BTW: the (Google-translated from Swedish, so terrible grammar) design document I followed for this project: http://pastie.org/9490234. The plan was roughly, take DN and fix all personal pet peeves. Might be worth reading through just for inspiration.

[Zayelion]

The YGOPro devs code share the central programming. DN is a completely different beast.

Preference. For SD it gives a web page access to the operating system. TCP, file system, registry. The system will allow the normal YGOPro to function in tandem and be updated for that prefer it. YGOPro requires a file edit before being able to Targeting Windows, Mac, and Linux node-webkit allowed me to code once and in one language.

Didnt realize it wasnt fully functional.

[simonlindholm]

Didnt realize it wasnt fully functional.

Yeah, I somewhat sensed that from what you wrote. I tried to make it clear from the README, but...

So yes, finishing this would be quite a bit of work. It was just a school project, never marketed as a full client, although I don't think duels are that far off.

Preference. For SD it gives a web page access to the operating system.

Hm, ok... I suspect it invalidates some of the advantages of the web (simple to use, no downloads), and spontaneously I think if I needed to do communication between browser and native program I would rather have the latter set up a server running on some obscure port on localhost and make HTTP/websocket requests to it. But I'm certainly not aware of the full story here.

[Zayelion]

Somewhat. The core system of ygopro is downloaded and playable in the 60MB installer, most other installers are 500MB. The launcher downloads the rest over time. It is still a website it is just in the nature of something like SwiftKit. There is an iframe that loads a central website, and then controls that interact with the operating system. Both are downloaded from the web at runtime with a backup version for offline mode included. I'll explain more in detail if you open up a thread on the SD project.

I'll look your code over again and see if I can get it to run when I have free time. I put DN work off till mid September.