#dev kits

I think it depends on what you mean by "large teams". For most dev teams, the need for dev kits varies on the role of the developer. Artists and animators, for example, don't really need their own dev kits - a group of artists can share a dev kit or two because they really only need to verify that their work looks proper in engine when they are nearly finished. The ratio of time spent using the dev kit to validate their work compared to the time spent doing that work is small.

Programmers, on the other hand, more often need to debug directly on the console in order to track down bugs. At one point, I was working on a multiplayer system and had to commandeer two other dev kits (for a total of three) in order to test out my synchronized animation system. I had built a system for one player to grab and choke another player to death. The three dev kits were needed to make sure that the killer, the victim, and the observer all played their respective synchronized animations properly on their monitors at the right locations and angles. I don't have a dev kit now; I verify my work on the PC build of the game I'm working on. My boss told me early that they'll give me a dev kit if I need one, but the need hasn't arisen yet.

QA usually uses test kits instead of dev kits - these are usually slightly weaker development machines that can play development builds but lack the extra memory and beefy hardware that the dev kits have in order to run debug builds. Test kits are significantly cheaper than dev kits.

From what I remember, most studios get an allotment of dev and test kits based on their need and the team size. The leadership then gets to figure out who gets them. The turnaround is usually a question of getting everybody involved to sign the appropriate legal contracts and such, and then getting the process approved by Sony. I've never worked on that part of sourcing, the team leadership usually just had the dev kits ready for us when we needed them. On occasion a dev kit gets bricked and needs to be replaced and that usually takes a couple of weeks. That's all I really know about the actual sourcing aspect of dev kits.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Short questions: Ask a Game Dev on BlueSky

Long questions: Ask a Game Dev on Tumblr

It isn't terribly technical, but I don't have a dev kit at the home office at the moment so you only get some of my old photos of dev kits from my previous employer today. A console dev kit is a lot like a networked computer fused with a game console. It has beefier hardware than the retail console (because it needs to be able to hold and run debug builds of the game). It has USB ports for controllers/keyboards/peripherals, network ports to connect to the network, and the usual video outputs to display to TVs. They also have a different version of the console's operating system for development stuff - they allow us to do things like reset achievements, change locale, connect to PSN/XBL/SwitchOnline, and other various features. Dev kits physically look like this:

Because they act like remote PCs, we can do things like upload builds to them over the network, and we can remotely connect our debuggers to those executables while running for debugging purposes. Game consoles today typically have plugins for Microsoft Visual studio to handle the remote debugging process. Programmers will build the debug version of the game on their workstations, transfer it to the dev kit, and run it on that hardware. Their workstations then connect to the dev kit's running game process remotely and attaches the debugger to it so they can see things like breakpoints.

Most designers, artists, and QA don't usually have access to (or understanding of) code, so we don't get the remote debugger attachment. Instead, we're usually limited to in-game debug menus, tools, and displays built by the programmers to verify our changes. This is why so many have some kind of "developer console" within the game, some kind of text interface that can run a bunch of different commands. Those text interfaces exist so we can access debug commands. Before we could do that, we had to use controller button combinations. You may know of them with their more common street name - "cheat codes".

We usually have two kinds of kits - the more expensive dev kits with more memory and hard drive space to handle the development process, and the less expensive test kits that are closer to retail hardware specs but use the development software provided by the platform (Sony, Microsoft, or Nintendo). Neither of these can play retail games, they only play development builds. They also require a developer account and license from platform to actually do anything, so obtaining one without platform's permission won't really do a lot of good to anyone.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Some random dev kit trivia:

Dev kits can’t play retail games at all.

Dev kits have much bigger system specs because we have to be able to run debug builds. Debug builds are much less optimized because of all the debug information that’s kept in memory.

Dev kit software can do a lot of things like simulate online and/or disc latency, handle remote network connections, record game screenshots/video and controller inputs, and profile resource usage.

Current gen dev kits require you to provide Sony/Microsoft with a whitelisted IP address. They won’t work if you aren’t connecting to the dev network without a recognized IP address. This has caused a lot of problems due to everyone working from home. Before the PS4 gen, this wasn’t the case - we could take our dev kits home if we wanted (and the company let us).

There’s the beefy (and expensive) dev kit, and then there’s the less beefy (and cheaper) test kit. Dev kits have more features and better hardware.

There’s a separate developer’s version of PSN and Xbox Live networks. This is so we can do things like test network stuff, locale, achievements, etc. without them going live

Most of the time, the company is very careful about dev kits because they cost a lot. I’ve had dev kits chained to my desk before.

When we had family events at the office like Halloween trick-or-treating, we had to cover up all of our (still under NDA) dev kits so children and family members could not see them.

The Xbone’s Developer Mode Activation does not actually turn your Xbone into a dev kit. It still has the retail hardware specs and it doesn’t have all of the features or access to the special dev network.

Last gen dev kits are a lot cheaper than the newest ones. You can probably get a PS4 or Xbone dev kit for under $2000 now.

Cheers!

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted. [What is the FANTa project?]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

There is no danger, really. All dev (and test) kits must log on to PSN with a developer credentials in order to authorize and update, and only Sony grants those. Further, you can’t obtain the developer software tools without those developer credentials either since you have to log in and download them from (you guessed it) the developer’s version of PSN. Dev kits also can't play retail games. Further, if somebody did try to use the dev kit to connect to PSN (to get the development tools and activate the kit) and Sony didn’t authorize it, they would be able to track the dev kit’s ID to who the original owner was and how it got into the wild. The only thing somebody could feasibly do with it is maybe install Linux on it and run it as a very expensive Linux computer. However, all of the actual PS5-specific functionality of the machine is basically useless without Sony’s blessing. 

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted. [What is the FANTa project?]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Yes, we get different revisions of the dev kits as time passes and platform changes things, but those system spec changes aren’t that big a deal. Dev kits are always beefier than retail consoles because they need more resources for keeping debugging symbols and the like in memory. Even if they adjust the specs for the retail console down for whatever reason, the dev kit will still have significantly more resources built into it because it needs them. Allow me to explain in a bit more depth. Let’s get into the difference between a Debug and a Final build.

In order to transform programmer code into a program that runs, we must feed the code into a compiler (and a linker). The compiler/linker combo translates the C++ code we’ve written into a machine-language executable that the computer can run. During this process, it can strip away a lot of bits that are unnecessary for the computer, like human-readable words and such, commonly referred to as symbols. The machine doesn’t need these symbols to run the program and removing them means the program needs less memory to run since it doesn’t have to load or track those symbols. Since it doesn’t have to track the values for those symbols, the program also runs a lot faster. This is great for the final product - we want it to run as fast in as little memory as possible, so it makes sense to strip that unnecessary data out.

Unfortunately, having no symbols makes it extremely difficult to debug problems because all the human programmers have to look at is a bunch of memory addresses and values with no human-readable labels. We don’t know whether this chunk of memory at this address is a character’s level, a world position, or part of a texture that was loaded, and that’s important when we’re trying to track down bugs. Without symbols, we’re basically operating while blind. To get around this, we can compile the program and have it include all of the human-readable symbols so that we know what’s what, but this will significantly increase the amount of memory the program needs to run in order to load all of the symbols in addition to the machine code. Not only does it take more memory, but it also takes longer because the CPU has to run both the program and track all of the symbol data. This means that debug builds run much slower than final builds, because the CPU is running all of the diagnostics on top of the program itself.

This is the biggest reason why dev kits need significantly more system resources than retail consoles - they have to be able to load all of these debugging symbols and information without crashing. No console manufacturer is going to send us dev kits that aren’t beefy enough to handle this task; otherwise the console would be nigh-impossible to develop for. This also means that we never develop for the dev kit’s system specs, we develop for the retail console’s system specs. The retail console’s specs are almost always locked in stone by the time development on a game for that console gets started, even if it’s a launch title, so we don’t really have to worry about that.

PS. We don’t have only “debug” and “final” builds, we usually have a middle-ground called “release” that strips most of the symbols out for more speed and lower memory footprint. These different types of builds also create a nasty breed of bugs called “release-only” and “final-only” bugs where the aberrant behavior happens only in release or final builds - without the debugging information available. Those bugs are pretty tricky to track down and fix because of the missing info. Almost every experienced developer out there has horror stories about some nasty final-build-only bugs they’ve had to track down.

Are you in Professional Game Dev? Please fill out the [Anonymous Salary Survey]!

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted. [What is the FANTa project?]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

In order to obtain next-gen dev kits, the biggest publishers often meet with the platform representatives and negotiate a deal far in advance. This is the sort of thing that starts at tradeshows and events - not on the show floor with the press and the fanfare, but in private meetings behind closed doors while the other parts of the show are going. Platform’s goal is pretty simple - secure pledges for games that will sell the console. They are looking for buy-in from as many of the biggest third-party AAA publishers as they can to get big budget games to help sell the new system. This generally means Activision-Blizzard, EA, Ubisoft, Take Two, Bandai-Namco, Square-Enix, Sega, and Capcom. The bigwigs secure a deal over time and move forward with the delivery of the dev kits to the publishers.

When it comes to handing out dev kits internally, it always goes in terms of priority. You need your core tech software engineering experts to lay the foundation for everybody else before you start giving them to the people on the game team(s). Core engineering is the internal group of senior software engineers that’s tasked with building and maintaining the publisher’s core technology, the common foundation code that most of the publisher’s games are built on across most/all of their studios. They always gets the first prototype dev kits to learn how the tech works and start building the software foundation for the publisher. They’re the ones who get the first things working - controller inputs, rendering, sound, networking - all of the necessary fundamental stuff - and package it up into the programmer API that the individual game teams will use to develop the projects on the platform. This code foundation can then be used on multiple projects.

After core engineering has enough kits to lay the foundation, you start handing them out to the game team. Engineering, art, and design teams each get at least one dev kit in order to validate work being done (usually taken by the leads), but the individuals on the team are handed dev kits on an as-needed basis. Engineering typically has the biggest need - most programmers each have at least one dev kit in order to test their code changes. Design usually comes in second (often having to share kits) and art is a more distant third, typically with an entire group of artists sharing a single kit. Production doesn’t normally get dev kits because they don’t typically need them - they aren’t touching the game itself, they’re greasing the gears to keep everybody else working. The only exception is generally the executive producer, who gets one because she’s in charge of the whole project. QA also doesn’t get dev kits, they get test kits - cheaper, less fully-featured machines designed to run development builds.

Since dev kits need to be built and manufactured, it’s very common that we don’t get as many dev or test kits as we need initially. The dev kit specs aren’t necessarily finished when we first start to get them. We’re often given a handful of prototype kits at the start with a promise of more eventually. New kits arrive over time as platform improves their production process, fixes bugs, and iterates on their initial designs. It isn’t uncommon to have multiple generations of dev kits scattered among the dev team over the course of launch title development. 

If this all sounds a little haphazard... well, that’s because it is. They’re building the new console while we’re building the game, so it shouldn’t be a surprise that there are unfinished parts here and there, both on the hardware and the software side of development.

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted. [What is the FANTa project?]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

New Post has been published on https://www.aneddoticamagazine.com/the-pinephone-development-kits/

The PinePhone Development Kits

The goal of the PinePhone is to provide an open, affordable (the end-user phone is targeting a price of $149), upgradable and modular, privacy-oriented mainline Linux phone for those who desire or require this particular feature-set. To be clear;  this is an announcement of the dev kits and not the end-user device (although, by extension, it’s also an announcement that a phone is in the works and scheduled for production sometime this year). Everything written henceforth refers to the kits specifically, but you can infer most of the phone’s functionality from what is written below.

The kit – internally codenamed Don’t be Evil (kudos to those that understand the codename)- will be produced in a limited supply because its meant for developers only.

New Post has been published on https://www.aneddoticamagazine.com/the-pinephone-development-kits/

The PinePhone Development Kits

The goal of the PinePhone is to provide an open, affordable (the end-user phone is targeting a price of $149), upgradable and modular, privacy-oriented mainline Linux phone for those who desire or require this particular feature-set. To be clear;  this is an announcement of the dev kits and not the end-user device (although, by extension, it’s also an announcement that a phone is in the works and scheduled for production sometime this year). Everything written henceforth refers to the kits specifically, but you can infer most of the phone’s functionality from what is written below.

The kit – internally codenamed Don’t be Evil (kudos to those that understand the codename)- will be produced in a limited supply because its meant for developers only.