[Dev] 0.1 "Babylon" Progress Thread

Scroll/Zoom

Oh yeah, that reminds me I forgot to reply to your mention of zooming in another thread. I recall working on several forms of scrolling and zooming, and of trying to get wraparound to work.

With zooming in particular, scroll with with a mouse wheel, pinch zoom on a touchscreen laptop, and pinch zoom on the Mac trackpad all needed different trigger code.

I thought I had scrolling working pretty well, but it's been a while since I've messed with it. It's entirely possible I broke it while working on something else either temporarily intentionally or inadvertently. Oh yeah, I also had touchscreen drag-to-scroll working I think. I'd have to get back into that a bit to re-figure it out.

Fog of War

If visibility is fog of war, it should be trivial to include at least not showing undiscovered tiles. The Civ3 SAV file has what I call "is visible" and "is visible now" values, the latter apparently indicating either culture-based visibility or culture and unit/tower visibility. (Or maybe the latter is actually marking owned tiles...needs a bit more investigation.)

Getting the pretty edges is something I haven't done yet, and enabling "fog peeking" would require a bunch more logic to draw then mostly obscure visible-adjacent tiles. Maybe it's not as hard as I think, but I never previously considered putting in the effort for my purposes. For C7 I'm sure someone will eventually ask about it, and the map will eventually need non-jagged edges.

In short, I expect to have fog of war to a point where it only draws non-spoiling map tiles for (an) arbitrary player(s), but obviously at first we'll have that hard coded to player 1's view.

 

Today I polished the map some more. I simplified the algorithm so that instead of the four cameraTileX/Y & cameraPixelX/Y member variables there is now only a cameraLocation variable which tracks the total offset of the camera from the origin. The cameraTile and cameraPixel vars are computed as needed in RefillMapView. This let me adjust the map to also work in cases where edges don't wrap, which should be easy but wasn't before the simplification. Since I think it's in a good place now I'll merge the repeating map branch into Development soon unless there are any objections.

It's in a good place but the map movement is not yet perfect, there are two things left to do:
1. Clamp scrolling around unwrapped edges. Right now you can still just scroll off the edges. This is easy for the top and left since the boundary is zero but it will require some thought for the bottom and right edges.
2. Keep the map centered on the same tile as the zoom level is changed or the window is resized. Part of the problem here is the Godot camera is still a factor and it moves when the window is resized so we could either recenter the map on the camera or anchor the camera in place and center the map on the window. I prefer the second option.

I agree it's time to add a Tile object. I've also been thinking about factoring out a Map object from Game, that would make the code neater especially once we have multiple map layers. A simple and natural first step would be to convert the game map into a 2D array of Tiles instead of an array of ints (specifying terrain) like it is now. I don't know about the toolbox architecture, I'll have to read up on that, and I'll admit I don't know how the event architecture is supposed to work or even what problem it's supposed to solve. None of this would conflict with what I've been doing with repeated tile maps since the MapView is a step removed from the map itself.

Also, have any of you given any thought to implementing multiplayer? IMO that's the biggest open architectural question. We should plan for that before we start working on the gameplay code because it would be very difficult to patch in after the fact. That's what Firaxis did for Civ 3 and is why its multiplayer is so buggy and crashy.

 

I vaguely recall discussing it. (It may have been in email before this subforum was created...don't recall at the moment.) Of course there is hotseat / play-by-email multiplayer, but I presume you mean online live multiplayer.

Godot *does* have a standalone headless server, but since our game logic is all C#, I think we can just have a C# server.

Beyond that I know we brainstormed a bit, but I don't think there was really a particular direction.

 

Interesting. Does EmitSignal block execution until the signal is handled? Is it possible to make it do that? Because that's what you'd want to do for any UI interaction where the player is asked to make a choice, like if the player captures a city and must decide whether or not to raze it. As I remember from reading WildWeasel's Google doc there were going to be events for gameplay occurrences like that.



About multiplayer, I've thought about it myself a bit and I don't have any better idea than a client/server architecture like you described. I think with any kind of peer-to-peer architecture we'd have a difficult time keeping things synchronized. I wonder if it would be plausible to have all state updates done on the server and broadcast to the clients or if the server would instead broadcast a stream of accepted moves and have the clients update their own states. I don't have a good sense of how much bandwidth the first option would require. The second one would require less bandwidth and be easier to implement though it might be more prone to desyncs.

Easiest thing to do is probably to give every client the complete state. Though one advantage to giving them only the state they can see is that they can't cheat the map visibility by inspecting the program's memory.

Another thing that ocurred to me re: multiplayer is that it would be a good idea to give each game object a unique ID (it need not be any more complicated than a serial number). That solves a potential synchronization problem around object creation/destruction. Like if you ordered that spearman to retreat but the before that order reached the server the spearman was killed and another unit was created with the same ID.

 

For IDs, @WildWeazel has been very particular about object GUIDs for everything, but I haven't yet grokked what that's going to look like. So far I'm trying to design code using interfaces and having IDs like IEquatable so I can use ints for now and swap out to GUIDs when appropriate.

Re: websockets...psst: http long polling. It traverses more networks better. And scales much better if anyone were to ever have a popular multigame server.

Edit: By the way, I'm in a "chasing all the shiny things" mode right now, so I'll probably stay out of Game.cs for a bit. Re: scrolling, I keep forgetting if old Civ3 even has vertical wrap maps available. And I wonder if we want the ability in C7. Probably, as we want to remove limits, but lots of code would have to check and consider vertical wrapping when calculating distances and pathfinding.

Edit 2: @Quintillus when you start rearranging the control nodes, be aware that it's easy to break the input handling. I ran across a comment in the code about that today:

Code:

        // Control node must not be in the way and/or have mouse pass enabled

Fixing it is a matter of reordering the Control nodes. I think the bottom-most one gets the input first?

 

If the controls work, you're good. I added something the other day and literally nothing worked: scrolling, zooming, pushing buttons...and I had to reorder the nodes to fix it.

Websockets are a new (-ish) shiny, but in particular proxies and load balancers tend to block or just not support it. I've only messed with them some with chat programs and for the http API version of cia3. Websocket is a pain in the butt and not really needed in most cases. It connects http and then upgrades the connection and then keeps it open indefinitely, each of which can and often does run into problems.

Http long polling was adequate, seems to be a default fallback for chat programs, and has libraries to make it about easy to use as http/https. Latency is a hugely touted advantage of Websockets, but for the traffic I've seen the few extra ms it saves doesn't really make a difference. And http long polling is still low-latency on the client end because the client is mostly just waiting.

For C7, data up will be player-driven, anyway, not a stream of constant data.

Websockets may have a use in high-reliability environments like same-machine or same-LAN, but my impression so far is not to mess with them unless somehow required over a large network.


I'm not sure I've ever played Civ3 multiplayer online. If you can have more than two human players, then peer-peer sounds problematic. Even if there are good mesh libraries these days–I'm not sure of that, but it sounds like it could be a thing–traversing NATs would seem to be a challenge. Or maybe uPnP has come a long way since I've messed with it. Or maybe I'm still in the stone age with respect to peer-peer networking.

 

Maybe city razing isn't the best example, I was trying to think of a case where you'd run some game logic, ask the player to make a choice, then run more game logic that depends on the choice made. In cases like that it would be easier to block execution of the game logic while waiting for the decision instead of shelving everything and resuming it later. That's how it's done in the original code and it usually makes things simple and easy even though it entangles game logic with UI. Though now that I've thought about it some more, I think it's probably easier overall to do the shelving because in multiplayer the state of the game could change underneath you anyway while you're waiting for the player to make a decision.

I should hope so.

 

Signals are non-blocking, but in an event-driven context we get to decide what gets...well, not blocked, but delayed.

Take for example the open file dialog in the TempTiles scene. A UI button is on the screen, and when it's clicked it sends a signal, and there is a listener that takes that signal and knows to run _on_OpenFile_Pressed() . That function just calls the Popup_() method of a custom file dialog object previously attached to the scene tree during setup. That dialog is mostly stock from Godot, but I think I made it find the Civ 3 location and open there.

That dialog (as provided by Godot) sends a predefined signal, and the tscn file (or a coded line) has a dev-defined listener (Connect()) that knows to run
_on_OpenFileButton_pressed in the proper scene script (as specified). In this case, the string path for the file is passed as part of the signal. And that handler function calls the code needed to load the selected save into the game and switch to the game UI scene.

Nothing is blocked. But neither is anything run until we tell it to, either via _Ready(), an explicit function call, or an event with a listener (a "connected signal" in Godot parlance).

If I wanted to have code calculating pi to infinity at the load screen, all that I described above could happen while it's doing that.

In fact, the C# code we're making has no native entry point. There is no main function. It's a collection of class definitions, and Godot intrinsically calls their constructor when instantiated, and then explicitly calls _Ready() when the object is properly attached to the scene with all its scene-defined children (I think it calls bottom-up, but double check me on that), and our persistent game logic, if any, will be started probably from a ready method.

Nothing happens unless and until we tell it to happen, asynchronously.

 

Alright. It makes sense that signals are non-blocking otherwise they'd be basically the same thing as a function call, though I guess you might want to call a function on a different thread.

Do you guys think it's worth it to block game logic while waiting for the player to respond to popups? The reasons I can think of to do that are (1) it makes the code simpler in some cases and (2) it's what the original Civ 3 does so we'd be closer to an exact reproduction. For example, in the original when you get the "city finished production" popup, you can zoom to the city then scroll to other cities that haven't had their interturn update run yet and change things around. There's also a serious exploit you can do by going into the science advisor screen through the "tech researched" popup then flipping over to domestic and changing your tax slider settings. I don't think it's a big loss if we leave behind the game's exploits.



Today I pulled the map viewer code out of the Game class into its own class called MapView. MapView is a Node2D that gets added to the scene tree like the old TileMap of the same name. Sometime soon-ish I'd like to add the concept of map layers so we can draw more things, like units especially. I'm thinking there will be two kinds of layers: ones that are TileMaps (terrain, civ borders, resources, pollution?) and others that are loose sprites (units, cities?). But first I'm looking into more basic things like figuring out which tile is at a certain screen location so we can click on tiles.

By the way @Puppeteer, I changed how you had the rows staggered in TerrainAsTileMap so x starts at y%2 instead of 1-y%2. This way there is a tile at (0, 0) like in the original game. Is there some reason you did it that way in the first place?

 

That's on purpose. The graphics tiles are offset from the real tile. Each real coordinate is made up of four corners of graphic tiles at the not-real coordinates. If you load a game file in TempTile with y % 2 instead of 1-y%2 you'll see it's really messed up.

And actually I'm not sure if the graphic should be on the left or right. We'll find that out.

What's more confusing is that the overlay terrain, resources, cities, and such are centered (-ish) on the true coordinate. I think rivers and flood plains are off-center like the base terrain. Not sure offhand about roads and railroads.

But I kind of have in mind drawing them at their true coordinates but just having those layers' Node2d shifted 64 pixels instead of changing coordinate systems.

I'm really hoping a native future format won't have these issues.

 

I don't quite understand. I know the tiles are not centered on their nominal locations, i.e. the tile at (x, y) is a diamond centered on (x+1, y+1), but the tile data should still be stored according to the tiles' locations. The way you had it set up there was no tile at (0, 0), in other words the value of Map[0,0] was never set. So I'm not sure how you could load a game properly since the coordinates wouldn't match. BTW I also made the corresponding change in the viewer so the randomly generated maps still look proper.

 

Ok, but load a real game map from a real civ 3 game into TempTiles.tscn under the UtilScenes directory. (Open the scene in Godot and then use the run scene–not project–button or control-R.) If not laid out as I put them, it wouldn't look right.

Oh, and I just realized that a Node2D shift won't work because each row shifts different directions. . Oops.

I'll try it and attach a screenshot to this post.

Edit: Ok, maybe I'm confused. The TempTiles script doesn't have the 1-y%2 pattern, and LegacyMap just uses the file id and tile index. So you're right. I guess when I made the display code that was in Game.cs I had remembered incorrectly.

Edit 2: Now I'm wondering if the current random terrain generation is also flawed. Now that I'm looking at it critically, there is a definite skew from the top right to bottom left that shouldn't be in the random noise. I don't mean from what you did; I think it was like that before.

 

@Flintlock , your scroll wrap code is in Development now, right?

I just cleaned up branches–I'm pretty darn sure I only axed the ones that were already merged (0 ahead of Development), but now I'm panicking a bit because my map isn't trying to wrap.

(If I did horribly screw something up, it's not gone; I'd just have to go digging through the raw git data to find the reference.)

Edit: Ok, I found the reference still in my local repo and re-added the branch to GitHub. It is also in Development commit history, but I can't find the mapWrap bools in the head code right now. Trying to figure out where they went.

Moar edit: Ah, I see now; it's refactored and segregated. All is well.

By the way, since I've switched back to the Godot noise for the in-Game.cs generator, the tiles aren't wrapped right now. I figure on fleshing out the generator in GameData and map loading and generation doesn't really belong in the main Godot project.

 

I had left wrapping turned off because I liked being able to zoom out and see the whole map, it's more convenient for what I'm doing right now. As I guess you've already figured out, the MapView is now a separate class that receives the wrapping settings when it's constructed.