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: Leo Wandersleb
Subject: Re: [glob2-devel] Revive Glob2 with a kickstarter
Date: Wed, 27 Aug 2014 20:56:36 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0

Hi Zenfur,

first of all, great you have motivation and time to revive my all time favorite
game on my favorite platform.

I agree it will definitely be a glob3 but I would stay true to its predecessor.
That is:
* no micro management (which is a great point for having in a RTS on a touch
device.)
* toroidal world. Well, I love that aspect of glob2 and would keep it. Makes for
great perfectly symmetric multiplayer maps.

1) I would not mind having it in 3d but would otherwise suggest not to go that
road. Best option is to separate view and controller to allow alternative views.
I did that with my totally failed game FluxForest. At times I had 3 different
views and I could close one and open the other and the game would just pick up
from where I left. And that's another important point: In adroid you always need
a way to serialize the game state. Always. If a call comes in, you have to dump
the game state to disc to be able to resume as else Android will just kick your
game from RAM at times and the user will not like that.

2) Tiles are essential for path finding. Other than that it would be great if
paths wouldn't be ugly as in glob2. Do some research. Use libs. Don't re-invent
the wheel and please don't migrate code from glob2.
One consideration of mine would be to use AndEngine with the Physics Extension
and to allow arbitrary building placement with buildings squeezing between other
buildings, eventually moving them to new positions. Pathfinding is the tricky 
part.

3) As a first goal I would not change anything in the game logic. Same units,
same resources, same buildings. Maybe have all buildings 1x1 or not. Maybe
having round buildings or not. I would keep resources to be blocking to land
units and water for swimmers. Kind of a proven concept ;)

I would probably go for singleplayer first, which makes an AI necessary but to
go without AI and networking instead will be the much more complicated way to go
as people always want to try it alone.

I also oppose the idea to have it quick and short rounds. If you later want
multiplayer, you need to plan with massive delays and probably running the game
on a server. I would love to have some really long rounds where I do adjustments
to my side when I can but with the game running even when I'm not logged in.

One idea I'm pretty sure partially killed glob2 is the synchronized game logic.
It simply isn't feasible to have all wait for one player that has a slow GPU. It
has to be optional to pause the game if players drop with autosavegames.

4) YOG map sharing is cool but keep it for a late late update.

5) Java. Forget C++. Maybe if it makes sense, you will end up using some
pathfinding library that uses the NDK but never ever would I do frontend stuff
in C++. If you have the game ready and people love it and complain that it gets
slow on maps bigger than 50x50, you can still optimize with C++ for just the
bottleneck but don't do preemptive optimizations by going full C for everything
as you will loose many potential coders. I would definitely not jump at it if it
was C++.

6) In Android you have no hard distinction between phones and tablets. You can
require a minimum screen size I guess but I would generally hope to see it on
phones, too.

Regards,

Leo

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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