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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ glob2-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/glob2-devel
