Lecture 11
----------
- Anil show and tell
- design plan
- what I've got (it isn't much)
- planning for rest of course
- show and tell (everyone else)
I owe you all grades on your proposals
- you all did pretty well
- will post by next Tuesday
(I have a paper deadline on Thursday night)
Polytopia clone with cooperative multiplayer elements
There's a polytopia wiki if you're more curious
- mobile is free to play single player
Simplified civilization game
- control towns
- towns produce units
- towns grow by harvesting local resources, building structures
- resources are represented using population and stars
- takes place on isometric grid
- each square has land type with optional structure or unit
- only one unit per square, only one structure per square
- gameplay is turn based
- on player turn
- select any tiles to be interacted with
- choose actions for the tile
- choose general actions (technology tree dev)
Graphics look relatively simple ("low polygon") but have lots of nice subtle touches
- not going to try replicating this, at least for a while!
Right now different players can only fight
- peaceful interaction is limited to exchanging technologies
when first meeting and otherwise ignoring each other
Coop multiplayer mechanisms should be simple
- identify encountered player as "ally"
- once an ally, can't attack until marked non-ally
- allies can see each other's territory
- visibility is a big factor
- team victory conditions
- instead of one player to 10,000, 2 to 20,000 combined
for example
- ability to share tech (maybe not all at once)
How to build basic world/mechanics in Godot?
Two basic approaches
- every square is a sprite
- tilemaps
Advantage of many sprites is each can be a different object with its own properties
Advantage of tilemaps is lots of mechanisms for displaying/managing lots of tiles
I decided to try tilemaps
- I found you can layer tilemaps pretty easily
- isometric tilemaps are well supported
- I was already going to have to implement tile logic on my own
- so I just have to maintain my own data structures for
internal game state
But, how do you programmatically control tile maps?
- recognize tiles that have been clicked on
- change tile state programamtically
Most godot documentation/tutorials don't focus on these tasks
- they are there but you have to dig
- don't explain nuances
What I learned
- world_to_map does not respect translations of tiles
- so if you translate, then all your transformations will not work
- you'd have to manually apply the translation to the
mouse clicks before mapping to map
- As you all know, simple misunderstandings/gaps in knowledge can lead to major difficulties
- it is fine to be stumped
Note that most of my game's implementation won't be directly supported by Godot
- it makes the visual/interaction parts really simple to build
(once you figure out how it works)
- but game logic & state will be in regular code
The big danger of working with a game engine is you think in their abstractions rather than your own
- only make fit what should fit
- but spend time thinking about how things will match
Now for the rest of semester
----------------------------
- design principles
- how to do iterative design
- proposal issues
- how to propose things
- how to "be creative" while being focused
- game AI
- relationship to regular AI?
- search, A* traversal
Should we be sharing our projects on github with each other?
- I think I can make a private "team" for us to share with
In so many Godot tutorials, the code is horrific
- they don't follow good software design principles
- hacked to get things to work