Game Engines 2021W Lecture 11

From Soma-notes
Jump to navigation Jump to search
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