-
Notifications
You must be signed in to change notification settings - Fork 0
Design Decisions
- Both are free for up to 1,000,000 requests/month, we won't exceed this
- Easy to use, setup and learning curve is minimal for a serverless architecture
- Fully integrated with AWS environment, can combine with other AWS services to make a full web app
- Lambda + AWS API Gateway means we can have an external API made out of Lambda functions with no direct server architecture
- Lambda integrates seamlessly with AWS storage options like DynamoDB and S3, allowing easy-to-manage persistence
- Serverless, meaning we don't have to manage provisioning or writing a web server
- Our game is turn-based, so there isn't a hard response time requirement, we can do HTTP calls with API Gateway and Lambda
- We can manage all AWS resources from the AWS console, allowing easy configuration and management of all services
- Effective separation of concerns into Lambda functions, each independent and stateless, logically grouped (Map, Lobby, Game)
- Given a more complex server design, we could face latency issues if we make calls interdependent
- Lambda calls other Lambda, cost of HTTP calls increases
- Not as portable, tied to AWS
- Implementation details hidden by AWS (IAM Access Controls, etc.)
- The only reason we talked about using Go was because we heard about the ease of setup
- AWS Lambda is also easy to set up, and uses familiar languages (Python/C#)
- If Lambda supported Go, we could have used it, but in the end it did not fit our needs
Looking at the numerous benefits to AWS serverless design, it makes sense to go with this option. We had already decided to use AWS for persistence and hosting our website, so using the other resources available in the free tier of AWS only benefits us due to the great integration of AWS services. Our project is a game, meaning a lot of the work is done client-side, with the server essentially doing validation to make sure the client state is in sync. This allows us to have a thin, stateless backend that operates on stored state, which is a perfect use case for Lambda. Within the scope of this project, we do not need to worry as much about our apps future, so not being tied to AWS and possible future complexity issues are not a concern.
Due to the above reasons, we decided to build our backend with API Gateway and Lambda.
- Due to poor testing support in Unreal (as discovered by Nicole and Jill), we are switching to using Unity as our game engine. This justifies our decision to create a lean server for the backend.
- The map needs to be easy to serialize back and forth
- The map should also be fast to load
- Each turn/map should not have special information about if it is the first turn of a map vs any subset from that. I.e. we don’t want to treat the initial map any differently than any other map. The map controller only needs to know how many turns are left in the game for the end condition stuff. This is so we can keep most of the code the same for loading in and for looking at stored games and all that jazz.
- We need to have explicit states to make loading in turns / testing out turns easy. (What we have right now might work)
- Recall that we want to be able to preview a turn (and potentially multiple future fake turns) before you commit to it. Our model should be able to accommodate that
- We need for ALL the logic (looking at your prefab data values) to be in the C# code so testing and the game server are easy.
In order to do this we will need to make sure all the ideas about tiles and maps and storage are all working together.
A tile remains basically the same as we have right now. (We do need to talk about what exact value we are going to put in here, but that’s later) The main change to tiles themselves is that they would get their views managed at the manager level and that we would be hot swapping values in and out of them.
The hot swapping may not be necessary, but getting tiles to control their tileset on their own would mean that we would no longer need prefabs.
At the tile controller level we would have an explicit concept of a second level to a tile. This could be occupied by pigeons, or walls, or whatever we want. Pigeons can then “live” in the tile controller and might have a pointer to their current tilecontroller, in addition to living in a pigeon array in the map. Then the pigeons are called from the map to take their pigeony turn, and they do their thing.
We probably want to make sure that the managers aren’t getting much game logic, looking at you map manager.
A tilecontroller would be able to be constructed directly from a json object and would be able to make it’s own jsonobject. And the JSON map would have a 2d array for these tilecontroller json objects.
I think we would benefit from making the up and down ticks that already exist in our game states more pronounced as we add things that will need to happen at very specific intervals.
Recall that we want to be able to preview a turn (and potentially multiple future fake turns) before you commit to it. Our model should be able to accommodate that
Side note: I did decide not to do a ridiculous sigmund function for burning heat even though I thought it would be cool.
How do we serialize maps Tilecontrollers should know everything that is on them Prefabs are ok
-
Simultaneous turns that resolve deterministically (i.e. no random elements)
-
Safe areas that you can herd the pigeons to in order to save them (probably in the center of the map, and more than one)
-
Deterministic pidgeon movement (i.e. run away from fire, possibly smart enough to path around a corner, possibly not)
-
Limited items (each level would give you say three lighters to use as BadGuy and you may only use those lighters to influence the match)
-
Spreading fire that will eventually burn everything and provide a natural timer to the game. (so if nobody does anything bad guys will always win)
In the simplest version of this game, all levels would be GoodGuy against BadGuy (more on this later) with objectives as described below.
-
BadGuy: Burn enough pigeons to win (amount specified by the level) by using some of your items (x1 per turn) to burn the pigeons.
-
GoodGuy: Herd the pigeons to safety (by using some of your items [x1 per turn] or by leading individual pigeons), so that you save enough pigeons to win (amount specified by the level).
-
GoodGuy vs GoodGuy. Where each good guy is trying to save their pigeons before the other. (may lure the other’s pigeons to their deaths)
-
BadGuy vs BadGuy. Burn the enemy’s pigeons before they burn yours
-
More player items (i.e. any that aren’t lighters)
-
Player powers, (items with no use cap, but cooldowns)
-
More map elements, exploding barrels of oil
-
Single player puzzle levels where you have to save pigeons by using their fear of fire
-
Single player puzzle levels where you have to guide pigeons through difficult levels
-
(Trigger Warning) lol Single player fun fun burn time where you traumatize Caden
-
Making a vegan mode where it’s water instead of fire and it’s pigeon robots with exposed circuitry
The gameplay is going to be different for the two roles, which sounds like fun
Everything would be deterministic, so that players can plan out a turn and play it ahead of time (if you aren’t sure how that works, look up frozen synapse, or rock paper scissors)
Most of the gameplay elements can be controlled from the level editor which gives us control, but prevents us from hard coding things in and lets us iterate on gameplay via map design easily. (And means that if we ever release this to the wild with good level creators it could be a good game even if WE never make any good levels)
The game engine selection has switched from Unreal to Unity due to there being poorly documented unity tests/test support for Unreal.
- Comparison between Unity and Unreal in this article:
https://create3dgames.wordpress.com/2015/09/07/unity-5-vs-unreal-engine-4/
- Uses C# or Javascript
- Free and Premium versions
- Premium is mostly analytics
- Has a lot of GUI stuff to circumvent writing scripts
- Has an awesome asset store full of free assets (scripts, tools, art, etc.)
- Windows PC, Mac OS X, Linux, Web Player, WebGL, VR(including Hololens), SteamOS, iOS, Android, Windows Phone 8, Tizen, Android TV and Samsung SMART TV, as well as Xbox One & 360, PS4, Playstation Vita, and Wii U
- Fairly lightweight to run, good for 2D games
- Uses C++ (Game companies mostly want C++ experience)
- Completely free as long as you make < $3000 (and also has School/University options), but no functionality is gated behind a paywall
- https://www.unrealengine.com/education
- Has a node based scripting GUI if you choose to use it
- Has an asset store but apparently not as good as Unity
- Really good documentation
- Windows PC, Mac OS X, iOS, Android, VR, Linux, SteamOS, HTML5, Xbox One, and PS4.
- Very heavy-duty engine, might be too big for our use case
- Might have a hard time running on everyone’s computers
- C++
- Integrated with AWS
- Too big of an engine for our use case
- Just write what we need, no unnecessary extra features
- A lot of companies use Unity/Unreal so having experience with one of them might be a cool thing to have on a resume
- I think Caden’s point of potential employers wanting C++ for game stuff is worth considering
2 Game Modes: Gameplay and Game Maker
- Single Player
- Multiplayer (Max of 2 players right now)
- ?Add another level of option for cooperative vs. PvP?
Set the layout of the level:
- Flammable objects
- Items
- Start/end positions
- Player spawn points
- Pigeon spawn points Set win conditions (locations?) for the map
- This can determine if the game mode is Co-op vs. PvP Set search tags for the level/map
Change the core game logic (as defined above; deterministic, simultaneous turns)
- Think Mario Maker, not SC2 level editor
- Connects to the server to browse created singleplayer games, as well as multiplayer games, but with AI bots as the other players
- Connects to a matchmaking service that sets you up with another player(s) to play on multiplayer maps
©WhyNot 2017