\nCE#9 Developer’s Guide

\"\" — Combat Engine #9— Swashbuckler’s Swordplay™

This guide has two sections:

\nDesign Overview Topics — holds the ideas and “rationale” for this game’s current construction.
\nLayouts & Event Sheets — list the same information in greater detail as it appears in the event sheets’ conditions and actions.

",{"_728":729,"_43":44,"_47":48,"_45":46,"_65":66,"_730":731,"_922":726},"previewContent","

\n \n
- \nPreface\n
  - \nDistribution Permission\n
  - \nForewords\n
  - \nDisclosures\n
  - \nDisclaimer\n
  - \nWorkbook Content\n
    - \n> For Patrons from Amazon and other Book Distributors\n
    - \n> About this Workbook\n
    - \n> How to Read & Use this workbook:\n
    - \n> Viewing the eBook:\n
    - \n> External Links\n
    - \n> References Used\n
    \n
  - \nYour newly obtained skills …\n
  - \nMore Resources\n
  - \nProgramming Courses\n
  \n
\n
\nPart I — Concept & Design\n
- \n1 “Code-less” Game Design\n
  - \n1.1 Game Genres Defined\n
  - \n1.2 Demand for Abstract Games\n
  - \n1.3 Game Delivery Modes\n
    - \n> Mobile “In Apps Purchases” (IAP) ROI\n
    \n
  - \n1.4 Game Tools & Generators\n
    - \n> The Digital Ludeme Project\n
    - \n> Ludii General Game System\n
    \n
  \n
- \n2 Combat Engine Designs\n
  - \n2.1 Engine Considerations\n
    - \n> Determining Successful “Hits”\n
    - \n> Determining Inflicted Damage\n
    - \n> Combination Experiments\n
    - \n> “Now What!” — Answering Our Question #3\n
    - \n> Summary\n
    \n
  - \n2.2 So, Give Me Some Space …\n
    - \n> Deeper Dive: Melee Weapons\n
    - \n> Deeper Dive: Ranged Weapons\n
    \n
  - \n2.3 Rules of Engagement: Take 5 paces, turn and …\n
  - \n2.4 Yo bro, give me some skin …\n
    - \n> Creating an Avatar’s Visuals\n
    - \n> Creating an Avatar’s metadata\n
    \n
  - \n2.5 Been there … done that …\n
  - \n2.6 Finite State Machines (FSM)\n
    - \n> FSM Resolving Combat Outcomes\n
    - \n> FSM Resolving AI behaviors\n
    \n
  - \n2.7 Recursive World Feedback\n
    - \n> Probability Data Tables\n
    \n
  \n
- \n3 Project Management Overview\n
  - \n3.1 “Loose lips sink ships” … and revenues!\n
  - \n3.2 Game Recipe™ just add Artwork, stir, & season to taste!\n
    - \n> Conflict Resolution & Victory\n
    - \n> Deeper Dive: Developer’s Right or Left-handed Bias?\n
    \n
  - \n3.3 Development:\n
    - \n> Step #1: Understanding “Human Limitations” & Requirements\n
    - \n> Step #2: The “Elevator Speech” & Description\n
    \n
  - \n3.4 Design:\n
    - \n> Deeper Dive: Putting Background Stories in the Wrong Place\n
    \n
  - \n3.5 Construct’s “Code-less” Encoding\n
    - \n> Deeper Dive: Creating Display Mechanisms — a 4-Step method\n
    \n
  \n
- \n4 Part I: Conclusion\n
\n
\nPart II: Starting a C2 Production\n
- \n5 C2 “Combat Engine” Project\n
  - \n5.1 About Your Project\n
  - \n5.2 Project Settings:\n
  - \n5.3 Configuration Settings\n
  - \n5.4 Design Considerations: CMS, PWA, or SWPA?!\n
    - \n> Creating a C2 SWPA Game Version?\n
    - \n> Creating a C2 CMS or PWA Game Version?\n
    \n
  - \n5.5 Season to Taste …\n
  - \n5.6 Comparing your code\n
  \n
\n
\nPart III: Starting a C3 Production\n
- \n6 C3 “Combat Engine” Project\n
  - \n6.1 About Your Project\n
  - \n6.2 Project Settings: Color Theme, Start-up & Display\n
  - \n6.3 Configuration Settings: Advanced & Editor\n
  - \n6.4 Design Considerations: CMS, PWA, or SWPA?!\n
    - \n> Creating a C3 SWPA Game Version?\n
    - \n> Creating a C3 CMS or PWA Game Version?\n
    \n
  - \n6.5 Season to Taste …\n
  - \n6.6 Comparing your code\n
  \n
\n
\nPart IV: Combat Engines (CE)\n
- \n \n
  - \n \n
    - \nHow to Use this Collection\n
    - \nCombat Engine License\n
    \n
  \n
- \n7 CE #1 — “5-Second Comparison”\n
  - \n7.1 Developer’s Guide\n
    - \n> Gameplay Flow\n
    - \n> The Workhorse — “es_ce1Config”!\n
    - \n> Keyboard commands\n
    - \n> Supporting Functions\n
    - \n> Upload Saved Avatars\n
    - \n>“In-Game Module” (IGM) Example\n
    \n
  - \n7.2 Construct Source Code\n
    - \n> Bonus Card Game — “Black Jack” (IGM)\n
    \n
  \n
- \n8 CE #2 — “Minimal Narratives”\n
  - \n8.1 Developer’s Guide\n
    - \n> Client/Server — HTML, W3CSS, JQuery, AJAX, & PHP Source Code\n
    - \n> Client-side — Construct Source Code\n
    \n
  - \n8.2 Construct Source Code\n
    - \n> Bonus RPG IGM — “The Blood Pit Arena”™\n
    \n
  \n
- \n9 CE #3 — “Original Standard Module”\n
  - \n9.1 Developer’s Guide\n
  - \n9.2 Construct Source Code\n
  \n
- \n10 CE #5 — “Guitar Hero”\n
  - \n10.1 Design Options …\n
  - \n10.2 Developer’s Overview\n
  - \n10.3 Construct Source Code\n
    - \n> Bonus Racing Games\n
    \n
  \n
- \n11 CE #6 — “Rock, Paper, Scissors” (RPS)\n
  - \n11.1 Developer’s Overview\n
  - \n11.2 Construct Source Code\n
  \n
- \n12 CE #7 — “Astral & Cosmic Magic”\n
  - \n12.1 Developer’s Overview\n
  - \n12.2 Construct Source Code\n
  \n
- \n13 CE #8 — “Click Fest”\n
  - \n13.1 Construct Source Code\n
  \n
- \n14 CE #9 — “En Gard”\n
  - \n14.1 Developer’s Overview\n
  - \n14.2 Construct Source Code\n
  \n
\n
\nCE#9 Developer’s Guide\n
- \n15 Design Overview Topics\n
  - \n15.1 Gameplay Flow\n
    - \n> “Game Clicked” Phase\n
    - \n> “Boot & Load” Phases\n
    - \n> “Splash / Language” Phase\n
    - \n> “Game Lobby” Phase\n
    - \n> “Play” Phase\n
    - \n> “Game Finished” Phase\n
    \n
  - \n15.2 Navigation\n
  - \n15.3 Game Perspectives\n
  - \n15.4 Adding Your Bespoke Gaming Features\n
  - \n15.5 Player Participation Modes\n
  - \n15.6 Multi-Player Roles\n
  \n
- \n16 Layouts & Event Sheets\n
  - \n16.1 “Swordplay” Layout\n
    - \n> “es_Common” Event Sheet\n
    - \n> “es_swordPlay” Event Sheet\n
    \n
  - \n16.2 Administration Folders\n
    - \n> “AdminConfig” Layout\n
    - \n> “es_adminConfig” Event Sheet\n
    \n
  - \n16.3 CMS Folders\n
    - \nBusiness Related Services\n
    - \nSample “Splash / Language” Layout\n
    - \n> Sample “es_splashLang” Event Sheet\n
    - \n“Main Menu” Layout\n
    - \n> “es_mainMenu” Event Sheet\n
    - \n“Credits” (internal) Layout\n
    - \n> “es_Credits” Event Sheet\n
    - \nGamer’s “Options” Layout\n
    - \n> “es_options” Event Sheet\n
    - \n“Help” (internal) Layouts\n
    - \n> “es_help” Event Sheet\n
    \n
  - \n16.4 Multi-Player Folders\n
    - \nMMoG Login Layout\n
    - \n> “es_mmog_Logon” Event Sheets\n
    - \n> (Include) “es_mmog_Signalling” Event Sheet\n
    - \n> (Include) “es_mmog_Host” Event Sheet\n
    - \n> (Include) “es_mmog_Peer” Event Sheet\n
    - \n> (Include) “es_mmog_Common” Event Sheet\n
    - \n“Game Lobby” Sample Layout\n
    - \nOptional Game Lobby (Group Sample)\n
    - \nMMoG “Prepare To Duel” Layout\n
    - \n> “es_prepToDuel” Event Sheet\n
    - \n“Tavern Brawl” Layout\n
    - \nMMoG Fight Layout\n
    - \n> “es_mmog_Fight” Event Sheet\n
    - \nMMoG Won & Lost Layout\n
    \n
  \n
- \n17 CE #10 — “1st Person”\n
  - \n17.1 Developer’s Overview\n
  - \n17.2 Construct Source Code\n
  \n
- \n18 CE #11 — “Wheel of Fate”\n
  - \n18.1 Developer’s Overview\n
  - \n18.2 Construct Source Code\n
  \n
- \n19 CE #12 — “Slot Machine”\n
  - \n19.1 Developer’s Overview\n
  - \n19.2 Construct Source Code\n
  \n
- \n20 What’s next?\n
  - \n20.1 Game Distribution & Marketing\n
  - \n20.2 Introduction: 8-Step Deployment Method.\n
  - \n20.3 Port to a Console\n
  - \n20.4 Selling Directly — The Advantages\n
  - \n20.5 Book Review Protocol\n
  - \n20.6 Tell the world about your game!\n
  \n
- \n21 Conclusion\n
\n
\nAppendix\n
- \nMore Resources …\n
  - \n“You don’t know JS Yet” by Kyle Simpson\n
  - \nConstruct Demos\n
  \n
- \nAppendix: Game Developer Tool Kits\n
  - \nArtwork Resources\n
  - \nSelling your Game Artwork & Assets\n
  - \nJavaScript Garden\n
  \n
- \nAdditional Appendices\n
\n
\nAppendix: “How to Start a WebSocket”\n
- \n \n
  - \nTesting Your Browser\n
  - \nWebSocket Protocol Handshake\n
    - \n> Deeper Dive: WebSocket API\n
    \n
  - \nSample Source Code: Client-side WebSocket\n
    - \n>Step #1: Game index page\n
    - \n>Step #2: Generate Event handlers\n
    \n
  \n
\n
\nNotes\n

\nPreface

\n\n\n

This is a collection of twelve (12!) conflict engines for any game genre. Each chapter leads you through various methods for combat encounter development. The chapters have both Construct 3 & 2 encodings and include a general License. It’s perfect for novices, experienced web developers, and anyone wanting their bespoke game, artwork, and features.

\n\n\n

\nDistribution Permission

\n\n\n

\nForewords

\n\n\n

\nDisclosures

\n\n\n

\nDisclaimer

\n\n\n

\nWorkbook Content

\n\n\n

\n> For Patrons from Amazon and other Book Distributors

\n\n\n

\n> About this Workbook

\n\n\n

\n> How to Read & Use this workbook:

\n\n\n

\n> Viewing the eBook:

\n\n\n

\n> External Links

\n\n\n

\n> References Used

\n\n\n

\nYour newly obtained skills …

\n\n\n

\nMore Resources

\n\n\n

\nProgramming Courses

\n\n\n

\nPart I — Concept & Design

\n\n

\"\" — Software Project Management for Games

\n\n\n

Part I is an introduction to my Game Design System™ and building Game Recipes™. By starting either “Part II (C2)” or “Part III (C3)”, and ending with Part IV Combat Engine Construction we’ll have created everything our Conflict Engine prototype needs.

\n\n\n\n

Introduction

\n\n

“Why should I study a “systems-based” design?”, you say? Answer: Yes! Why indeed! The earliest decisions about what kind of game(s) a studio builds will impact all the development and production activities of that project’s management. It affects how Construct “encodes” your game’s features, how you will construct scenes, layouts, layers, and optimize Game Mechanics’ Events, and how those “time-consuming animations” and “cut-scenes” are handled — just to mention a few. There’s also a heavy cost associated with how much creative freedom is permitted. Historically, games with “open-ended” possibilities tend to be much more difficult to accurately schedule. The Game Design System™ addresses those shortcomings in this project management approach.

\n\n

Creating your own bespoke game is an exciting adventure in creativity using the Construct Game Framework (or with any Gaming Framework for that matter); and, at the same time, it’s fun! However, dealing with all those “full-stack” technical details — such as web pages, artwork production, collisions, sprites, “game phases” (and there’s a lot more!) — can be quite intimidating; especially, if this is your first experience with such gaming components.

\n\n

In general Construct, — and any other Code-less Gaming Framework — generates all the JavaScript resources and libraries for us that run inside our Internet device. Any of these “code-less frameworks” simplifies and abstracts those gaming programming patterns and algorithms into easy-to-use, high-level “worksheets” for those JavaScript functions. Using these “worksheets”, we can quickly build various two-dimensional ( aka “2D” or 2.5D ) and even 3D games are possible inside a simple HTML5 “<canvas>“ tag. Construct does 95% of all that “work” for us; and beyond that, all you need is your imagination and some basic logic. If you’d like to create “complex game interactions” then JavaScript knowledge becomes handy; and with only a few hours spent, you can gain that knowledge for FREE from W3Schools. So, let’s begin by creating several Combat Engines and Systems for any Game Mechanics.

\n\n\n\n

In Part IV our goal is to “construct” 12 fully functional “Combat Engines” for any gaming genre. We’ll build them to replace, insert, and even substitute existing hostile encounters. You might even consider letting your gamers choose which systems to use. There are simple step-by-step “Game Recipe™ instructions” for each task. We’ll catalog and create various Game Mechanism Components — those “visual elements” that are separate from the core Game Mechanics rules, logic, and data. From this simple foundation, we can combine our “Combat Engines” into any game genre as easily as a child would use Lego™ blocks to construct a toy castle. Furthermore, you can review this construction process and many other Game Mechanics in the Construct Game Starter Kit Collection workshop books — a growing collection of other classical and popular game mechanics and their sub-genres.

\n\n

So then, “What’s a Combat Engine prototype”, you asked?
Answer: It is an operational gaming foundation that can:

\n\n

accepts inputs (Game Framework Mechanism (GFM) component);
moves game elements and components (Game Framework Mechanism (GFM) component);
transitions between game phases, and translates “game actions” (Game Mechanics (GM) component which dictates changes to the “visual elements” in the displayed Game Framework Mechanisms (GFM).)
reacts to internal game object collisions, visual animations, and “Heads-Up Display” (HUD) feedback — those interactions between both Game Mechanics (GM) and Game Framework Mechanisms (GFM) Components.

\n\n

What are the benefits of creating an isolated Combat System?

\n\n

Answer: See the latest comments from various gaming experts here and here; and other software engineers’ opinions about prototyping in general — here.

\n\n

My Game Design System™ is clearly echoed in the Construct Framework, GDevelop, Apple’s Game-Play Kit, and Play Canvas as “Entities and Components”. Apple’s Game-Play Kit plainly states,

\n
“The Entity-Component design pattern is an architecture that favors composition over inheritance. To illustrate the difference between inheritance-based and composition-based architectures, consider how you might design, for example, a “tower defense” style game, with the following features … (Continue reading their comparisons in “Designing with Entities and Components”.
\n

\n\n

It’s a wonderful feeling to discover after several decades that other prominent game developers are thinking along the same patterns of “game prototype development”.

\n\n\n

\n1 “Code-less” Game Design

\n\n

\nApproaching Game Development

An Excerpt from “Macromedia Director Game Development” available from Amazon.com

\n\n

Whether you are an experienced game developer, a master of video games, or even new to computers, a great computer game will offer you entertainment and often some type of competition. Over the years, basic games have evolved to encompass numerous genres such as role-playing, first-person shooter, side-scrolling, strategy, education, and simulations. Role-play games involve a main character or characters thrust into a heroic plot. A first-person shooter, however, involves adrenaline-fed killing and destruction. Although simulations are generally designed to be as realistic as possible, most side-scrolling, strategy, and educational games tend to be a bit more simplistic. With the wide variety of games available today, the average person will have no trouble finding a game that suits their desires. As you develop your game design skills, avoid simply mimicking existing games. In most cases, however, any game you develop will fit clearly into a specific genre.

\n\n

\nFocusing Your Game

\n\n

When you begin the process of designing a game, you must first decide how to approach the task. Determining the focus of your game is the best way to begin. You should decide on a topic, purpose, and theme for your game. Listing objectives that you want to accomplish through your game is often a smart way to begin. You might have objectives that direct the activities you will build into the game and a different set of objectives for the person who plays the game to accomplish. Through your thinking process, you will determine exactly what your game is about and how you should go about creating it. How focus your game will affect all the decisions you make later in the design process.

\n\n

\"\" — ***Game Design System™*** creating new Games by “re-skinning” Artwork Themes!

\n\n\n

Game classification is diverse. So, I’d like to agree on some standard definitions as we “cook up” our Combat Engines using the Game Design system™ and its Game Recipes™ tools.

\n\n

\ngame prototypes — are a blend of three components: the Game Mechanics (GM — composed of data, logic, and rules in which Combat Engines reside); the Artwork Theme(s); and the Game Framework Display Mechanisms (GFDM). These three components create the “Minimum Viable Product” (MVP). Quoted from “Construct Game Starter Kit Collection” (page 69), “By combining all of our game mechanisms, with a set of game mechanics and its rule systems — as non-invasive aspects in our gaming product — along with an artwork theme, we’re able to create multiple game products quickly and even substitute different Combat Engines “on the fly”! It simply becomes a matter of exchanging any of those “3 cross-cut” components into a new innovative mixture for a new game product. We could even allow our gamers to choose which Combat Engine to use in each hostile encounter. This is the secret to concocting a new game every month or even every week! For example, swapping a “Guitar Hero” artwork theme with a “Plants & Zombies” — both use the same Combat Engine. The new game uses the same “Game Mechanics” and “Game Display Mechanisms” but with a “fresh organic garden” look and feel! From Page 117, “… let me write that code once and reuse it for similar items in other games as a “component prototype” — this is the secret sauce in our Game Recipes™! Keep your “featured ingredients” D.R.Y (Don’t Repeat Yourself) and use it everywhere in your game Studio!” Construct has already given us many “Plug-ins” components to help us. (See the Appendix for 300+ more Plugins, Behaviors, and Effects!)
\ngame mechanics — (11-page Bonus Content) — are written into Construct’s “Event sheets”. You merely describe how your game “works” using a “logical block system”. Quoted from “Construct Game Starter Kit Collection” (page 68), “From a game programming perspective, basic Game-Play can be deconstructed — revealing tactical components inside a game’s overall mechanics, logic, and rules. For example, a fighting game deconstructs into various tactics such as attacks (or punches, throws, and kicks), defensive moves, and dodges. These tactics are assigned to code functions and visual mechanisms — the input keys, mouse clicks, and screen interactions. This allows us the flexibility to transfer Combat Engines between different gaming genres.

\"\" — From “Game Programming Patterns” by Robert Nystrom

\n\n

\ngame mechanisms — are those visible objects placed in Construct’s “Scenes, Layouts, and Layers”. Quoted from “Construct Game Starter Kit Collection” (page 85), “The gameboard grid defines the Game Mechanics (GM) movement rules; how that grid is drawn is a Game Framework Mechanism (GFM). Players will send their decisions from their device’s inputs using their browser — keyboard, mouse, game-pad, etc. — and the visual widgets and mechanisms we designate as drop-down menus, buttons, and “sliders”. Mechanisms are those “visual-display elements” of Construct’s Game Framework Mechanism (GFM).” You will soon discover how important it is to keep the Combat Encounters isolated to their own layout screens.

\n\n\n\n

\"\" — ***Game Design System™*** User Interface (UI) to Game Mechanics — there and back again!

\n\n\n

\n1.1 Game Genres Defined

\n\n\n\n\n\n

Game Genres can be confusing. The inconsistency comes from trying to describe a game’s mechanics, a game’s delivery mode, with details associated with a game’s theme. Game genres are specific game categories related by their similar gameplay characteristics. Remember that gameplay IS the “rules of a game” (i.e.: the Game Mechanics (GM)). Single-player and multi-player are therefore not game genres. They are “delivery” mechanisms dictating the “mode” of gameplay.

\n\n

A genre’s challenges are those rules that govern its gameplay and conflict resolutions. Game genres are separate from their interfaces, and operating systems. If we turn to ludology (aka “gaming theory”), it classifies games according to several criteria —

\n\n

whether a game is symmetric or asymmetric,
what a game’s “sum” is (zero-sum, constant sum, and so forth),
whether a game is a sequential game or a simultaneous one,
whether a game includes perfect information or imperfect information, and
whether a game is determinate.

\n\n

\nGG Interactive — Game Design Course\n

\n\n

Genres don’t help market a game — instead, the selection of a genre has an effect on what (the size of) the audience is likely to be interested and willing to purchase a game. Genres do help an audience understand the basics of a game by promising them a certain amount of familiar elements they desire (or demand) in a particular genre. For example, fans of medieval fantasy will expect some common themes in a Fantasy Real-Time Strategy (FRTS) game: knights, castles, troop combat, and magic, to name a few. As a game designer, it is important to understand what kind of audience expectations exist across different genres. Stray too far from these expectations without designing a brilliant alternative and the game will lose its audience. Stick too close to what has come before and the game will be overlooked as offering nothing new. Even the bold designer who intends to rewrite all that we know about how a genre game is played needs to understand what, to this point, has made the genre popular before deconstructing it and making it better.

\n\n

\n\n\n\n

\n1.2 Demand for Abstract Games

\n\n\n\n

These charts show what games you should develop profitably, in which languages, and where to deploy them (i.e.: marketing channels). “Resolving Hostile Encounters through Combat Engines” is a subset of both the “Puzzle” and “Strategy” genres gameplay.

\n\n

\"\" — Demand for Puzzles and Games per Euro-monitor

\n\n\n

\n\n\n

\"\" — Game Genre’s Popularity compared Worldwide

\n\n\n

If you combine the “Action-adventure” with the RPG genre, you will have a “healthy market share” to target for your final product. This also guides you into “what style of combat engine” Abstract Puzzle and Strategy games will use — for example, a “Bump or Jump” To Capture is a standard elimination for both “Abstract Strategy” and “Puzzle” games.

\n\n

\n1.3 Game Delivery Modes

\n\n

This is another often-misused term and is often confused with a game’s perspective or participants. Let’s agree that “game mode” refers to a game’s participation and the number of players within a game session. Armed with this definition let’s further define how gamers participate.

\n\n

Single Player — A single-player game accepts input from only one participant and refers to those games that can be played by only one active person. “Single-player mode” converts game-play into a single-player input. Furthermore, the “Single-player mode” might have representation as an avatar found in PacMan which shows the position and interaction of a player within the gaming world. Single-player is not restricted in representation as in arcade-style games of Tetris. Many military strategy games allow multiple avatars per single gamer while battling the computer’s artificial intelligence. Much of the online games, today were designed for single-player mode. Here’s an interesting and controversial article on the future of computer-monitored single-player games. Are single-player games doomed?

\n\n

Multi-Player — This mode, as its name suggests, allows more than one game participant. Many game publishers mistakenly set Massive Multi-Player Online Games (MMoG) as a separate gaming genre. Yet, in my opinion, it is not. Massive Multi-Player Online Games (MMoG) is a mode of play couched within many different game genres just as single-player games have varying genres. Gamers can play cooperatively in teams or antagonistically as opponents in this mode. Like single-player games, Multi-Players normally have avatar representation as “one player to one avatar” or “one participant with multiple avatar teams”. The gaming party might have local or remote access to a single game session. Two gamers could play in “hot-seat” mode; in which, they would pass the input devices to the next player for their game-turn. This was popular in the early days of console gaming when local area networks were significantly diminished as compared to current modern-day network capabilities. Modern networks have provided the foundation for Massive Multi-Player Online Games. I have dedicated an entire section to various considerations in the multi-player game development.

\n\n

With these definitions, we can now determine which “game mode” to use, how, and where to deploy our game as either a “Cloud Service” or a “Mobile app”. Notice how similar Combat Engines become going toward and away from “Cloud Service”.

\n\n

\"\" — Using Cloud Delivery Services vs Mobile Targeted Audience

\n\n\n

\n> Mobile “In Apps Purchases” (IAP) ROI

\n\n

\"\" — ***Strategy Games Return On Investment (ROI) has the greatest revenues!***

\n\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n

**Revenues from Game in-app purchases on 20161017 for iOS & Android US smartphones**
Top	$21,188,000 (clash of clans)
Average	$8,400
80th Percentile	$3,100
50th Percentile (Median!)	$150
20th Percentile	$0

\n\n\n\n

\n1.4 Game Tools & Generators

\n\n

You will discover many supporting tools from “MakingBrowserGames” GitHub and in the Appendix of this book. Here are some tools that will help in generating gaming ideas, game design documents, and dynamically generated project source code.

\n\n

\nYourKit — supports open-source projects with innovative and intelligent tools for monitoring and profiling Java and .NET applications.
\nRandom Game Mechanics Generator — This idea generation machine randomly selects 3 — by default — common game theory mechanics. The game mechanics and descriptions should help your imagination blend and produce the next blockbuster game.
\nGame Framework Mechanisms (FREE Limited Access) — This library of game controls and mechanisms spans several JavaScript gaming frameworks — more are on the way! This tool helps you choose those game controls and then opens the generic code snapshots (aka “snippets”). Spend a minute to re-factor those snapshots to your bespoke design and you’ll have a functional game prototype within minutes.
\nGIT — Git is a free and open-source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git allows and encourages you to have multiple local branches that can be entirely independent of each other. The creation, merging, and deletion of those lines of development takes seconds.
\nConstruct Tools & Resources
\n“12 Handy Free Productivity Tools For Game Designers”

\n\n

\n> The Digital Ludeme Project

\n\n

This project is a computational study of the world’s traditional strategy games throughout recorded human history. Their aim is to improve our understanding of traditional games using modern AI techniques, chart historical game development, and explore their role in the development of human culture while incorporating ludic ideas. They define games as structured sets of “ludemes” (units of game-related information), which will allow the full range of traditional games to be modeled into a single software system for the first time. (See the “Ludii General Game System” below — a general game system designed to play, evaluate, and design a wide range of games, including board games, card games, dice games, and mathematical games.) Their system will not only model and play games but will also evaluate reconstructions for quality and historical authenticity. This will lay the foundations for a new field of study called “Digital Archaeoludology” (DA).

\n\n

\n> Ludii General Game System

\n\n\n\n

Ludii, a computer program, creates games by taking the rules of existing games and scrambling them into new combinations using genetic programming (GP) techniques of crossover and mutation. New games are tested through self-play trials and assigned a quality score based on their estimated potential to interest human players. The complete process of design, testing, and evaluation is entirely automated. Ludii creates a unique name for each evolved game using a Markovian stochastic process seeded with Tolkien-style words.

\n\n\n\n\n\n

\n2 Combat Engine Designs

\n\n\n

\n2.1 Engine Considerations

\n\n\n

\n> Determining Successful “Hits”

\n\n\n

\n> Determining Inflicted Damage

\n\n\n

\n> Combination Experiments

\n\n\n

\n> “Now What!” — Answering Our Question #3

\n\n\n

\n> Summary

\n\n\n

\n2.2 So, Give Me Some Space …

\n\n\n

\n> Deeper Dive: Melee Weapons

\n\n\n

\n> Deeper Dive: Ranged Weapons

\n\n\n

\n2.3 Rules of Engagement: Take 5 paces, turn and …

\n\n\n

\n2.4 Yo bro, give me some skin …

\n\n\n

\n> Creating an Avatar’s Visuals

\n\n\n

\n> Creating an Avatar’s metadata

\n\n\n

\n2.5 Been there … done that …

\n\n\n

\n2.6 Finite State Machines (FSM)

\n\n\n

\n> FSM Resolving Combat Outcomes

\n\n\n

\n> FSM Resolving AI behaviors

\n\n\n

\n2.7 Recursive World Feedback

\n\n\n

\n> Probability Data Tables

\n\n\n

\n3 Project Management Overview

\n\n\n

\n3.1 “Loose lips sink ships” … and revenues!

\n\n\n

\n3.2 Game Recipe™ just add Artwork, stir, & season to taste!

\n\n\n

\n> Conflict Resolution & Victory

\n\n\n

\n> Deeper Dive: Developer’s Right or Left-handed Bias?

\n\n\n

\n3.3 Development:

\n\n\n

\n> Step #1: Understanding “Human Limitations” & Requirements

\n\n\n

\n> Step #2: The “Elevator Speech” & Description

\n\n\n

\n3.4 Design:

\n\n\n

\n> Deeper Dive: Putting Background Stories in the Wrong Place

\n\n\n

\n3.5 Construct’s “Code-less” Encoding

\n\n\n

\n> Deeper Dive: Creating Display Mechanisms — a 4-Step method

\n\n\n

\n4 Part I: Conclusion

\n\n\n

\nPart II: Starting a C2 Production\n

\n\n\n

\n5 C2 “Combat Engine” Project

\n\n\n

\n5.1 About Your Project

\n\n\n

\n5.2 Project Settings:

\n\n\n

\n5.3 Configuration Settings

\n\n\n

\n5.4 Design Considerations: CMS, PWA, or SWPA?!

\n\n\n

\n> Creating a C2 SWPA Game Version?

\n\n\n

\n> Creating a C2 CMS or PWA Game Version?

\n\n\n

\n5.5 Season to Taste …

\n\n\n

\n5.6 Comparing your code

\n\n\n

\nPart III: Starting a C3 Production\n

\n\n\n

\n6 C3 “Combat Engine” Project

\n\n\n

\n6.1 About Your Project

\n\n\n

\n6.2 Project Settings: Color Theme, Start-up & Display

\n\n\n

\n6.3 Configuration Settings: Advanced & Editor

\n\n\n

\n6.4 Design Considerations: CMS, PWA, or SWPA?!

\n\n\n

\n> Creating a C3 SWPA Game Version?

\n\n\n

\n> Creating a C3 CMS or PWA Game Version?

\n\n\n

\n6.5 Season to Taste …

\n\n\n

\n6.6 Comparing your code

\n\n\n

\nPart IV: Combat Engines (CE)

\n\n\n

\nHow to Use this Collection

\n\n\n

\nCombat Engine License

\n\n\n

\n7 CE #1 — “5-Second Comparison”

\n\n\n

\n7.1 Developer’s Guide

\n\n\n

\n> Gameplay Flow

\n\n\n

\n> The Workhorse — “`es_ce1Config`”!

\n\n\n

\n> Keyboard commands

\n\n\n

\n> Supporting Functions

\n\n\n

\n> Upload Saved Avatars

\n\n\n

\n>“In-Game Module” (IGM) Example

\n\n\n

\n7.2 Construct Source Code

\n\n\n

\n> Bonus Card Game — “Black Jack” (IGM)\n

\n\n\n

\n8 CE #2 — “Minimal Narratives”

\n\n\n

\n8.1 Developer’s Guide

\n\n\n

\n> Client/Server — HTML, W3CSS, JQuery, AJAX, & PHP Source Code

\n\n\n

\n> Client-side — Construct Source Code

\n\n\n

\n8.2 Construct Source Code

\n\n\n

\n> Bonus RPG IGM — “The Blood Pit Arena”™\n

\n\n\n

\n9 CE #3 — “Original Standard Module”

\n\n\n

\n9.1 Developer’s Guide

\n\n\n

\n9.2 Construct Source Code

\n\n\n

\n10 CE #5 — “Guitar Hero”

\n\n\n

\n10.1 Design Options …

\n\n\n

\n10.2 Developer’s Overview

\n\n\n

\n10.3 Construct Source Code

\n\n\n

\n> Bonus Racing Games

\n\n\n

\n11 CE #6 — “Rock, Paper, Scissors” (RPS)

\n\n\n

\n11.1 Developer’s Overview

\n\n\n

\n11.2 Construct Source Code

\n\n\n

\n12 CE #7 — “Astral & Cosmic Magic”

\n\n\n

\n12.1 Developer’s Overview

\n\n\n

\n12.2 Construct Source Code

\n\n\n

\n13 CE #8 — “Click Fest”

\n\n\n

\n13.1 Construct Source Code

\n\n\n

\n14 CE #9 — “En Gard”

\n\n\n

\n14.1 Developer’s Overview

\n\n\n

\n14.2 Construct Source Code

\n\n\n

\nCE#9 Developer’s Guide

\n\n

\"\" — Combat Engine #9— Swashbuckler’s Swordplay™

\n\n\n

This guide has two sections:

\n\n

\nDesign Overview Topics — holds the ideas and “rationale” for this game’s current construction.
\nLayouts & Event Sheets — list the same information in greater detail as it appears in the event sheets’ conditions and actions.

\n\n

\n15 Design Overview Topics

\n\n

This section has the design “rationale” and the choices I took to develop this game. There are still many options I’d like to include or change for better gameplay. This section discusses those various options.

\n\n

\"\" — This is my standard gaming structure.

\n\n\n

“Layouts” are the game’s visual elements from the “Gaming Framework Display Mechanisms” (GFDM).
“Event Sheets” hold the “Game Mechanics (GM) — the game’s “Data, Logic, and Rules”.
\nArtwork Assets and Themes are the graphical elements shown inside the layouts.

\n\n\n\n

\n15.1 Gameplay Flow

\n\n

\"\" — Content-as-a-Service (CaaS) for a Content Management System (CMS)

\n\n\n

Also review the “Flow of a Multi-Player Game” tutorial.

\n\n

\n> “Game Clicked” Phase

\n\n

A gamer has discovered our game — hopefully a licensed version?! — somewhere on the Internet. Our gamer clicks the hosting game site’s web page to play our game.

\n\n

\n> “Boot & Load” Phases

\n\n

This begins the “Web Socket” and game delivery to the gamer’s browser. The game is downloaded from any “Content Delivery Network” (CDN) to the gamer’s browser if this is their first visit. Otherwise, the game might still be in their browser cache — meaning this is a return visit. See the “multi-player connectivity” tutorial.

\n\n

\n> “Splash / Language” Phase

\n\n

This layout should display the game’s “Business-To-Business” (B2B) sponsor(s) or advertisements. Otherwise, this layout is a “White Label” licensed version — as seen here!

\n\n

At first, supporting various languages may seem complicated. I’ve read all of the available Construct tutorials (as of 20241101) and purchased “several of these assets“ concerning language integration (aka “Internationalization”) and many of these were not “well-thought-out”. Instead of typing in each supported language’s text into an “Excel Spreadsheet-styled” array, I assign language text into its dedicated language Dictionary’s listing. — instead of having all languages jumbled together into a single project file. Putting all the various languages into a single single file complicates upgrading game features — you’ll need a minimum of 13 languages(!!!) for each HUD text, new features, and menu labels referenced; especially, if those features do NOT apply (or are intended) to all markets segments! The “Splash / Language Layout’s Event Sheet” below shows my optional implementation (or see the “official Construct example here”).

\n\n

\"\" — Toggling an Optional “Splash/Language Layout”

\n\n\n

The sample code above provides game administrators an option to toggle their “Splash/Lang” layout. If the “langUsed” variable is set to “0”, then the game’s administrator has a default language for everyone to use (in this case, English). The game goes immediately to the “Main Menu” layout. Otherwise, if the game administrator sets the “langUsed” variable to “99”, a gamer is sent to an initial language menu for them to choose their native language. (See sample illustration below) Of course, this assumes the administrator has all of the HUD text, menus, and button labels ready for the gamer’s choice.

\n\n

\"\" — Sample of a Language Selection Layout

\n\n\n\n\n

I also separate a button label from its underlying sprite. Doing so, allows me to insert any language into that label’s content. I firmly believe that the first thing a gamer sees is a language selection menu. The student workbook and workshop lectures go into great detail about International marketing and language integration. Native English gamers are only a small marketing segment compared to all the gamers in the world. I use “National Flags” to represent a country’s primary language. I use the “heads-up display” (HUD) text in their native languages to ensure their choice and provide instructions about what to do next. If a gamer selects with their mouse, then I know they’re playing from a “Desktop computer”. If the gamer “touches” their flag, then I know they’re playing on a “touch screen” device. “Why’s that important?”, you asked. Because:

\n\n

I set specific controls for the mouse or touchscreen controls triggered from this layout.
I want as many people “Internationally” playing my game. Construct3 v370+ now integrates icons and text; but more importantly, has the i18n Internationalization feature — making multilingual games a “cinch”! This plugin uses the standard “IETF language tags” which help distinguish language variants for countries, regions, or writing systems.
Not everyone speaks or reads English natively. English native speakers are only 16% of all Internet users. I want my game to capture a larger market share than that. Don’t you?!
(Quoted from “Construct Game Starter Kit Collection” page 269) “By 2040, India will be the largest population on earth — surpassing China!”

\n\n

\n How Languages Got Their Directionality by Steph Koyfman April 28, 2021

\n\n

… The prevailing theory is that “Directionality” was a mechanical consequence of the way languages were written. For instance, East Asian languages, which are often written top to bottom, were once written on scrolls. It would be easier for someone to write top to bottom with one hand holding the paper.

\n\n

It also apparently affects more than just the way you’re accustomed to reading text on a page. A group of researchers found that the “Directionality” of a language can affect the way people represent time spatially. That makes sense when you consider that training your eye and hand movements in a certain direction also creates deep associations with the way chronological order works visually, or with the way you organize information generally.

\n\n

… Believe it or not, English came pretty close to being a right-to-left language. Back in the day, Old English was written in the runic alphabet, a writing system that ran right to left in its earliest iterations. Eventually, though, the Latin alphabet replaced runes, reversing the directionality.

\n\n

\nRight-To-Left Languages

The two most well-known right-to-left languages are Arabic and Hebrew, which share a common linguistic ancestor in the Aramaic alphabet. Persian, Sindhi, and Urdu all use adapted forms of the Arabic alphabet. Azeri, Kurdish, Azerbaijani, Rohingya, Fula, N’ko, Syriac, and Maldivian are also right-to-left languages.

\n\n

\nTop-To-Bottom Languages

\n\n

Most of the world’s top-to-bottom languages are found in Asia. These include Mongolian, Chinese, certain Japanese dialects, and a couple of Korean dialects, though some are written vertically from left to right, and some are written vertically from right to left. Chinese, Korean, and Japanese are also often written horizontally, too, from left to right.

\n\n

—————————————————–

\n\n

\nContent languages market position report.

\n\n

Review this chart of the website languages on the Internet as of 14 DEC 2022. By tailoring your game to these top 13 languages, you increase the pool of possible gamers to over 34+% beyond the 58.7% English users. That is a total Internet market share of 93+%!

The 13 languages your game should have, as a minimum for users, are (in order): English (58.7%); Russian (5.3%); Spanish (4.4%); French (3.7%); German (3.7%); Japanese (3.0%); Turkish (2.8%); Persian / Arabic (the 6th most spoken language globally) (2.3%); Simplified Chinese (1.6% of the websites, but has the most users internationally and 14+% of the global population); Italian (1.6%); Portuguese (1.5%); Vietnamese (1.4%); Dutch, Flemish (1.2%); and Polish (1.1%) for a total market pool of 94.1% of Internet users. (view the complete updated list here)

\n\n\n

\n\n\n\n\n\n

\n> “Game Lobby” Phase

\n\n

This game phase comes in several display formats. Its primary purpose is to provide a logon for the gamer into the Scirra Multi-Game Server.

\n\n

a simple “Log on” default layout, OR
a detailed “Game Lobby” layout customized by a business partner (discussed in greater detail below) in which gamers can see all the available “Rooms” and any other logged-in gamers.

\n\n

This phase associates gamers and herds them into “Waiting Rooms” until the “MAXIMUM” players are collected. The first gamer, to enter a room, becomes the gaming session’s “HOST” for everyone else who arrives later. The HOST’s device could be a mobile phone, laptop, or desktop computer. Keep this in mind whenever you customize this game. Ask yourself, “How many players could a mobile phone support?” Since no one can predict what device a gamer is using who becomes a “HOST” (aka the “Master Device”), I restrict my game versions to 7 other players — because a “Bluetooth piconet” (aka a “PAN”) can only support seven (7) other devices. See the multi-player signalling tutorial OR “Making Multi-Player Online Games” workbook.

\n\n\n\n

\n> “Play” Phase

\n\n

Finally, the gamers arrive at the actual gameplay phase. The gameplay could be designed as either a “Smart” Browser client or a “Dumb” browser client which is the standard for the Scirra Multi-Game server.

\n\n

Combat Engine #9 uses several different game modes. It has the “Single Player / Single Avatar” (SPSA) found on the main menu layout. It also uses the Combat Engine #2 which dominates most of the multi-player gameplay in the “Single Player / Multi-Avatar” (SPMA).

\n\n

\n> “Game Finished” Phase

\n\n

Displays a gamer’s success or failure. Most “Massive Multi-Player Online Games” (MMoG) show a scoreboard of the top players, and the ability to submit new scores. Of course, there should always be a “Play Again” option.

\n\n

FYI: As of January 2021, 4.66 billion people — more than half of the world’s population — were actively using the Internet. Of this number, a whopping 92.6% access the Internet using mobile devices. With such a vast number of people accessing massive data, today’s service providers require network upgrades to increase bandwidth capacity. (Read more here…)
—
Design Note: In the modern-day WWW, it is naïve to assume all your client gamers have a keyboard and/or mouse. Many users now browse the web with only touch-screen devices — they don’t have a physical keyboard or mouse. Furthermore, the Construct “Keyboard object” does not respond to any modern touch device’s input from its on-screen keyboard. Therefore if your game exclusively uses mouse or keyboard controls, it’s impossible to play your game on any touch devices. See the “Touch controls tutorial” for an alternative control system. Also, note that there are a variety of keyboard layouts used internationally. There are around 7,000 languages and 50 writing systems in the world. For example, if you only provide “WASD” as direction controls, — is one of my pet peeves from legacy 1982 games! (Learn why! and about “Dennis Fong” (alias “Thresh”)) — your game may be difficult to control on AZERTY keyboards. “ZQSD” controls cover the AZERTY layout better, but there are still many more possible keyboard layouts — while game developers “scratch their heads” and ponder why their games aren’t Internationally popular?!?! QWERTY keyboards are popular within the US, but the US only has 16% of the total Internet traffic. You restrict your game and cripple your market share by using “WASD” instead of “arrow keys”. Always use arrow keys for directional controls (and stop following the ignorant crowd)! See for yourself! Review the International keyboards here — all of them have “arrow keys”! The “Arrow Keys” will cover most International keyboards, but remember that the same problem applies to any other controls depending on a specific keyboard layout.

\n\n

\n\n\n\n

\"\" — CE#9 Main Menu Multi-Player Selected

\n\n\n

I use several types of game navigation elements:

\n\n

\nText objects and Button labels — such as the “Affiliate ID”, game version, and labels sitting on top of their sprite menu buttons;
\nSprite menus and arrow buttons — can be any shape and have three animation frames — a normal, highlighted (green for “Go”), and “Forbidden” (red for “Stop”) animation frames;

\n\n

Whenever I display left or right arrows, the left arrow ALWAYS returns to the main menu layout for “Left-to-Right” languages. The right arrow ALWAYS goes to the next “Game Phase” for “Left-to-Right” languages. For “Right-to-Left Languages”, I reverse their destinations.

\n\n

I never use embedded sprite fonts in any menu button; it is a poor design in my opinion, and more importantly, restricts those sprites to a single language (which is also extremely poor product marketing management).

\n\n

\n15.3 Game Perspectives

\n\n

First-person, Third-person, Top-down, & Isometric

\n\n

\nFirst-person — The camera view is at the same angle as the gamer. A player sees the gaming environment through their avatar’s eyes as if they are actually in the game.
\n3rd Person (aka “Platform” view) — The camera view is positioned for you to see all the avatars. This could be modified and positioned behind a gamer’s avatar so that their backside is seen while moving through the gaming environment.
\nTop-Down (aka “Bird’s Eye” view) — is the default camera view in CE #9.
\nIsometric is similar to the “3rd person” view but with a different camera angle. Isometric has a variety of subcategories. \n
- “Orthographic” projections — “isometric, dimetric, trimetric” including some already mentioned above.
- “Oblique” projections — is a parallel projection in which the lines of sight are not perpendicular to the projection plane.
- “Perspective” projections — the center of projection is at a finite distance from the projection plane. This projection produces realistic views but does not preserve the relative proportions of an object’s dimensions.
\n

\n\n

\n15.4 Adding Your Bespoke Gaming Features

\n\n

Your new gaming features should entice gamers to play multiple gaming sessions. The student workbooks review those various “enticements”. Scirra Multi-Game Server encourages this also by assigning the first gamer into a “room” to become that gaming session’s HOST. I further enhance this by permitting the HOST to choose its gaming environment and its combat grid style in licensed editions.

\n\n

I have a “grocery list” of other such features that I want to include; some may appear in future releases. You’ll find, as you play this game, that you might want to tweak or add some more/other gaming features, different system rules, and other Gaming Mechanics (GM). Here’s how I assign new features to one of these participation modes …

\n\n

\n15.5 Player Participation Modes

\n\n

Single Player / Single Avatar (SPSA) against an AIBot.
Single Player / Multi-Avatars (SPMA) against an AIBot team.
Multi-Player / Single Avatar (MPSA) against another Human gamer.
Multi-Player / Multi-Avatars (MPMA or “teams”)

\n\n

Multi-Player games can then become either …

\n\n

\nCompetitive — All participants are in a “Free for All” Gang Fight! I’ve learned that this type of multi-player game requires a highly proficient customer support system. Aggressive gamers often take the same approach toward my “customer support” employees.
\nCooperative — All participants are on the same team and start in the “Disengaged Combat Mode”. Whenever their avatar becomes adjacent to an “enemy team member” (i.e.: AIBot), they are “Engaged” in combat and could move to another layout.

\n\n\n\n

\n15.6 Multi-Player Roles

\n\n

A gamer can assume the role of either a “HOST” or a “PEER”; it is a “Hub and Spoke” network relationship. The “HOST”, as its “Hub”, manages all the “Enemy AIBots”, processes all incoming participation reactions, and synchronizes the locations of everyone’s avatars. The HOST is the authoritative version of a gaming session — doing anything else is inviting disaster! Their primary purpose is to show how we’re able to synchronize smooth AI movements over a Multi-Player network connection(s). A “HOST” broadcasts gamer’s data to all participants and relays their messages between “PEERS”. A “PEER” may only send information to its “HOST”. Each “PEER” has a “Peer ID” uniquely assigned by the Scirra Multi-Player Server before surrendering the gaming session to its “HOST”. The “Peer ID” is a permanent assignment and refers to a specific gamer’s avatar regardless of whether they change their alias nickname.

\n\n

\"\" — CE#9 Swashbuckler’s Swordplay Multi-Avatar Edition (Grid-less Combat)

\n\n\n

\n16 Layouts & Event Sheets

\n\n\n

\n16.1 “Swordplay” Layout

\n\n\n

\n> “`es_Common`” Event Sheet

\n\n\n

\n> “`es_swordPlay`” Event Sheet

\n\n\n

\n16.2 Administration Folders

\n\n\n

\n> “`AdminConfig`” Layout

\n\n\n

\n> “`es_adminConfig`” Event Sheet

\n\n\n

\n16.3 CMS Folders

\n\n\n

\n\n\n\n\n\n

\n\n\n

\nSample “Splash / Language” Layout

\n\n\n

\n> Sample “`es_splashLang`” Event Sheet

\n\n\n

\n\n\n\n\n\n

\n\n\n

\n> “`es_mainMenu`” Event Sheet

\n\n\n

\n“Credits” (internal) Layout

\n\n\n

\n> “`es_Credits`” Event Sheet

\n\n\n

\nGamer’s “Options” Layout

\n\n\n

\n> “`es_options`” Event Sheet

\n\n\n

\n“Help” (internal) Layouts

\n\n\n

\n> “`es_help`” Event Sheet

\n\n\n

\n16.4 Multi-Player Folders

\n\n\n

\n\n\n\n\n\n

\n\n\n

\n> “`es_mmog_Logon`” Event Sheets

\n\n\n

\n> (Include) “`es_mmog_Signalling`” Event Sheet

\n\n\n

\n> (Include) “`es_mmog_Host`” Event Sheet

\n\n\n

\n> (Include) “`es_mmog_Peer`” Event Sheet

\n\n\n

\n> (Include) “`es_mmog_Common`” Event Sheet

\n\n\n

\n“Game Lobby” Sample Layout

\n\n\n

\nOptional Game Lobby (Group Sample)

\n\n\n

\nMMoG “`Prepare To Duel`” Layout

\n\n\n

\n> “`es_prepToDuel`” Event Sheet

\n\n\n

\n“Tavern Brawl” Layout

\n\n\n

\nMMoG Fight Layout

\n\n\n

\n> “`es_mmog_Fight`” Event Sheet

\n\n\n

\nMMoG Won & Lost Layout

\n\n\n

\n17 CE #10 — “1st Person”

\n\n\n

\n17.1 Developer’s Overview

\n\n\n

\n17.2 Construct Source Code

\n\n\n

\n18 CE #11 — “Wheel of Fate”

\n\n\n

\n18.1 Developer’s Overview

\n\n\n

\n18.2 Construct Source Code

\n\n\n

\n19 CE #12 — “Slot Machine”

\n\n\n

\n19.1 Developer’s Overview

\n\n\n

\n19.2 Construct Source Code

\n\n\n

\n20 What’s next?

\n\n\n

\n20.1 Game Distribution & Marketing

\n\n\n

\n20.2 Introduction: 8-Step Deployment Method.

\n\n\n

\n20.3 Port to a Console

\n\n\n

\n20.4 Selling Directly — The Advantages

\n\n\n

\n20.5 Book Review Protocol

\n\n\n

\n20.6 Tell the world about your game!

\n\n\n

\n21 Conclusion

\n\n\n

\nAppendix

\n\n\n

\nMore Resources …

\n\n\n

\n“You don’t know JS Yet” by Kyle Simpson

\n\n\n

\nConstruct Demos

\n\n\n

\nAppendix: Game Developer Tool Kits

\n\n\n

\nArtwork Resources

\n\n\n

\nSelling your Game Artwork & Assets

\n\n\n

\nJavaScript Garden

\n\n\n

\nAdditional Appendices

\n\n\n

\nAppendix: “How to Start a WebSocket”

\n\n\n

\nTesting Your Browser

\n\n\n

\nWebSocket Protocol Handshake

\n\n\n

\n> Deeper Dive: WebSocket API

\n\n\n

\nSample Source Code: Client-side WebSocket

\n\n\n

\n>Step #1: Game `index` page

\n\n\n

\n>Step #2: Generate Event handlers

\n\n\n

\nNotes

Part I — Concept & Design

\n\n

\n\n","tocStructure",[732,733,734,735,736,737,738,739,740,741,742,743,744,745,746,747,748,749,750,751,752,753,754,755,756,757,758,759,760,761,762,763,764,765,766,767,768,769,770,771,772,773,774,775,776,777,778,779,780,781,782,783,784,785,786,787,788,789,790,791,792,793,794,795,796,797,798,799,800,801,802,803,804,805,806,807,808,809,810,811,812,813,814,815,816,817,818,819,820,821,822,823,824,825,826,827,828,829,830,831,832,833,834,835,836,837,838,839,840,841,842,843,844,845,846,847,848,849,850,851,852,853,854,855,856,857,858,859,860,861,862,863,864,865,866,867,868,869,870,871,872,873,874,875,876,877,878,879,880,881,882,883,884,885,886,887,888,889,890,891,892,893,894,895,896,897,898,899,900,901,902,903,904,905,906,907,908,909,910,911,912,913,914,915,916,917,918,919,920,921],{"_80":74,"_43":70,"_71":-5,"_75":76,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":70,"_71":-5,"_75":76,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":86,"_71":-5,"_75":87,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":92,"_71":-5,"_75":93,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":95,"_71":-5,"_75":96,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":98,"_71":-5,"_75":99,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":101,"_71":-5,"_75":102,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":105,"_71":-5,"_75":106,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":108,"_71":-5,"_75":109,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":111,"_71":-5,"_75":112,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":114,"_71":-5,"_75":115,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":117,"_71":-5,"_75":118,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":120,"_71":-5,"_75":121,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":123,"_71":-5,"_75":124,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":126,"_71":-5,"_75":127,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":129,"_71":-5,"_75":130,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":74,"_43":132,"_71":-5,"_75":133,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":136,"_71":-5,"_75":137,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":140,"_71":-5,"_75":141,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":143,"_71":-5,"_75":144,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":146,"_71":-5,"_75":147,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":149,"_71":-5,"_75":150,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":152,"_71":-5,"_75":153,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":155,"_71":-5,"_75":156,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":158,"_71":-5,"_75":159,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":161,"_71":-5,"_75":162,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":165,"_71":-5,"_75":166,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":168,"_71":-5,"_75":169,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":171,"_71":-5,"_75":172,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":174,"_71":-5,"_75":175,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":177,"_71":-5,"_75":178,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":180,"_71":-5,"_75":181,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":183,"_71":-5,"_75":184,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":186,"_71":-5,"_75":187,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":189,"_71":-5,"_75":190,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":192,"_71":-5,"_75":193,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":195,"_71":-5,"_75":196,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":198,"_71":-5,"_75":199,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":201,"_71":-5,"_75":202,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":204,"_71":-5,"_75":205,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":207,"_71":-5,"_75":208,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":210,"_71":-5,"_75":211,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":213,"_71":-5,"_75":214,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":216,"_71":-5,"_75":217,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":219,"_71":-5,"_75":220,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":222,"_71":-5,"_75":223,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":226,"_71":-5,"_75":227,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":229,"_71":-5,"_75":230,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":232,"_71":-5,"_75":233,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":235,"_71":-5,"_75":236,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":238,"_71":-5,"_75":239,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":241,"_71":-5,"_75":242,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":244,"_71":-5,"_75":245,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":247,"_71":-5,"_75":248,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":250,"_71":-5,"_75":251,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":253,"_71":-5,"_75":254,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":256,"_71":-5,"_75":257,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":259,"_71":-5,"_75":260,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":74,"_43":263,"_71":-5,"_75":264,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":267,"_71":-5,"_75":268,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":271,"_71":-5,"_75":272,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":274,"_71":-5,"_75":275,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":277,"_71":-5,"_75":278,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":280,"_71":-5,"_75":281,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":283,"_71":-5,"_75":284,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":286,"_71":-5,"_75":287,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":289,"_71":-5,"_75":290,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":292,"_71":-5,"_75":293,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":74,"_43":295,"_71":-5,"_75":296,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":299,"_71":-5,"_75":300,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":303,"_71":-5,"_75":304,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":306,"_71":-5,"_75":307,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":309,"_71":-5,"_75":310,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":312,"_71":-5,"_75":313,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":315,"_71":-5,"_75":316,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":318,"_71":-5,"_75":319,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":321,"_71":-5,"_75":322,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":324,"_71":-5,"_75":325,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":74,"_43":327,"_71":-5,"_75":328,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":331,"_71":-5,"_75":332,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":335,"_71":-5,"_75":336,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":338,"_71":-5,"_75":339,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":341,"_71":-5,"_75":342,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":344,"_71":-5,"_75":345,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":347,"_71":-5,"_75":348,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":350,"_71":-5,"_75":351,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":353,"_71":-5,"_75":354,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":356,"_71":-5,"_75":357,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":359,"_71":-5,"_75":360,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":362,"_71":-5,"_75":363,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":366,"_71":-5,"_75":367,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":369,"_71":-5,"_75":370,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":372,"_71":-5,"_75":373,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":375,"_71":-5,"_75":376,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":378,"_71":-5,"_75":379,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":381,"_71":-5,"_75":382,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":385,"_71":-5,"_75":386,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":388,"_71":-5,"_75":389,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":391,"_71":-5,"_75":392,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":395,"_71":-5,"_75":396,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":398,"_71":-5,"_75":399,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":401,"_71":-5,"_75":402,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":404,"_71":-5,"_75":405,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":407,"_71":-5,"_75":408,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":411,"_71":-5,"_75":412,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":414,"_71":-5,"_75":415,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":417,"_71":-5,"_75":418,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":421,"_71":-5,"_75":422,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":424,"_71":-5,"_75":425,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":427,"_71":-5,"_75":428,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":431,"_71":-5,"_75":432,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":434,"_71":-5,"_75":435,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":438,"_71":-5,"_75":439,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":441,"_71":-5,"_75":442,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":74,"_43":444,"_71":-5,"_75":445,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":448,"_71":-5,"_75":449,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":452,"_71":-5,"_75":453,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":455,"_71":-5,"_75":456,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":458,"_71":-5,"_75":459,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":461,"_71":-5,"_75":462,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":464,"_71":-5,"_75":465,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":467,"_71":-5,"_75":468,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":470,"_71":-5,"_75":471,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":473,"_71":-5,"_75":474,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":476,"_71":-5,"_75":477,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":479,"_71":-5,"_75":480,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":482,"_71":-5,"_75":483,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":485,"_71":-5,"_75":486,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":488,"_71":-5,"_75":489,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":492,"_71":-5,"_75":493,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":495,"_71":-5,"_75":496,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":498,"_71":-5,"_75":499,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":501,"_71":-5,"_75":502,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":504,"_71":-5,"_75":505,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":507,"_71":-5,"_75":508,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":510,"_71":-5,"_75":511,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":513,"_71":-5,"_75":514,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":516,"_71":-5,"_75":517,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":519,"_71":-5,"_75":520,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":522,"_71":-5,"_75":523,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":525,"_71":-5,"_75":526,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":528,"_71":-5,"_75":529,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":531,"_71":-5,"_75":532,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":534,"_71":-5,"_75":535,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":537,"_71":-5,"_75":538,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":540,"_71":-5,"_75":541,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":543,"_71":-5,"_75":544,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":546,"_71":-5,"_75":547,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":549,"_71":-5,"_75":550,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":552,"_71":-5,"_75":553,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":555,"_71":-5,"_75":556,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":558,"_71":-5,"_75":559,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":561,"_71":-5,"_75":562,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":564,"_71":-5,"_75":565,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":567,"_71":-5,"_75":568,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":570,"_71":-5,"_75":571,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":573,"_71":-5,"_75":574,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":576,"_71":-5,"_75":577,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":579,"_71":-5,"_75":580,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":582,"_71":-5,"_75":583,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":585,"_71":-5,"_75":586,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":104,"_43":588,"_71":-5,"_75":589,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":591,"_71":-5,"_75":592,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":595,"_71":-5,"_75":596,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":598,"_71":-5,"_75":599,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":601,"_71":-5,"_75":602,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":605,"_71":-5,"_75":606,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":608,"_71":-5,"_75":609,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":611,"_71":-5,"_75":612,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":615,"_71":-5,"_75":616,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":618,"_71":-5,"_75":619,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":621,"_71":-5,"_75":622,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":625,"_71":-5,"_75":626,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":628,"_71":-5,"_75":629,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":631,"_71":-5,"_75":632,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":634,"_71":-5,"_75":635,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":637,"_71":-5,"_75":638,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":640,"_71":-5,"_75":641,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":643,"_71":-5,"_75":644,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":74,"_43":647,"_71":-5,"_75":648,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":651,"_71":-5,"_75":652,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":655,"_71":-5,"_75":656,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":658,"_71":-5,"_75":659,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":661,"_71":-5,"_75":662,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":665,"_71":-5,"_75":666,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":668,"_71":-5,"_75":669,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":85,"_43":671,"_71":-5,"_75":672,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":81,"_43":674,"_71":-5,"_75":675,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":74,"_43":678,"_71":-5,"_75":679,"_73":74,"_88":-5,"_89":-5,"_90":-5},{"_80":74,"_43":682,"_71":-5,"_75":683,"_73":74,"_88":-5,"_89":-5,"_90":-5},"publicChapterContent","nextChapter","sections",[847,848,849,850,851,852,853,854,855,856,857,858,859,860,861,862,863,864,865,866,867,868,869,870,871,872,873,874,875,876,877,878,879,880,881,882,883,884,885,886,887,888,889,890,891,892,893,894,895,896,897,898,899,900,901,902,903,904,905,906,907,908,909,910],"routes/_store+/_layout","routes/_store+/_readers+/_layout","actionData","errors"]

\nCE#9 Developer’s Guide

Table of Contents

\nPreface

\nDistribution Permission

\nForewords

\nDisclosures

\nDisclaimer

\nWorkbook Content

\n> For Patrons from Amazon and other Book Distributors

\n> About this Workbook

\n> How to Read & Use this workbook:

\n> Viewing the eBook:

\n> External Links

\n> References Used

\nYour newly obtained skills …

\nMore Resources

\nProgramming Courses

\nPart I — Concept & Design

\n1 “Code-less” Game Design

\n1.1 Game Genres Defined

\n1.2 Demand for Abstract Games

\n1.3 Game Delivery Modes

\n> Mobile “In Apps Purchases” (IAP) ROI

\n1.4 Game Tools & Generators

\n> The Digital Ludeme Project

\n> Ludii General Game System

\n2 Combat Engine Designs

\n2.1 Engine Considerations

\n> Determining Successful “Hits”

\n> Determining Inflicted Damage

\n> Combination Experiments

\n> “Now What!” — Answering Our Question #3

\n> Summary

\n2.2 So, Give Me Some Space …

\n> Deeper Dive: Melee Weapons

\n> Deeper Dive: Ranged Weapons

\n2.3 Rules of Engagement: Take 5 paces, turn and …

\n2.4 Yo bro, give me some skin …

\n> Creating an Avatar’s Visuals

\n> Creating an Avatar’s metadata

\n2.5 Been there … done that …

\n2.6 Finite State Machines (FSM)

\n> FSM Resolving Combat Outcomes

\n> FSM Resolving AI behaviors

\n2.7 Recursive World Feedback

\n> Probability Data Tables

\n3 Project Management Overview

\n3.1 “Loose lips sink ships” … and revenues!

\n3.2 Game Recipe™ just add Artwork, stir, & season to taste!

\n> Conflict Resolution & Victory

\n> Deeper Dive: Developer’s Right or Left-handed Bias?

\n3.3 Development:

\n> Step #1: Understanding “Human Limitations” & Requirements

\n> Step #2: The “Elevator Speech” & Description

\n3.4 Design:

\n> Deeper Dive: Putting Background Stories in the Wrong Place

\n3.5 Construct’s “Code-less” Encoding

\n> Deeper Dive: Creating Display Mechanisms — a 4-Step method

\n4 Part I: Conclusion

\nPart II: Starting a C2 Production\n

\n5 C2 “Combat Engine” Project

\n5.1 About Your Project

\n5.2 Project Settings:

\n5.3 Configuration Settings

\n5.4 Design Considerations: CMS, PWA, or SWPA?!

\n> Creating a C2 SWPA Game Version?

\n> Creating a C2 CMS or PWA Game Version?

\n5.5 Season to Taste …

\n5.6 Comparing your code

\nPart III: Starting a C3 Production\n

\n6 C3 “Combat Engine” Project

\n6.1 About Your Project

\n6.2 Project Settings: Color Theme, Start-up & Display

\n6.3 Configuration Settings: Advanced & Editor

\n6.4 Design Considerations: CMS, PWA, or SWPA?!

\n> Creating a C3 SWPA Game Version?

\n> Creating a C3 CMS or PWA Game Version?

\n6.5 Season to Taste …

\n6.6 Comparing your code

\nPart IV: Combat Engines (CE)

\n> The Workhorse — “`es_ce1Config`”!

\n> “`es_Common`” Event Sheet

\n> “`es_swordPlay`” Event Sheet

\n> “`AdminConfig`” Layout

\n> “`es_adminConfig`” Event Sheet

\n> Sample “`es_splashLang`” Event Sheet