To make a dedicated server build, I have to build from engine source, which takes a long time, because the engine is huge.
To make a client build that can connect to that dedicated server, AFAIK I have to build from that same engine source in a different build configuration, which effectively means building the engine twice.
If there’s a bug or iteration that needs to happen, I need to rebuild both the server and client, from source, again. This is a really long turnaround (currently ~2 hours on an extremely fast machine).
I don’t see a way of avoiding that. But 2 hours suggests a complete rebuild - unless you’re changing one of the very core engine headers, which seems unlikely, then subsequent rebuilds should be very quick. I’d look into if and why the whole engine is getting rebuilt each time. What approach are you taking to initiate the build?
I have to go back and forth between building from source (for dealing with this dedicated server stuff) and building from an installed build of the engine (for distributing a game code binary to the rest of the team). Each time I switch contexts, it seems to invalidate all my intermediates, even though it really shouldn’t. This class of problem has been an ongoing issue which TBH has really soured me on this engine overall (see here).
I may just need to check out two separate copies of the game project and associate one with the installed build of the engine used by the rest of the team, and associate the other with my local source build. (LOL say goodbye to free HDD space…)
The installed build is going to expect certain Timestamps / CRCs on all the intermediate files, so if you’ve changed those via a manual build - it’s going to complain and want to rebuild everything.
The solution is to treat the installed build vs the manual/dedicated server build as two separate projects (install is “stable”/“released”/whatever, and the manual is “dev”/“unstable”/etc). Honestly I’d setup a build pipeline that allows team members to either push / request a new installed build / automatically does it nightly.
This may be of no use to you, but we automate building server and client using Jenkins on a separate pc on our network. That pc also hosts our svn server and the source version of the engine.
We have to rebuild the souce version each time a new engine update comes out, but other than that, the process is rather painless. Each team member just keeps a packaged version of the engine on their pc or laptop and uses svn to update their working copy and commit changes.
Getting a packaged version of the client is automated through our WIP game launcher. The only part of the process that we have yet to automate is uploading the .zip files to our online servers.
Yeah, I’ve set up something similar in our office (albeit less sophisticated, due to time constraints). Getting a packaged version of the engine built and distributed to the team is relatively painless (it’s just slow). The only real problem is just me, on my own dev machine, having to ping-pong between that version (for regular gameplay dev) and the source version (for server-specific dev).
Part of the pinch there is that I build the engine on my own machine; I have a build script that automates the process, but I still have to fire off that script, and it still eats up all my system resources for a long time while it builds. That’s a combination of an infrastructure problem (we need to get a new PC that can be a dedicated build machine) and a time problem (I need the available dev time to provision and configure such a PC once it arrives).