|
| 1 | +Getting Started |
| 2 | + |
| 3 | +New to Game Foundry Studio? Start here. |
| 4 | + |
| 5 | +Learn the fundamentals of building games, creating projects, understanding the creator workflow, and turning ideas into playable experiences. These videos provide the foundation for everything else in Game Foundry Studio. |
| 6 | + |
| 7 | +Build your first game. Learn the tools. Start creating. |
| 8 | + |
| 9 | +Tool Tutorials |
| 10 | + |
| 11 | +Step-by-step walkthroughs of Game Foundry Studio tools. |
| 12 | + |
| 13 | +Explore Project Workspace, Game Design, Assets, Objects, Controls, Events, Publishing, and more. Learn how each tool works, how they connect together, and how to use them effectively in your game projects. |
| 14 | + |
| 15 | +Master the tools that power your games. |
| 16 | + |
| 17 | +Game Design |
| 18 | + |
| 19 | +Learn the art and science of game design. |
| 20 | + |
| 21 | +Discover gameplay mechanics, level design, player engagement, balancing, progression systems, scoring, game loops, and design best practices. Whether you're building an arcade classic or an original game concept, great design starts here. |
| 22 | + |
| 23 | +Design games players love to play. |
| 24 | + |
| 25 | +Asset Creation |
| 26 | + |
| 27 | +Create the visuals, audio, and content that bring your games to life. |
| 28 | + |
| 29 | +Learn pixel art, sprites, animations, sound effects, music, environments, characters, and visual storytelling. Build assets that make your games unique and memorable. |
| 30 | + |
| 31 | +Create assets. Create worlds. |
| 32 | + |
| 33 | +Dev Logs |
| 34 | + |
| 35 | +Follow the development journey of Game Foundry Studio. |
| 36 | + |
| 37 | +See new features, upcoming tools, design decisions, challenges, milestones, and behind-the-scenes development updates. Watch the platform evolve from concept to creator ecosystem. |
| 38 | + |
| 39 | +Building in public, one feature at a time. |
| 40 | + |
| 41 | +King of the Iceberg |
| 42 | + |
| 43 | +Follow the creation of King of the Iceberg from idea to release. |
| 44 | + |
| 45 | +Watch gameplay development, mechanics design, balancing, level creation, art updates, testing, and feature implementation. This playlist showcases how a complete game is built using Game Foundry Studio. |
| 46 | + |
| 47 | +Build. Test. Improve. Play. |
| 48 | + |
| 49 | +Community Creations |
| 50 | + |
| 51 | +Discover games, assets, projects, and creations from the Game Foundry Studio community. |
| 52 | + |
| 53 | +Featuring creator spotlights, project showcases, tutorials, challenges, and innovative ideas from builders around the world. |
| 54 | + |
| 55 | +Create. Share. Inspire. |
| 56 | + |
| 57 | +Channel Home Message |
| 58 | + |
| 59 | +Use this as the overall channel positioning: |
| 60 | + |
| 61 | +Build Games. |
| 62 | + |
| 63 | +Create Assets. |
| 64 | + |
| 65 | +Learn Game Development. |
| 66 | + |
| 67 | +Share With Others. |
| 68 | + |
| 69 | +Welcome to Game Foundry Studio — a creator platform designed to help anyone turn ideas into playable games. Whether you're building your first arcade game or creating an entire game world, you'll find the tools, tutorials, inspiration, and community to help bring your vision to life. |
| 70 | + |
| 71 | +Build. Play. Share. |
| 72 | + |
| 73 | +This gives visitors an immediate understanding of what the channel is about within a few seconds of arriving. |
| 74 | + |
| 75 | +----------------------------------------------------------------- |
| 76 | + |
| 77 | +I agree completely. |
| 78 | + |
| 79 | +For Game Foundry Studio, I would keep **all deployment validation assets under `docs_build/`** because: |
| 80 | + |
| 81 | +* Never ships to UAT/Prod bundles. |
| 82 | +* Clearly separated from runtime code. |
| 83 | +* Keeps deployment verification as an engineering process, not a product feature. |
| 84 | +* Easier to archive historical deployment results. |
| 85 | +* Easier to compare UAT vs Prod deployment runs. |
| 86 | + |
| 87 | +I'd structure it like: |
| 88 | + |
| 89 | +```text |
| 90 | +docs_build/ |
| 91 | +└── deployment/ |
| 92 | + ├── packages/ |
| 93 | + │ ├── dev/ |
| 94 | + │ ├── uat/ |
| 95 | + │ └── prod/ |
| 96 | + │ |
| 97 | + ├── scripts/ |
| 98 | + │ ├── package-dev.ps1 |
| 99 | + │ ├── package-uat.ps1 |
| 100 | + │ ├── package-prod.ps1 |
| 101 | + │ ├── deploy-uat.ps1 |
| 102 | + │ ├── deploy-prod.ps1 |
| 103 | + │ ├── verify-uat.ps1 |
| 104 | + │ └── verify-prod.ps1 |
| 105 | + │ |
| 106 | + ├── db/ |
| 107 | + │ ├── migrations/ |
| 108 | + │ ├── seeds/ |
| 109 | + │ ├── rollbacks/ |
| 110 | + │ └── validation/ |
| 111 | + │ |
| 112 | + ├── baselines/ |
| 113 | + │ ├── required-routes.json |
| 114 | + │ ├── required-labels.json |
| 115 | + │ ├── required-tools.json |
| 116 | + │ └── db-contracts.json |
| 117 | + │ |
| 118 | + ├── playwright/ |
| 119 | + │ ├── routes.smoke.spec.mjs |
| 120 | + │ ├── assets.smoke.spec.mjs |
| 121 | + │ ├── controls.smoke.spec.mjs |
| 122 | + │ └── account.smoke.spec.mjs |
| 123 | + │ |
| 124 | + └── manifests/ |
| 125 | + ├── uat-deployment-manifest.json |
| 126 | + └── prod-deployment-manifest.json |
| 127 | + |
| 128 | +docs_build/ |
| 129 | +└── reports/ |
| 130 | + └── deployments/ |
| 131 | + ├── uat/ |
| 132 | + └── prod/ |
| 133 | +``` |
| 134 | + |
| 135 | +The part I think you're missing is a **deployment contract**. |
| 136 | + |
| 137 | +Example: |
| 138 | + |
| 139 | +```json |
| 140 | +{ |
| 141 | + "requiredRoutes": [ |
| 142 | + "/", |
| 143 | + "/toolbox/", |
| 144 | + "/toolbox/game-workspace/", |
| 145 | + "/toolbox/game-journey/", |
| 146 | + "/toolbox/controls/", |
| 147 | + "/account/user-controls.html" |
| 148 | + ] |
| 149 | +} |
| 150 | +``` |
| 151 | + |
| 152 | +Then the validation scripts don't hardcode anything. |
| 153 | + |
| 154 | +They read: |
| 155 | + |
| 156 | +```text |
| 157 | +docs_build/deployment/baselines/ |
| 158 | +``` |
| 159 | + |
| 160 | +and verify: |
| 161 | + |
| 162 | +* routes exist |
| 163 | +* labels exist |
| 164 | +* tools exist |
| 165 | +* pages exist |
| 166 | +* no console errors |
| 167 | +* no missing assets |
| 168 | + |
| 169 | +For Game Foundry Studio specifically, I'd eventually grow this into: |
| 170 | + |
| 171 | +```text |
| 172 | +Level 1 - Infrastructure |
| 173 | +``` |
| 174 | + |
| 175 | +* Site responds |
| 176 | +* SSL valid |
| 177 | +* Health endpoint valid |
| 178 | + |
| 179 | +```text |
| 180 | +Level 2 - Navigation |
| 181 | +``` |
| 182 | + |
| 183 | +* Header |
| 184 | +* Footer |
| 185 | +* Toolbox |
| 186 | +* Account |
| 187 | + |
| 188 | +```text |
| 189 | +Level 3 - Tool Validation |
| 190 | +``` |
| 191 | + |
| 192 | +* Every Beta/Complete tool opens |
| 193 | + |
| 194 | +```text |
| 195 | +Level 4 - Creator Workflow |
| 196 | +``` |
| 197 | + |
| 198 | +* Game Workspace |
| 199 | +* Game Design |
| 200 | +* Controls |
| 201 | +* Assets |
| 202 | +* Publish |
| 203 | + |
| 204 | +```text |
| 205 | +Level 5 - Regression |
| 206 | +``` |
| 207 | + |
| 208 | +* No removed routes |
| 209 | +* No missing tools |
| 210 | +* No missing labels |
| 211 | +* No JS errors |
| 212 | + |
| 213 | +```text |
| 214 | +Level 6 - Release Gate |
| 215 | +``` |
| 216 | + |
| 217 | +Generate: |
| 218 | + |
| 219 | +```text |
| 220 | +docs_build/reports/deployments/uat/2026-06-11/ |
| 221 | +docs_build/reports/deployments/prod/2026-06-11/ |
| 222 | +``` |
| 223 | + |
| 224 | +with: |
| 225 | + |
| 226 | +* PASS |
| 227 | +* FAIL |
| 228 | +* WARN |
| 229 | +* screenshots |
| 230 | +* console logs |
| 231 | +* network failures |
| 232 | + |
| 233 | +Then before promoting: |
| 234 | + |
| 235 | +```text |
| 236 | +DEV |
| 237 | + ↓ |
| 238 | +UAT Validation |
| 239 | + ↓ |
| 240 | +PROMOTE |
| 241 | + ↓ |
| 242 | +PROD Validation |
| 243 | + ↓ |
| 244 | +RELEASE |
| 245 | +``` |
| 246 | + |
| 247 | +Everything lives under `docs_build/`, nothing deploys to production, and deployment validation becomes a first-class engineering process rather than runtime code. |
| 248 | + |
| 249 | +--------------------------------------------------------------------------------- |
| 250 | +I’d keep actual generated deployment bundles out of long-term source unless you intentionally archive them. Use: |
| 251 | + |
| 252 | +docs_build/deployment/packages/ |
| 253 | + |
| 254 | +for local generated output, but make it cleanable. |
| 255 | + |
| 256 | +DB updates fit here: |
| 257 | + |
| 258 | +docs_build/deployment/db/migrations/ |
| 259 | +docs_build/deployment/db/seeds/ |
| 260 | +docs_build/deployment/db/rollbacks/ |
| 261 | +docs_build/deployment/db/validation/ |
| 262 | + |
| 263 | +The flow becomes: |
| 264 | + |
| 265 | +package → deploy → migrate DB → seed if needed → validate DB → run smoke tests → write report |
| 266 | + |
| 267 | +Best rule: |
| 268 | + |
| 269 | +Runtime app code lives outside docs_build/. Deployment instructions, packages, scripts, migrations, validation contracts, and reports live inside docs_build/ |
0 commit comments