This project is why ive started going over the GCE rules, im sure i will be asking for more clarification as needed.
Im pasting in my post from over on reddit since i think its more relevant here:
So yeah, im trying to make GCE a playable computer game, the above was as far as i had gotten when i made that post.
Since that post ive reworked what i had for the movement phase by separating out the mechanic for actually running actions into a reusable component which the actions of further phases can hook into.
Now im into the Shooting Phase, specifically target nomination:
Ive got a system set up to raycast against a 3x3 point grid from shooter eye height to the collision cylinders of units within the 90 degree forward angle of the potential shooter.
This is an abstraction, rather than using the actual visual mesh of the "mini", im setting all "models" up with a shape, to and from which mechanics are worked out.
If none of the 9 points can be "seen" then the unit is out of line of sight. Excluded from being a target.
If less than half can be seen then its in cover. Returns -2 to hit.
If more than half can be seen then its in partial cover. Returns -1 to hit.
If all are seen then its in the open.
This, combined with the several other modifiers described in the rulebook are mechanically worked through to figure out which is the most obvious target.
It shows the total modifiers, without weapon range modifiers, for hitting a target so the player can pick what to shoot at.
The system will highlight the easiest to hit target in red, if there are other valid options according to the ruleset, then those get orange markers and can be chosen for shooting at.
This is what it looks like zoomed in from behind the possible shooter, the red marked Mr Boss is out in the open but further away than the selectable Slaver in partial cover behind the wall.
Next step is making weapons actually roll to hit.
Im pasting in my post from over on reddit since i think its more relevant here:
So about that video game version that never came out? There is now another one that might never come out.
There was recently a post over on the GM facebook group about the Dreamcast/PC Gorkamorka game which never came out.
It looked to be developing towards a racing/combat game.
Neat, i did play the demo and i would have played its released version, but it was not really Gorkamorka in anything except its theme/skin.
So what would i like to have seen in a Gorkamorka video game?
Gorkamorka, obviously, a faithful representation of the tabletop game playable on my computer with gang creation, handling of the mechanics, campaign xp/skill/injury tracking, multiplayer etc.
I dont know how to code/develop video games, however, with the buzz about "Vide Coding", which is explaining to an AI what you want and it attempting to code that for you:
Ive decided to take a shot at making the Gorkamorka video game i want.
Im using the current version, 4.6.1, of the Godot engine and started with just copy/pasting to/from the Godot Editor in free Grok/ChatGPT sessions, waiting for resets when they ran out, and have moved on to using Visual Studio Code via the Godot plugin and the free tier of Github Copilot(which ran out, im now on the free Pro trial).
Here is the unflashy state of it after about two weeks:
Basic Mob creation.
Loading a Mob and managing the gangers.
Picking two Mobs, starting a fight and going as far as i have gotten.
Its very rudimentary, lacking in vehicles and only goes up into the movement phase this far but it is actually doing something![]()
Ive converted part of Gorkamorka Community Edition and the Gorkers and Morkers faction pack into less than perfectly structured .json files in a folder structure for the start of the "GCE datapack".
What is actually working pregame:
Creating a Mob of a chosen faction (and if available, subfaction) which gets granted 100 teef to spend.
Recruitment of gangers with d6 random XP added, unless they are Yoofs (have a starting XP of 0).
Mob validation, only lets you recruit a Nob if you dont have one, needs to have a Nob to recruit other gangers, allows yoofs up to the total number of other orks, allows grots up to the total number of orks if there is one or more Slaver(s) in the mob.
Moving gangers up and down on the roster.
Renaming gangers.
Buying them more equipment.
Moving equipment from a ganger to the gang stash.
Moving equipment from the gang stash to a ganger.
The mob rating calculation.
Saving and loading gangs.
All gangs, gangers and their equipment are tracked via unique identifiers.
Picking saved gangs to put in a fight.
Scenario selection which sets the ingame pre fight steps based on the .json file of the chosen scenario.
And ingame:
WASD camera movement control and QE for rotation, hold RMB to freelook, with a clamp on pitch between horizontal and vertically down, mouse scroll wheel for camera height.
Setting the size of the "table".
Placeholder phases for: setting up terrain and generating a random amount of scrap counters to be placed.
Actually rolling off to see which gang gets to pick their deployment zone and the opposite being assigned to the other gang, in accordance with the scenario file.
Deploying gangers within their deployment zone, with units snapping back to the closest valid location as determined by the deployment zones given in the scenario file.
Movement phase:
Selecting a ganger.
Picking a movement phase action.
Move->Ganger faces towards the cursor, click where you want to go, the ganger moves towards the point you clicked, up to its M stat, hold left mouse down to have the ganger face towards the cursor so you can set which way its facing when letting go of the mouse button, sets the "has moved" property.
Run->Same as above but double its M stat, sets "has run".
Charge->Lights up valid targets, the closest one which is not down or pinned and closer ones that are, without regard for actual movement range so you have to make a judgement call about if the ganger can reach(like in the tabletop game), clicking a target turns and moves the ganger towards it, sets "has charged" on the charging ganger and "In hand to hand" on it and its target if successful, sets "has run" if failed and allows for turning to face like a run or move action.
Each phase and functional action are obviously their own milestones but the first big goal is to make it possible to roll through a one off hotseat-style local multiplayer game with just the basics of moving, shooting and fighting on a flat empty table with victory conditions set by the scenario, nothing fancy like special rules or tracking of xp, going on.
The main pipe dream is to actually have it run a computerized version of Gorkamorka Community Edition with visually customizable gangers that have representations of their wargear, tracking of xp, advances, permanent injuries etc and playable over the internet with one player hosting and another (or more) bringing their Mob(s) to fight.
With the option for using GorkGo-MorkGo/alternating ganger activation for less extended waiting periods.
So what about the name of the project, the generic terms used in the UI/this post and why did you say "GCE datapack"?
I have a pompous name in mind, which im leaving unsaid for now.
That name is another pipe dream in itself but im trying to build this project to be a modular and data driven engine.
That far off idea is that if one makes a compatible "datapack", when it comes to the basic main ruleset (2nd ed 40k), like for example OG Necromunda, Mordheim or Shadow War: Armageddon, they would slot in and run.
Im obviously a veery looong waaaay off with lots of stuff to figure out but the process this far is actually pretty fun and engaging so ill see where i eventually end up.
So yeah, im trying to make GCE a playable computer game, the above was as far as i had gotten when i made that post.
Since that post ive reworked what i had for the movement phase by separating out the mechanic for actually running actions into a reusable component which the actions of further phases can hook into.
Now im into the Shooting Phase, specifically target nomination:
Ive got a system set up to raycast against a 3x3 point grid from shooter eye height to the collision cylinders of units within the 90 degree forward angle of the potential shooter.
This is an abstraction, rather than using the actual visual mesh of the "mini", im setting all "models" up with a shape, to and from which mechanics are worked out.
If none of the 9 points can be "seen" then the unit is out of line of sight. Excluded from being a target.
If less than half can be seen then its in cover. Returns -2 to hit.
If more than half can be seen then its in partial cover. Returns -1 to hit.
If all are seen then its in the open.
This, combined with the several other modifiers described in the rulebook are mechanically worked through to figure out which is the most obvious target.
It shows the total modifiers, without weapon range modifiers, for hitting a target so the player can pick what to shoot at.
The system will highlight the easiest to hit target in red, if there are other valid options according to the ruleset, then those get orange markers and can be chosen for shooting at.
This is what it looks like zoomed in from behind the possible shooter, the red marked Mr Boss is out in the open but further away than the selectable Slaver in partial cover behind the wall.
Next step is making weapons actually roll to hit.