WildWeazel
Carthago Creanda Est
We've been at this long enough that it's time for a proper status update. Dev Diary is a term for an informal technical report on work in progress. It's a pretty common practice among open source, indie, and even some commercial projects these days. Since we admittedly don't have much to show yet, this one will be pretty brief.
a logo makes it official
@Puppeteer, @Quintillus, and I have been putting together this prototype to demonstrate some of the core technical features in Godot. The prototype is a place for us to experiment with the engine before committing to a proper solution. It's called C7, for Civfanatics Creation & Customization Community's Civ3 Conquests Clone. That's the codename for the whole new game, or "Build It" option. We created a (temporarily) private GitHub team and repository in which to collaborate, so I can't directly link to the code here but if you have a GitHub account I'll give you access.
Here's the current state of things. The demo finds Civ3 and loads some PCX files. First the title screen is shown with a button to start a game. Click the button to proceed to the next "scene" which is a random map of correctly placed terrain tiles. There's another button to end your turn. Click this one, and you'll see the console output cycle through some steps. The button is disabled for 2 seconds while the computer "takes a turn" before control is returned to you.
arguably a "turn based game"
And here's me, after patching together some code samples I found online to make it work:
come at me, Jon Skeet
Now this doesn't look like much, and it's really not, but there's a fair amount going on here beyond printing a few lines:
Instead of a linear "game loop" there's a script tracking the turn state (game start, player begin, player end, computer start, computer end...) and raising events - signals that other code can listen for - whenever the state changes.
The humble turn count is not just a loop index, in fact it doesn't know anything about the main script. It's an example of a component that reacts to an event, in this case this case the start of a turn, by incrementing and printing its counter. In a real game this component would also calculate the new date and pass both back to the UI, while other components would react to the same event by generating an autosave, recalculating scores, and so on.
These components can get access to each other via a component manager to set up these event listeners and pull state data as needed.
That's the gist of the planned architecture: lots of small, independent components publishing and subscribing to each others' events, stored in the manager and orchestrated by the game state cycle.
I dunno, blockchain or something
So far we've opted to do all of this in code, and that in C#, because it's what we're most familiar with. Godot lets you do quite a bit directly in the editor, but it remains to be seen whether that's useful since this will be a very data-driven and customizable game. It also provides its own scripting language GDScript, similar to Python, with even more engine support but a bit less powerful as a language.
So where do we go from here? It's a bit open ended since we're still exploring the engine, but there are several more features I'd like to try out in this prototype:
a logo makes it official
@Puppeteer, @Quintillus, and I have been putting together this prototype to demonstrate some of the core technical features in Godot. The prototype is a place for us to experiment with the engine before committing to a proper solution. It's called C7, for Civfanatics Creation & Customization Community's Civ3 Conquests Clone. That's the codename for the whole new game, or "Build It" option. We created a (temporarily) private GitHub team and repository in which to collaborate, so I can't directly link to the code here but if you have a GitHub account I'll give you access.
Here's the current state of things. The demo finds Civ3 and loads some PCX files. First the title screen is shown with a button to start a game. Click the button to proceed to the next "scene" which is a random map of correctly placed terrain tiles. There's another button to end your turn. Click this one, and you'll see the console output cycle through some steps. The button is disabled for 2 seconds while the computer "takes a turn" before control is returned to you.
arguably a "turn based game"
And here's me, after patching together some code samples I found online to make it work:
come at me, Jon Skeet
Now this doesn't look like much, and it's really not, but there's a fair amount going on here beyond printing a few lines:
Instead of a linear "game loop" there's a script tracking the turn state (game start, player begin, player end, computer start, computer end...) and raising events - signals that other code can listen for - whenever the state changes.
The humble turn count is not just a loop index, in fact it doesn't know anything about the main script. It's an example of a component that reacts to an event, in this case this case the start of a turn, by incrementing and printing its counter. In a real game this component would also calculate the new date and pass both back to the UI, while other components would react to the same event by generating an autosave, recalculating scores, and so on.
These components can get access to each other via a component manager to set up these event listeners and pull state data as needed.
That's the gist of the planned architecture: lots of small, independent components publishing and subscribing to each others' events, stored in the manager and orchestrated by the game state cycle.
I dunno, blockchain or something
So far we've opted to do all of this in code, and that in C#, because it's what we're most familiar with. Godot lets you do quite a bit directly in the editor, but it remains to be seen whether that's useful since this will be a very data-driven and customizable game. It also provides its own scripting language GDScript, similar to Python, with even more engine support but a bit less powerful as a language.
So where do we go from here? It's a bit open ended since we're still exploring the engine, but there are several more features I'd like to try out in this prototype:
- Add a couple of units for each player to move once per turn
- Play unit animations with civ colors
- Integrate at least some of Puppeteer's SimpleGame logic
- Some kind of game setting loaded from an external file (e.g. map size, unit stats)
- Figure out how to visually scroll and wrap the map
- A simple "mod script" loaded during the game
- Distribute a compiled runnable version
"C7"
.
