Link to video:
Table of contents:
0:00:00
Jeff was one of the Lead Engineers for Supcom (not FA)
Jeff worked on Secret of Evermore, TA, other games, Azurik, Supcom, other game, Microsoft, Google, Oculus
Recently made hand tracking on VR - you can move your hands without a controller
0:02:36
Jeff took over as Lead Engineer, 2 years into production
They had started with C# then changed to C++,
There was lots code but no gameplay
Were going to use a single texture to skin every unit
Had procedural terrain
0:07:02
They added lua
Because the publisher EA cancelled the contract
They had to knock up a demo in 2 weeks and lua took care of that
Lua wasnt for mods but had some advantages
Scripting with C++ is possible instead but has disadvantages
Lua can be slower but you can call out to native code for intense stuff
Lua was tricky when you save the game because they had to save the lua call stack
0:18:33
TA had a very different network synchronization model
0:20:34
Supcom they introduced a new network model, sim, order queue, determinism
They had issues with determinism because maths libraries behave differently on different cpus
But there are advantages like replays, low network traffic, reduce percieved latency by scheduling commands
Determinism has been around for ages, probably C&C, Age of Empires, and before that.
Without determinism, latency causes issues in game experiences
One game uses prediction to reduce percieved lag, but you need to be able to rewind the sim
Supcom could rewind using todays hardware
0:33:34
PA uses a central server model where the sim runs on the hosts machine
It punishes players with latency but you can compensate by adding artificial latency
But you need a solution for when the host leaves
The server can be on a 3rd party site
Its more flexible
PA server reduces traffic by telling clients only what they need - dont tell them about offscreen units. Dont tell them low level details about far away units.
If the bandwidth is struggling you can drop details.
They normally have a chunky sim layer of physics and a detailed clientside layer of cosmetic physics.
0:40:19
If he built another RTS, Jeff would...
- follow PA network model
- use something like LUA
- make a custom engine because its fun, but you could use Unity or Unreal
in RTS simulation is a bigger aspect than other genres
Supcom came at a time where engines weren't quite the standard yet
if you don't implement determinism development becomes much easier, can use simple libraries
you can dynamically pick if server or client does processing
you could make Supcom in Unity and it would be easier
you can solve performance issues by calling out to native code
C# can be competitive against C++ if written a specific way.
(Jeff worked at Microsoft advising how to port games to C# )
0:48:35
TA and Supcom used A* for pathfinding
TA used wall hugging to speed it upp
Supcom had heirarchal A* with 8x8 blocks to work out if blocks connected
Jeff would use flow field for next RTS - cheap, nice
Flow less good on some maze maps
Flow less good down when units go against flow
Supcom does google map search for each unit
Supcom 2 had flow field
0:54:27
Supcom has formation path finding where units maintain distance from leader (biggest unit)
They have union of capabilities (formation wont hover even if some units can)
Units try and pathfind to their offset from centre but if that isnt possible quickly, they pathfind to the formation centre instead
0:58:33
Multicore cpus were new when supcom came out
They had a sim thread and ui thread
The simulation was based on the Previous sim state
The ui layer had a copy of the several sim states
Ui thread would push edits to command queue, which is what the network needs
There was some pathfinding in other threads.
Pathfinding changes over time as buildings level terrain.
They dropped more realtime terrain changes due to infeasability, but there is code to handle it.
A few other things moved into threads, but not many.
Today you could harness more cores.
You would split it vertically so each core handles a certain amount of units.
Because units read off previous-frame-state, order execution wouldnt break determinism.
You wouldn't split processing horizontally because you can't harness N cores.
Although its good from a cache point of view.
When you are mission scripting you don't want to think about vertical order.
The system could dynamically work out how many threads to spawn based off cores.
1:11:44
making an indie supcom sounds possible
using a server centric model ditches determinism which allows use of easy solutions
Jeff wants to make his own game
if you want to give him 10's of millions of dollars, that's ok.
nuke ocean = tidal wave = kill coast
Supcom was not meant to be about micro, the units were smart
Jeff liked automation like queueing orders, patrol
Jeff wanted the base-automation to be greater
Jeff feels like he is not so good at the micro
Jeff wanted to add shift-click order queuing to TA and he was told not to, but he went rogue and did it anyway and THANK YOU, Jeff
In a new RTS Jeff would add more automation
He would like to use machine automation to train units
- Training bots to play against you
- Offline, to train your own units to work for you, being able to delegate "repair my base" to your helper-AI
- Developers training AI to play against you
- Train AI against itself
- AI that adapts to your tactics
1:22:25
Jeff wanted an offline mode where you design bases, then just deploy them
Jeff wanted AI to autorepair his base
The AI would prioritise certain repairs
The Player would be able to tweak priorities
You could train your machine learning AI assistent, and delegate him jobs
You could actually make a mod to do this already
AI will do silly things sometimes and in a non-serious game it works
1:27:44
Not everyone on the same page on supcom team
There were two main schools of though: focus should be on good skirmish or good campaign?
Perhaps they spent resources on the wrong things
Someone wanted to make tutorial videos which costs a lot but bakes in things to you cant change them
Not everyone on supcom was sailing in the same direction
Chris helped pull things together
You need a good communicator to pull things together
1:32:36
Jeff played a bit but feels like he isnt that great at it
Stopped playing when had kids
Sandbox mode is good for kids, TA didn't have that
Dungeon Keeper was annoying cos you would win and couldn't build anymore
Minecraft fixed this
1:35:16
Jeff left supcom happily - he just liked the concept for the next game
Gpg struggled - not getting the programmers they wanted
Jeff was pushing for Unity or another engine, but Chris wanted an engine
They spent a lot of time building generic engine stuff
Jeff left games out of frustration
1:37:04
Jeff was Lead Developer for a while but had kids, demoted himself to Architect.
Chris H was Lead - then Jeff - then John Mavor
There were 4-6 programmers
Mavor did graphics
William did all the tricky bits (deterministic sim, lua saveload)
Bob Berry did lots
Daniel & Jeff did AI
Elai was engine components
There were others engine programmers as well
Then there were other Game Design Implementers doing map scripting & balance, unit scripting
1:41:19
About building the map renderer
Mavor made most of the map rendering
Jeff did bump map lighting + height map
There was terrain quad tree LOD to reduce terrain triangles, which removed middle vertexes, some technical details on seams and popping in
In a first person game that would be harder
Jeff enjoyes tricky code like that
These days you could do it on the graphics card, much easier
You can fake extra detail now
Shadows were added later but once again it's easier from top view, with technical details. Once again it's easier in Unity now
They source algorithmns from publications, GDC, reference books, mentions some other places
If we built a map renderer today, we might stick with decals-texture-heightmap
We could add ways to bend textures around overhangs
You could make a shader to automatically switch textures based on vertical-ness
1:49:43
Jeff thinks we should allow mods, even if it allows cheating a bit
Modding is good for players
You could argue to have no-mods when competitive
They hash-check the sim layer, there could be a way to enforce no-ui-mods by checksum
If they put cheat countermeasures in - it would be spyware and they don't want to do that
Google Stadia reduces the ability to cheat because player PC doesnt have the game info at all (just a video stream of it)
You can still use macros
1:53:51
Factory attack move reclaim is a bug!
Jeff knows cos he made it.
1:55:27
LuaJIT would improve performance
They had trouble syncing c++ and lua reliably with stock-lua, so they modified LUA - which means you cant just substitute LuaJIT in
Jeff realised he could have solved it in stock-lua with a weak table
In FA they tried to use LuaJIT but it was too hard.
It would be much faster with LuaJIT - all the lua scripting would speed up as LuaJIT compiles lua into native code
Normal Lua is pretty fast but maybe we could see 10x speed increase with LuaJIT
1:59:46
Jeff is not sure why range rings are slow - perhaps too much texture memory
Today you would do it totally in the shader
But there are better ways to do it on older hardware - Signed Distance Fields
It's nice to work on a team to get ideas how to do things - easier than searching
2:02:53
Lua classes should have been restructured to have no inheritance
Could have just had mixins
Maybe the could be a table of unit capabilities
Inheritance is bad - consider other options
2:07:30
There was a Debug module that was dangerous for players - they shipped with it on one time
2:10:30
There were some critical decisions
The move to determinism
Ideas like walking ships - Chris systematically has these ideas
2:11:55
Representing scale is tricky
Scaling units up doesnt always make it feel bigger
2:13:23
In a new RTS they could have bigger scale (10,000 units)
Would probably keep the rectangle map because it's easy to play on
Would keep the random events that happen in a sim
Would add the offline battle plans - design playbook of orders for execution
Would add drop in/out multiplayer
Would be nice if unit behaviours were learned
Visually you could do a lot
Perhaps experimental scale could be grander
Could have a meta game
Could do better physics
FAF had a meta game for a while but it's gone
2:24:25
Game balance is tricky
2:25:12
We don't get dumps on desync because we don't have the debug version
2:25:50
They didn't actually do integration tests
Today it's easier with cloud
Tests can be a burden or not
It's possible to do it great
Code quality != success
One of the engines he made was great, but didnt make $
Other bug ridden games make mega$
Its good to organize code so unit bug = weirdness, not crash
Jeff is happy that almost every game he worked on actually shipped
2:31:08
Jeff wasnt big on estimates for Supcom
He is quite good at making them after he has developed the feature
The estimates were there from the start (before Jeff started)
But it was still open to interpretation
2:32:45
The campaign/metagame focus debate
Didnt affect Jeff's work because the engine needed the capabilities anyway (scripting)
In Forged Alliance they had a clearer picture
It's easier to FA because the engine was there
TA also had an expansion pack that benefited the same way
2:34:54
Fans are making their own rts
Jeff thinks it's viable for a few guys to make an RTS
It's so much easier with an engine
You could get a good result hiring Unity artists
Engines are great
2:37:05
Jeff doesnt have the source code
ASF desyncs are also Jeffs fault
2:38:23
If you wanna play the new Seraphim campaign come to faforever.com
We still have players new and old = we get new players all the time
Add your questions in the comments
