Hello, Leo:
> 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. > 2014-08-28 18:31 GMT+02:00 Bradley Arsenault < [email protected]>: > > Glob2 isn't that bad on a small screen. Unlike most RTS, your not > selecting > > specific units, your selecting buildings, which are fairly large. > > Tablet is certainly better then a phone. Ability to zoom in and out would > also be required > > ------ Yeah, I thought so. But it will be easier for me to focus on easier task which is develop for tablets and then wonder how I can tune it for lower resolutions as well. > On Thu, Aug 28, 2014 at 5:53 PM, Stéphane Magnenat <[email protected]> > wrote: > >> On 27.08.2014 22:10, Shawn Anderson wrote: >> >> I seem to remember Glob2 to be quite CPU intensive. Will it run >> adequately on tablets and phones? > > > Today's tables and phones are far more powerful than the computers we had > when we started Glob2. For souvenir, the initial target and development > platform was a 60 MHz SPARC workstation with 16 MB of RAM. Compared that to > a 2 GHz 4 Core phone with 2 GB of RAM ;-) Exactly, that shouldn't be a problem. 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. > Of course, all good main aspects I hope to rebuild to feel the same as in old glob2. These two are foundament ;-) (The latter may be a little troublesome for zooming feature) > 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. > I see many benefits of 3d approach, but also many challenges and thus I'll probably keep it 2d. Yeah, separating view and controller and game logic in order to allow easy swaps would be awesome. Good point, didn't think of that. That proves that saving and pausing are neccesary and important features. > 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. > Yeah, there's a lot of research that I have to do in the first place. But that's a shame that I can't use glob2 code as Leo and Bradley say. I was hoping that I will be able to help myself a lot with having something working to base on. Well, if you tell me that I have to rebuild application that in effect works like globulation, but doesn't use the same solutions as globulation as they were bad approach to the problem, then now I'm kinda stuck. I'm stuck as this a little too much to ask from me... Well at least that's what I think now. Maybe I'll get enlightened doing the research. 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 ;) > Yeah, little steps, something simple and working to start with and expand. > 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. > That's my thinking. If I get far enough to have something I can play what looks like original globulation that will be a great success. AI will be next neccessary step. > 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. > What do you mean? How *massive* the massive delays? Do you simply mean high ping problems with synchronisation? About multiplayer do you suggest peer to peer + some kind of waiting to keep everyone in sync? Or maybe make one host of the game and neccesity to inform him about your actions and keep host as a sync source. Well, in theory it could be probably one server for everybody... but I'd like to keep some offline multiplayer bluetooth playing possibility. Whichever solution I choose, it's best to make my mind early as it will have big influence in developping even single player. Am I right? 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. > What would you suggest then? You mean that synchronized game logic is harmful for this multiplayer design or just this particular implementation which was in glob2? I'll have to research how other multiplayer RTSes solve this problem. > 4) YOG map sharing is cool but keep it for a late late update. > Sure! Most of things have to be done before that. But it's neccesary imo as it was one major feature which kept glob2 alive for so long ;-) > 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++. > Crap, I was afraid of such answer. I guess the time has come for me to start a personal struggle with java. Yet another obstacle :/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. Thanks for encouragement and good advices. Regards, Zenfur
_______________________________________________ glob2-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/glob2-devel
