Action game production · Combat acceptance
Game Combat Design: Define Attacks, Counterplay and Acceptance
Before commissioning more weapons and enemies, agree what an attack permits, what warns the player, how a hit resolves and what creates an opportunity to respond.
Game combat design defines how players and opponents act against one another: available actions, attack conditions, targeting, timing, hit rules, feedback and counterplay. For someone commissioning an action game, the deliverable is more than a list of weapons or damage values. It is a playable set of rules that lets a reviewer explain why an attack happened, whether it should have connected and what the player could do differently.
Make this system a named part of your Unity game development scope. Separate designing the combat rules from producing models, animation, effects and a complete campaign. These tasks connect, but a polished weapon model does not demonstrate a working hit rule, and one enjoyable encounter does not establish that every opponent has been implemented.
Start with the decision the player controls
Describe the intended interaction before requesting a large arsenal. Does the player aim manually, prioritize targets, move out of danger, block, time an ability or manage ammunition? Decide which responsibilities are automatic and which remain deliberate. Automation can reduce touchscreen demands without removing meaningful decisions, provided the remaining choices are understandable.
In our ROADFORGE case study, automatic primary fire works alongside steering, positioning and limited special abilities. That is one production example, not a prescription for every action game. A different camera, input method or genre may require a different allocation of attention. Record the chosen camera and controls in the review conditions.
The game design document keeps shared product rules together. A combat specification develops those rules into individual attack behavior. The level design guide owns where challenges appear and how a route unfolds; this guide owns what an attack does wherever the approved system is used.
Give each attack a short behavior card
Write the conditions that permit the attack: actor state, valid target, range, line of sight where relevant, resource availability and cooldown. An animation beginning is not necessarily permission to damage a target. Identify when the target is selected, whether aim continues tracking and whether the action can be interrupted.
Separate the cue, commitment, active resolution and recovery. During the cue the player receives information. At commitment the agreed choice becomes fixed or follows a specified tracking rule. The active part applies the hit logic. Recovery limits what the attacker may do next. Not every game needs the same phases, but any exceptions should be intentional rather than consequences of unrelated scripts.
| Part | Agreed rule | Review question |
|---|---|---|
| Permission | Only a living, available opponent may start against a valid target. | Can a defeated or disabled actor begin another attack? |
| Cue and commitment | A visible cue precedes a charge toward the position selected at commitment. | Does the charge unexpectedly follow a later player movement? |
| Hit resolution | The active charge may damage each eligible target once; the recovery phase cannot. | Does overlapping the target repeatedly apply the same attack? |
| Recovery | The opponent finishes the agreed recovery before another charge. | Can a new attack bypass that recovery or a cancelled action resume? |
This card is an illustrative specification, not a reported ROADFORGE configuration or a passed test. Durations, range and damage remain project decisions. Giving an example precise behavior does not make its values universal balance recommendations.
Make counterplay visible in the actual camera
A threat should give the player the information required by its intended response. If the expected response is repositioning, check that the warning appears before the relevant decision is no longer possible. If cover matters, review the protection rule as well as its appearance. If an attack is intentionally unavoidable, state the mitigation or resource decision instead of promising a dodge that does not exist.
The GDC Creating Conflict session overview connects scenario goals, implementation and cover arrangements. Those relationships matter when reviewing whether a mechanic supports the intended situation. They do not supply a universal timing value or prove that a particular combat build feels fair.
Observe the player's view, not only the editor view. Effects, interface panels, enemy overlap and camera motion can hide information that is clear in isolation. Record whether the player noticed the cue and understood the result. “I was hit without knowing why” deserves investigation; it does not immediately prove that damage should be reduced.
Review hit logic separately from visual impact
Decide what counts as a hit and who may receive it. Projectile collision, a swept test, an area query and an instantaneous trace have different implementation needs. Specify friendly-fire behavior, damage immunity, shielding, repeated overlaps, target destruction and attacks crossing scene boundaries. The team should select an implementation that preserves the agreed rule, not quietly redefine the rule around whichever effect is easiest to display.
Unity's collision detection guidance describes trade-offs between accuracy and computational cost, including different modes for fast-moving objects. A buyer should request evidence that the chosen approach handles the agreed combat cases on target hardware. Turning on a more expensive mode everywhere is not a substitute for testing, nor does one physics setting solve every targeting problem.
Keep the accepted result separate from its presentation. Damage should not occur twice because both a projectile and an effect report impact. A defeated actor should not remain a valid source of new attacks. Visual and audio feedback should communicate the actual outcome, including blocked or rejected hits where that distinction matters.
Test a baseline before tuning variations
Choose a known loadout, opponent configuration, arena, camera and build. First check the basic rule with one opponent and one attack. Then add controlled variations: moving targets, different ranges, interrupted actions, simultaneous threats and the supported weaker device. Changing several variables together makes it difficult to distinguish a balance decision from an implementation defect.
For the hypothetical charge, review starting out of range, losing the target before commitment, moving after commitment, overlapping during the active phase, defeating the attacker and restarting the encounter. Record the expected result before running each scenario. Results stay pending until the actual build has been observed; a checklist is a plan, not evidence of success.
Progression can change the experience without changing the attack's underlying correctness. Use the economy specification for upgrade and resource assumptions. When comparing combat outcomes, identify which equipment state is being used rather than treating an upgraded player as equivalent to the initial baseline.
Accept the system and receive its configuration
Request the attack cards, editable configuration, reviewed build, relevant observations and unresolved limitations. Distinguish a broken agreed rule from a preference for different timing or intensity. A change request should name which behavior changes and which scenarios need another review, rather than simply asking the team to “make combat better.”
Multiplayer adds a separate question: which authority accepts the hit when devices disagree? Use the multiplayer planning guide to scope that boundary instead of assuming an offline combat proof establishes network fairness. Release readiness also needs broader checks; our mobile release checklist, in Arabic, covers that gate without replacing combat-specific review.
Before expanding enemy and weapon production, confirm that another configuration can use the accepted system without hidden code changes. Receive the source and parameter documentation under the agreed scope. Acceptance of a combat increment is not proof of universal enjoyment, retention, all-device performance or complete release readiness.
Game combat design questions
What should game combat design specify?
Specify player actions, attack permission, targeting and commitment, cues, active hit rules, interruption, recovery, counterplay and outcome feedback. Record camera, controls, loadout assumptions and review scenarios. Separate these rules from producing weapon assets and arranging encounters across a campaign.
How do you accept a game combat design before production expands?
Review a named playable build from a known loadout and opponent configuration. Check the basic attack, then vary range, movement, overlap, interruption and simultaneous threats. Compare observed results with written rules, retest bounded revisions and receive editable configuration and limitations before ordering a larger arsenal.
Commission combat with rules you can review
Send your game concept or current Unity build, platforms, camera, control scheme and the combat systems you need. We can discuss an implementation scope with playable review checkpoints, explicit exclusions and organized source handover.
Explore game development services · Discuss your game · Send the brief on WhatsApp