glob2-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [glob2-devel] Revive Glob2 with a kickstarter


From: Gregor Fabritius
Subject: Re: [glob2-devel] Revive Glob2 with a kickstarter
Date: Tue, 17 Dec 2013 01:39:17 +0100
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

-----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-----



reply via email to

[Prev in Thread] Current Thread [Next in Thread]