GCE - Im trying to make it a computer game.

Wurrkop

Juve
May 28, 2016
35
46
18
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 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.

fLd4aeJ.png


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.
 
  • Like
Reactions: Biggle_Bear
Wish you all the best in this. Sounds like a really cool project.
 
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.

fLd4aeJ.png


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.

Not sure if you’re aware but your images are not viewable in my region (UK). Would be cool to see them!
 
Ive been working on the line of sight and pinning mechanics, ive currently got the unit typ for gobbos in the data but they display as orks since thats the only model asset ive put in.
So now im poking about with creating a base gobbo so i can properly visualize it to set its size relative to orks for the purpose of line of sight and properly knock the weedy gitz over.

Im starting from https://www.thingiverse.com/thing:7090899
And have tweaked one of the stl models to look like this by pulling in hands with actual fingers, adding a fifth toe and modifying the nose and ears a bit:
0Z4Hr1K.png

I fed that screenshot into Qwen edit running locally on my gaming rig and asking it to remove the wristbands+background and "colorize it as an unshaded game character reference, it is a goblin with green skin, red eyes, crude dirty canvas pants and a leather belt", which has returned this image after a couple of tries:
dkwknRN.png

Then i took that image and fed it into trellis2, also running locally, and this (after several tries to get 5 toes) gave me a textured 3d model that ive pulled back into blender and it looks like this at the moment:
SIPe8mX.png


The topology and UV maps are pretty bad, its what one gets when generating models so that will need some cleanup but at least its looking like a decent place to start for doing so.

Not sure if you’re aware but your images are not viewable in my region (UK). Would be cool to see them!
Are you on a VPN?
Imgur sometimes has issues with those, try using another endpoint/server within you region.
I get the same issue sometimes on NordVPN here in Sweden and a switch or two of servers sorts it for me.

Wish you all the best in this. Sounds like a really cool project.
Thanks dude, im very surprised with how easy its been this far.

Ive yet to write a single line of actual code, just changing some values and references.

The coding LLMs are pretty smart, what im doing is trying to make my instructions/prompts clear and easy for them to understand, quite a lot like aligning RAI and RAW in tabletop terms.

Ive noticed that they tend to make large scrips so ive had to stop them a few time, or rework large scripts to break out parts as callable subscripts so the project remains maintainable by telling them to abide by coding terms like "DRY"/Dont Repeat Yourself, "SoC"/Separation of concerns for splitting stuff into reusables and having them only handle one thing.
As well as asking them to tell me when im touching upon or going against game dev best practise and patterns so i can realign them to follow such.
 
Last edited:
No I’m not on a VPN. Your images are just always purple boxes!
Just read up on it and apparently Imgur started blocking UK user access due to UK's Online Safety Act (not wanting risk fines for not complying with the regular "but think of the children" bullshit) about six months ago.

There are already inline browser extensions which will fetch imgur content via proxies.

The vids and pics are up, UK users just need to go through a hoop or two :p (which will also restore functionality for other places that links imgur hosted content)
 
Last edited:
The actual geometry and topology of the generated teeth are unusable so im making new ones soon.

Until then, i present: Gummy the Gobsmacked Grot.
okgMzwe.png
 
Last edited:
Okay, got Gummy reworked to have much better topology and a UV map one can make sense of.

The generated original one is up top, the reworked one below:
hsRzSL1.png

And without the selection highlights:
pRFFjBa.png


For those unaware of 3d stuff but interested: The red lines are the "seams", where ive decided to place virtual cuts so that the surface of the model can be unfolded for texturing.

Here is the 'lil guy without overlays and with a fresh new belt buck, the generated and remeshed ones were really bad so i whipped up a replacement.
rSFORPd.png


Far from professional but good enough for me.
 
  • Like
Reactions: Biggle_Bear
Lotsa progress over this extended weekend.

Still in the shooting phase but:
LOS for detecting cover now seemingly works properly.
Units that can get pinned get knocked on their front when hit, will try to escape pinning if conditions for doing so are met at the start of the player turn, otherwise unpinning happens in recovery.
Hits inflicted roll to wound using their S vs target T, if there is armour then saves are rolled for, conditional modifiers for flak and shields, weapons with save positive modifiers (bow and blunderbuss) work so presumably negatives ought to work as well, though i dont yet have any vehicles in and havnt gotten to H2H so havnt tried it.
Unsaved wound roll on the injury table, flesh wounds strip WS and BS to OOA if both reach 0, down puts the model on its face and only allows it to crawl during movement, OOA kills/despawns models with a simple sinking into the ground animation.
Move or Fire for Crossbows works
Kannons induce knockback resistance tests on hit, if failed the model moves away from the shooter.
Sustained Fire Dice implemented so for example Six-Shootas pick a target, if the SFD roll is 1 then it just fires at the single target, If SFD=JAM! then do an ammo roll, if its 2 shots or more there is another step to allow distributing shots to other models within 4 of the target and within LOS of the shoot, then the shots resolve.

I think thats most of whats gotten done the last couple of days.

Tonight ive been working on Stikkbombs, single target mode works as other weapons, target and fire.
Frag stickbombs have a preview of the template centered on the target, on hit each unit inside it are hit, partials on 4+, rolled automatically and hits resolve as other hits do.
Target ground works, a preview template is centered on the mouse cursor so the player can put it where they want, rolls to hit the clicked position with -1 for small target and resolves template hits as above.

Next is making the miss/scatter mechanics but thats gotta wait until after work "tomorrow", gotta get up again in about 3.5 hours but a had an accidental nap from maybe 5pm to 10pm so ill be alright.
 
Last edited:
Mostly got grenade scatters working with a small effect for visual indication of WHERE.
Added multi damage hit handling to remove wounds and/or roll multiple times on the injury table.
Add small effects to models shooting or getting hit.
Cleaned up the output to the battle log.

Shooting a bunch of over armed gangers at each others to look at what happens:
 
  • Like
Reactions: dabbk
Ive put some more time into the project since the last update.

The Movement Phase has been split up into three subphases, the first only allows for charging, the second will contain compulsory movement after those mechanics are built and the third is as ive shown before, minus the declare charge action.

Ive added obstacle avoidance so that gangers move around each other instead of through and can not end their movement intersecting each other.
There is now a preview of where they can move during regular movement (not shown for declaring charges since range is a judgement call there)
After initially having issues with the avoidance i figured out a way to do it by skimming along virtual points placed around other units and finding the shortest route along those points. Thats apparently Dijkstra's algorithm and commonly used in all manner of things.

Made krak stikkbombs scatter, added a small visual explosion indicator for where kraks go off so players can go "Phew!" on narrowly avoided scatter hits.

Implemented the start of the H2H phase, as there is only local hotseat multiplayer for now ive made a split weapon declaration interface, left side for the ganger of active player, right for the inactive.
Both players get to pick which of their available weapons to use in the fight, with first and second options for gangers with multiples, this matters when it comes to separating strikes per weapon in case of an odd number, the first gets the odd strike.

Most of the base HTH mechanics work:
Roll Attack dice, pick highest.
Add WS and bonuses for charge, critical, opponent fumble.
Compare, inflict the difference amount of strikes on the loser.
Initiative comparison on equal combat score with 1 strike to the winner, draw if equal I.

Next is to work out how to properly handle outnumbering.
 
maybe relevant but I just saw that mrmodulork on minifactory had gorkamorka stl (human and ork)
 
maybe relevant but I just saw that mrmodulork on minifactory had gorkamorka stl (human and ork)
His stuff is great, especially the multi part stuff thats more modular than just headswaps ;)

Couldnt use it though since his stuff is licensed as BY-NC-ND.
The ND part means "No Redistribution" so if i based stuff on his, like converting minis into models for use in this project, i couldnt share them.

The Grot stl i used is BY-SA, SA meaning "Share Alike" which requires redistribution if something has been based on it, the model ive made to use in the project will be included and reusable by anyone under that same license.
 
  • Like
Reactions: Hobo86
I shared it as an inspiration source,
but now thinking about it, he could be open to some cooperation if he get advertisement for his (pretty good) stl range?
 
I shared it as an inspiration source,
but now thinking about it, he could be open to some cooperation if he get advertisement for his (pretty good) stl range?
I did actually consider hitting him up earlier to ask about access to some of his multipart stuff in exchange for promoting him ingame but figured id do some of my own for the testing phase.
Ive sorta settled on not wanting to go beyond what i can make myself, already available free-use, attribution or share-alike without negotiating with anyone to start with since id prefer there to be no stronger strings than that yet.
Im also not certain this project is actually going to get completed and dont want to waste anyone elses time/effort by having them deal with me yet.

A still far off idea is that it should be possible to individually customize gangers by swapping legs, torsos, head, arms, etc as well as having a couple of options for sluggas, choppas, shootas, etc to be able to make visually distinct gangs.
This is where nicely made multipart models would come in but im not actually sure if it would be worth it to try to convert the printable files into usable ingame models, it requires quite extensive re(w)orking in blender, as well as "painting"/texturing the models.

Ive been looking some at ways to do this, in current day video/computer games, non-hard surface/organic characters are usually built to deform, the visual mesh follows a skeleton, with parts stretching and joints bending.
What ive thought would be neat, and more achievable for a single newbie maker such as i am, would be going the route of earlier generations of 3d models, think from around N64 or PS1.
Those use separate shapes which are attached to a skeleton and were allowed to intersect at the joints, not actually deforming.
Im thinking it might be simpler to do that and have different parts modeled and just individually switching which version is visible.

The grot on the left is rigged with automatic weights, you can see his hips and chest deforming with the movement and that requires a bit of manual cleanup.
The grot on the right is segmented, torso, upper arm, lower arm, leg, each of the visible bones control one part.

This below might actually be more than i do for a release version, it might just be head, arms, torso, legs, like 3rd edition ork plastics, that would probably be enough, though id want weapons to be possible to swap in, so not attached to hands.

j8hmJEU.gif


Im thinking ill eventually be making a simple base system for animation.
An armature/skeleton would have a couple of different poses.
An idle with three or four poses, like looking to the left, looking to the right, hefting a weapon, stuff like that.
A move cycle with three frames, left foot forward, right foot forward, center of step with both feet parallel during the motion.
A shoot animation with taking aim, fire and recoil.
Melee windup, strike and back to neutral with either weapon.
The animation player would tween (smoothly transform) between the poses/frames as the actions are taken to give a bit of stylized life to the gangers, not looking to build fully interactive lifelike animations for everything.

Having it be simple like this would allow for others to relatively easily build their own drop in assets later on too.

As for actual progress on the project today:
I have multiple on one outnumbering fights mostly working, a check is ran to see which ganger is engaged with which, if there are overlaps then the gangers get grouped as an outnumbering fight, selecting either of them in the hand to hand phase brings up a selection for which outnumbering attacker is to fight.
Attacker and defender get to declare weapons and combat between them is resolved.
If the defender is still standing, then the UI for selecting attackers opens up again with attackers that have not fought being selectable.
The declared weapons of the defender are locked to their previous pick, new attacker declares weapons, bonus A and combat result to subsequent attackers in accordance with the rules,
Rinse and repeat.
 
Last edited:
  • Like
Reactions: Hobo86