-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello everyone,
I follow this list for a long time, although I've never contributed. However, I'm a freelancing C++/Qt/image processing developer/consultant and glob2 is still one of my favorite kill-an-hour-or-two games. If there is the possibility to contribute to further development, I'd love to try to take the time. On 13/12/15, 10:20, Stéphane Magnenat wrote: > * Qt5/Javascript + works well with both computers and Android + > great Qt API + easy to mix C++ for core algos/Javascript for game > design + Could reuse part of the existing codebase if necessary - > default Javascript maybe not as suited as Python/Scala - more > things to do by hand I agree with these points. I'd like to add that Qt supports iOS since the recent 5.2 release, so there is more platform support for free. If you decide to base development on C++/Qt, I could help in development and/or try to help in answering technological questions. > * the network part is open, not clear how the current system would > work on mobile devices, maybe for that we should run the whole > game on server and only stream what is currently "being seen"? > This brings the question on whether the game should be browser > based actually. This is an open question, I am not really convinced > of that myself. _If_ one would use Qt (at least) for the display part, a browser-based approach would not be the best choice (IMHO). Offloading the display logic to the GPU (if available) works quite well using QML. It also reduces the amount of possible complicated GUI C++ code in favor of more Javascript-based declarative code. This way a developer is forced (in a good way, in this case) to separate UI and core logic very strictly. In case a browser based GUI is requested, one could simply (more or less) exchange the UI logic to be a web server instead of a QML backend. Regarding network communication: I'm not familiar with the way glob2 handles that now. That said, I'd generally suggest communicating state changes for the whole game between clients, maybe managed by a dedicated server. ZeroMQ [1] combined with Google Protocol Buffers [2], for example, has proven well for handling the communication for this kind of task. Regarding mobile devices: To keep the traffic to/from mobile devices a minimum, the approach to stream visible data sounds nice! Regarding implementation this should (again, IMHO) be an instance of client logic running for each device on server side. The display logic could then be split to a display data streaming component (still on server side) and an actual GUI stream receiver component (running on mobile or within browser). > * Keep the same basic game system, but with added dynamics in the > world: - height map world (hence 3D graphics, or mixed 3D > map/bitmap units) - free poses for units (not on a grid) - dynamic > environment, with some rivers, etc. (dams ? ) - meteo? If you intend to have a 3D UI written in some more high level game engine my points for QML above are not valid. Separation of core and UI logic will have its own philosophy then. Personally, I like the simplicity of nicely done 2D graphics. There was a time when I thought about writing a RTS game where units are just different shapes of different colors on a black background, kind of like Defcon [3] did a few years later. You may have noticed that I haven't dived into glob2 code for now. following this thread, I just wanted to add my 2ct, maybe they are helpful. It's great to see that glob2, however on hibernation, is not dead! Best regards, Gregor [1] ZeroMQ: http://zeromq.org/ [2] GPB: https://code.google.com/p/protobuf/ [3] Defcon: http://www.introversion.co.uk/defcon/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKvnTUACgkQBOEA34BJIxoSrgCfT9ttj0rgYtBXwiMyxpd6FUTK tGIAoIATXwXFtfhAMTjsOletGUDBh8NW =RhGC -----END PGP SIGNATURE----- _______________________________________________ glob2-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/glob2-devel
