Of course, there were hundreds of different standup arcade games, utilizing different hardware, and different developers creating software for them using different tools. So, there's no "one-size-fits-all" answer to your question. Rather, there were some general-purpose low-level ways of doing development back then that were fairly universal.
First, early arcade games were programmed using machine language. The only "offline" tool that might have been used to free the developer from encoding opcodes by hand would be a simple assembler. It was not unusual for early processor vendors to provide a cross-assembler for their processor, and that could run on common mini or micro computers of the time. Therefore, editing of the initial assembler source, and automatic conversion to machine code, could be done on a more advanced computer than the processor used in the arcade game.
Second, the developer needed to be able to test their code. In some cases, they may have done that in a simulator while they were still working to finalize the custom hardware that would go into the arcade game. More likely, they tested their code on a prototype of the arcade game hardware. This meant that hardware and software were being developed and debugged simultaneously, which is hard. Thus, it was common practice for arcade game vendors to settle on a specific hardware platform, and then use that same hardware for as many arcade games as possible. This was common practice at least as far back as Pac-Man in 1980.
Getting the machine code onto the hardware for testing could be a minor challenge. In some cases, EPROMs might need to be burned and plugged into the arcade board. More likely, the prototype development hardware would include a mechanism to download the target code using something simple like an RS-232 or JTAG port connected to a development computer. It's not that different, at least in concept, to how embedded software development is still done today.
In most cases, besides having extra development aids like RS-232 ports, prototype hardware could also include special software on ROM to provide a monitor program. This would allow the developer to do things like insert breakpoints in the code and examine memory in order to track down bugs. If the prototype was more advanced, then an In-circuit emulator (ICE) may be available to simplify the debugging process by relying on additional hardware besides just the target CPU abilities. But even simple 8-bit CPUs of the time, like the MOS 6502, supported break point (BRK) instructions that could invoke a resident monitor program.
All in all, the process was not very different than the bootstrapping of any software onto any new hardware that was done for other computers of the time. And, to a pretty large extent, the same techniques are still employed today. It's just that off-the-shelf components are much more available and advanced now than in the early days. This frees modern developers from having to reinvent the wheel on such low-level tooling for compiling, assembling, downloading code, testing, and debugging.