Making a tank in Stormworks. I've programmed the regenerative braking, which is quite simple. It is very effective on a tank, since it uses brakes for steering and 50 tons has a lot of energy to store.

How the motor should work in response to driver inputs, saving the engine (due to low RPMs), and smoothing out the power delivery... More complex.

The engine has enough power to accelerate pretty well, but diesel engines disadvantage in tanks compared to turbines is that the jet can deliver very high torque, allowing (say) an Abrams or T80 to accelerate from stationary much faster than their diesel equivalents. Thus, hybrid tank.

Main cases:

• starter. Probably the simplest case, the motor gives power until the diesel gets to ignition
• Saving the engine from stalling: keeps the RPMs above ignition until the engine's controller catches up to the situation. Needs a safety cut-off in case something is jammed to prevent damage.
• driver wants to accelerate. WS controls, should turn off when clutch is disengaged for gear changing (no torque converters, sorry)
• sudden dips in RPMs when there is no driver input. Sudden hills, rougher terrain. Not to prevent the RPM from going down entirely, but to provide smooth running while going over rough terrain.

One thing I am finding is that the diesel engine is very hard to tune if I do any of these, so I should probably do that first before doing anything but the starter case.

The motor on its own can rolling start the tank pretty well

A reply someone sent to me a while ago that annoyed me enough to respond. The vibe I got was: “Dune Spice Wars is just a palette swap of Northgard” with the implication that the devs are lazy and greedy for developing a game that is extremely similar to their previous game (asset flipping, I guess).

I hadn’t played Northgard at the time, but did watch the trailer. Northgard was on sale recently, so I gave it a shot after having played a bunch of Spice Wars.

Because this has bitten me in the ass a few times on hexbear, here’s a short list of things I’m not arguing in this post: Game Publishers aren’t using DLCs or low effort new games games as low labour sources of profit. Obviously, this is the case. Artist and programmer hours down, IP rent up is endemic to the games industry. The devs are “good”. I actually have no idea, I just think this particular charge was unwarranted. Dune: Spice Wars or Northgard are good. Idk, I’ve enjoyed at least one of them These are the two most different games, nay, nouns in human history. They are not. Idk why, but in my region of the world “completely different” gets used for “actually very similar, but legally distinct”. Comes up a lot in these sort of nitpicky nerd circles Devs are always right, publishers/critics are always wrong

Here is a short list of ways in which the two games are similar: Same engine Same genre (so, trad RTS, selecting units, giving them orders, building up an economy to ensure a healthy supply of units to defeat opponents in a roughly similar situation to you) Region-based mechanics (building limits, buffs, privileged starting zone etc) Diplomacy mechanics Variety of victory conditions rather than hunting down every last power plant

Having now played at least some of both, these games feel substantially more different than many other pairs of games from similar devs that don’t get targeted like this. The main differences I’ve found: What players spend a lot of their time doing. Northgard heavily preferences micromanaging of the core unit (peasants), whereas Dune feels more like a trad RTS with Northgard characteristics. Northgard feels more like a village building game that also happens to be an RTS. Personally, I find the removal of peasant micromanagement a substantial improvement and one of the more annoying aspects of Northgard (especially annoying because it takes up a lot of the game) Mechanics present in Northgard are tightened and simplified substantially in Dune. This makes sense as Dune comes after Northgard and the devs have had time to hone down what worked in Northgard. For instance, scurrying around with scouts and trade relationships in Northgard is now just a single interface in Dune where you can manage your relationships etc. This does make relationships with other factions in Dune a little bit simpler, it’s not necessarily “better”. Different resources. Obviously, the relationship with these and things you actually do can change with a button, but neither are just “Money” and “population”. They both have these, but Dune Spice Wars isn’t being accused of being a palette swap of Age of Empires or Act of Aggression. No permanent Alliances: My experience with Northgard’s diplomacy was everything generally felt more permanent, whereas Dune has much more ebb and flow (as well as a limited set of hostile actions you can perform on allies). There can also only be one winner per match (two minds about this personally, I like allying with my friends and stomping on the computer, but it does change the diplomacy part of the game a lot). Less factions, greater faction differentiation. Given Northgard’s bread and butter was making lots of small DLCs with minor player factions, I feel like making a different game with both less factions but more content per faction is important.

Beyond those, there are a lot of smaller changes that it would be weird to go over. There’s a couple of mechanics that are sorta tacked on (e.g. the Landsraad council/influence stuff) that are different, but I hope you get the idea.

I have played a lot of different RTSes and I would say that mechanically these two games are more different than C&C and Tiberian Sun, or C&C and Red Alert (two pairs from the pre-DLC times), Age of Empires and Age of Empires 2 (an example from another developer), Medal of Honour 1 and Call of Duty 1 (a pair of games from different developers with two different engines) etc.

I don’t really know why this annoyed me so much that I had to make a post. It might be touching on an extreme anti-DLC reaction that seems to want every single game to be entirely new despite most studios not having the resources to hire a network engineer every time they want to make a new game. The idea that a group of artists might commission a game engine (big, expensive, requires network engineers etc) and then write stories in that game engine (small, cheap, within reach for a group of artists) and not starve is apparently obscene.

It always seems to get deployed as a "The West are the only true innovators" and ignored if its like... The Islamic golden age or whatever. Also like some Arabian merchant couldn't have seen a steam train and gone "Oh, that's a good idea", it required colonialism to get ideas like plumbing etc. all over the world.

Bleh

Hey, I've just finished my diploma of mech eng and them and my new workplace use largely solidworks. Solidworks might have the most annoying subscription service integration I've ever seen, but also I've clicked with its interface.

Any guides or tips for switching over?

So, a while ago I was in a community theater and we put on plays that would break even largely. Our biggest costs were theater rent, followed by specialist hires (a worker with safety training that did our ropes and high powered electrical stuff). We charged pretty cheap tickets in the context of theater, which given the majority of our actors, costuming and props labour etc. was volunteer.

It got me thinking about games. I realise there is an intense dislike of DLC, particularly AAA companies doing day 1 DLC, but even longer term DLC that could not have been made on the budget of the original game and released like a year later or whatever.

The idea was having a platform for, say, RPG systems that's well coded, slick, bla bla bla, and comes with a few base stories, but after that the majority of development after that is done by something similar to the theater group but indie artists, writers etc. and you buy into a long form RPG (or, idk, subscribe on patreon or whatever). Every month (or whatever), some sub-team releases a new part of their adventure or a new system with a new adventure, and you can keep playing with what characters you had before (if that's what's happening).

Things like the Adventurer's Guild (or whatever the D&D one is, where you register and play each adventure bit once alongside thousands of other players) are a thing, this would wind up be something similar but system agnostic and more tech oriented.

IRL, every time a community theater wants to do a show, they don't rebuild the theater and stuff. It's not "wholly original".

I'd also want the writers/artists to be more connected to their community, hypothetically.

The system would have to have very non-coder friendly tools for writers to pull together systems and make maps and stuff. Dialogue trees may be a bridge too far.

Just got this email from one of the event ticketing place some of my friends use

(Um, I don't know why your post triggered me into writing this pitch for a wishlist game. Maybe the minecraft with guns bit? idk, I got excited) (repost, as this is enough crap for its on top level post)

I have this pitch for a builder game where you're a military procurement/engineering firm. The LoD would be about what Stormworks has (25cm blocks, or maybe 20 or 10 cm), you spend time fiddling around with air fuel ratios and RADAR etc. You'd be able to fiddle with various war nerd numbers on vehicles you create, but there wouldn't be much for you to do with the vehicles directly. Instead, you teach bots how to use the vehicle (some sort of waypointing system, some vehicle tests like turning, acceleration etc etc). After that, your vehicle and usage data is compiled and a little war goes on in the background. Hypothetically, this war would be happening on another screen or you could refer to it. Because the vehicle is compiled into this RTS mode and not run as a physics simulation (or at least, would be run as a very cut down simulation), that section would be quite light. Possibly multiple layers to examine (strategic, operational, tactical). Your vehicles would have logistical strain (e.g. fuel, maintenance/wear, damage from fire etc). You'd probably want to define a few other variables on how its used (e.g. This is a TANK, GENERAL PURPOSE, SWARM or something). I don't think it would be possible for an AI to account for all ways people would design vehicles and use-cases, but the basic classes are pretty standard nowadays, and people could request things that feel plausible to the dev.

A few reasons for doing it this way:

• Having it so that the vehicle is tested by itself on multiple predictable scenarios means the physics simulation (e.g. denting, beams bending etc) can be more detailed, and allows for more complicated vehicles.
• Once its "compiled" so that the bots can use it, it will run quite light (this is sort of explored in From The Depths, but not to its fullest extent). This couldn't take into account everything possible, but hopefully the bots would use things intelligently (e.g. using cover, grouping tanks, screening etc)

You'd watch combat and take notes on what works well and what does, and work on new designs as the war gets under way. Your new designs that you produce and test would percolate through the logistics system and slowly start appearing on the front.

There'd also be a little thing where you could define your squads that the AI uses in the war (e.g. 12 dudes, 1 command, 2 fireteams, each fireteam has a LAW and 5 assault rifles, command has 1 commander and 2 machine guns etc), with some reference to real world stuff. This would obviously be important for transport vehicles and logistics.

There'd be a mode where you'd have to do it "in real time" (i.e. no pausing for designing), a more freeform creative mode where you can design and save freely without worrying about wars and launch battles with your vehicle instantly, and a thing where you could compile all of your designs into a faction. Presumably, the game would ship with a few real world referenced factions, people could mod in their own ones. And people could also mod in maps that the AI will fight wars on, and opponent factions (of varying degrees of fairness). Tutorial mode, build a truck that carries a squad. It's an electric truck so you don't have to program a gearbox.

It's probably a bit beyond me as a coder (maybe, idk, the primary time I was trying to learn coding was when I had pretty severe depression), but maybe as a fresh godot project if applicable? I think it would absolutely kill amongst a certain sort of war nerd.

Um, comments, I guess. Obviously extremely ambitious on my end, it will probably be another half-started project in my collection :(

One of the first cards is planting corn.

I didn't make it. We made it.

idek if 7zip is better than winrar anymore assuming both are being updated constantly, but like... My memory is that pretty much every tech oriented person on windows uses 7zip.

News thread IFV project, made in stormworks. Not wholly functional, but enough so that it's going to look the same regardless.

Role: Transport, Medevac, amphibious, anti-air, anti-drone, fire support

Features/design choices:

• Fast on both land and calm waters. This vehicle is more on the "truck" end of IFV rather than "tank". The vehicle spends most of its time ferrying troops around. Can stop small-arms, light munitions, and shrapnel, with armour focused on the crew/passenger compartment.
• Twin 40-mm autocannons, loaded with fragmentation rounds. Can be loaded with AP rounds, but is primarily there for knocking missiles, planes, and drones out. Obviously infantry are going to be threatened by two autocannons as well.
• Side doors. This means that troops can dismount if the vehicle is moving in a column and parks end-to-end. The doors open up, giving cover to evacuating troops. There is a small window for troops to look out of before trying to disembark. This can be a safety issue if hydraulics fail.
• 8 Wheel design is substantially cheaper, faster on roads, and is mildly bouyant. This does mean that the vehicle's cross-country performance suffers, especially in thick mud and other extreme adverse conditions. As a general purpose vehicle to improve infantry's mobility in most conditions, the 8 wheel design was chosen over tracks. It also allows the bulge in the middle, increasing transport capacity.
• 2-frequency RADAR tracking. The vehicle can track aerial targets, and the turret can lock on to a specific target. The gunner can then trim the RADAR output to lead appropriately. I'd code something here, but I'm lazy.
• Turret actually poorly armoured. This helps with balance in water. The primary purpose of this vehicle is to transport them. All the ammunition for the turret is separated by armour, meaning that if the ammo cooks off the passengers and crew are safe. Locating the bulk of the ammo in the turret means there is enough additional space to include light medical facilities.
• Exhaust is dumped behind the rear wheels, which spreads out the exhaust and makes it harder to lock on to with heat-seeker weapons.

Tac notes:

• This is designed to be used as part of a general mechanisation program, not specifically for specialist troops. The idea is to have so many light-air defence systems in a battle space that opposing aircraft, drones, and cruise/tactical missiles will be unable to operate.
• In a pinch, the twin 40s can rip up urban fortifications. However, this is not their primary role. Certainly they shouldn't be used as a preliminary bombardment tool, rather one used for emergencies or particularly good targets.
• Remember that side doors need about an extra meter of clearance to open, so tight streets should be avoided especially for dismounting.
• This vehicle wound up being fairly short. While this makes the vehicle harder to detect, the presence of drones makes this less important. However, lower height makes the vehicle more stable in hilly terrain or in the water. It also means cover against direct-fire weapons (esp. HEAT missiles, which can be tripped by brick walls etc) is easier to find.
• Doctrinally, this is a truck with armour, amphibious capability, and firepower. However, it is likely to be able to defeat most other transport vehicles other than heavy IFVs. A single one of these is capable of extremely disrupting supply lines.

Room for future features:

• Drone launching platforms can be mounted on the front-side slanted armour, with opening hatches like the rear ammunition storage bins.
• There is enough space in the vehicle for a small command centre.
• Missiles could be mounted on the turret pretty easily. Small AA missiles or ATGMs.
• Multiple outlets for exhaust could be used for different situations. For instance, an exhaust outlet underneath the hull to reduce detection chances, and an exhaust above the hull for amphibious operations.
• More electronic warfare options.

Things I had to work around because the game only has 25 cm blocks

• The turret would be a lot flatter IRL. The combination of having to have 25 cm blocks for armour and 25 cm blocks for mechanics means the whole thing is a lot taller. The same goes for all the camera systems.
• I'd probably fit more med-beds in the crew compartment. While they're not in use, troops can dump bags and stuff on them (and just have more leg room).
• With a lot of the space savings from having a maximum of 50 mm RHA instead of 250 mm, I'd probably include a commanders section.

Thoughts:

• So, one of the reasons the Bradley IFV is so big while only transporting 4-ish soldiers is that their turret basket extends the whole height of the vehicle, creating a big space in the middle which I assume is for ammunition storage or a gunner. Obviously, if it's moving around, passengers can't sit there.
• Yes, it looks sort of like a stryker or BTR. How many different shapes could an IFV/APC possibly have?
• The Germans claim the Puma (I think) can stop 125 mm rounds from the front, which sounds optimistic. I didn't bother with that capability.

Anyway, this was a fun exercise.