What do the PRO Developers use to create thier games?

CLRH2O · Post by **CLRH2O** » Sun May 22, 2005 11:26 pm

I did a quick search for Cave, 8ing, Joker Jun and a few other longer strings but came up with nothing in the dev forum here... so:

What development software and hardware are the big dogs using?

When 8ing/Raizing set out to create Battle Bakraid or Seibu Kihatsu was gearing up to start production of Viper Phase 1 what were each software developer given for each machine to run to do their work. The GFX guys what did they use - the Hit Detection and Movement path guys what did they use - the Audio and SFX guys, what did they use?

What about when Zero Gunner 2 was created - same thing. Espraid, Ketsui, DoDonpachi and DoDonpachi III, Ikaruga, Border Down.... For 2D and for 3D - from any developer... G-rev, 8ing, Cave, Psikyo, Raizing, Siebu, Takumi....

We all know about Multimedia Fusion and Game Maker for the little guys.... But what about the REAL DEAL stuff the big guys use?

I've been a GFX designer working for myself since 1997 - I've created everything from CD covers and Magazine covers to websites, interactive CD-Roms and 3D video animation for Live events, TV and independent film.... But in the entire time I've been playing games right on up through the whole of the 80s, 90s and now the 00's I've never heard what the big guys really use to make their games with –you would think someone with my own deep knowledge of at least the pixel pushing end of things with such a long and deep love of video games would have heard something of what they use during the past 20 years…. But no, not really.

When I searched for some info of the dev platform given out to Dreamcast developers I found out it was a system called "Katana" and that it was a combination of both dedicated software packages for each part of the design process and a custom built PC machine for those package to run on with a GD-Rom Burner for prototyping. But that's a VERY vague explanation of just what exactly the game creators were given to work with.

Sure, I'm CERTAIN Photoshop is core program for the GFX teams - some flavor of video editing software that can use a custom codec for compression and playback of video/multimedia files in the native format (for a particular games hardware setup).

Hmm - I wont go much further with just one post here but bear with my stream on consciousness for one more second as that last point brought me to yet another question.

For the programmers - is there a "PRO" version of something akin to a Multimedia Fusion or Game Maker program that is modular in some way, or uses plug-ins that let's it compile it's game data into the form needed for a myriad of different CPU and DSP chip setups? Obviously the code compiled for say Cyvern (on the Kaneko Super Nova system) wouldn’t play back properly if put on EPROM’s and mounted to a Seibu Kaihatsu's SP1 pcb motherboard.

AHHHH - so many questions. Any words?

landshark · Post by **landshark** » Mon May 23, 2005 1:57 am

I would be very suprised if anything but C/C++/ASM was used by developers in the field.

Alot is probably based on prevous libraries/routines/games they have written, not often starting from scratch.

Possibly versions of codewarrior? I think they are at least involved in the console industry. Not sure about PCB.

raiden · Post by **raiden** » Mon May 23, 2005 4:59 pm

for console development, C++ has been the norm for about 10 years now. If you´re patient and willing to spend a lot of money on them, you can find old devkits for sale on sites like Yahoo Japan. Those devkits include several tools and get new revisions over the life of a console.
There are a few hardcore guys who still go deep into the hardware with ASM, mostly to develop new engines which get licensed out afterwards.

For PCBs, I´d like to know more, too. But from the CPU speeds, you can gather that they probably still use ASM, as C++ would be too slow. At least for the old-fashioned boards, things like Namco systems or Naomi are probably fast enough for C++. Type-X anyway.

captain ahar · Post by **captain ahar** » Mon May 23, 2005 5:12 pm

assembly is scary.

landshark · Post by **landshark** » Mon May 23, 2005 8:31 pm

captain ahar wrote:assembly is scary.

bahhh

nullpointer · Post by **nullpointer** » Mon May 23, 2005 11:09 pm

yeah i agree..
asm for custom sprite routines, especially when using older boards.
and C++/C for everything else.
Most Naomi based games (DC stuff as well of course) will be written in C++, I expect with type x it will be the same idea.
Photoshop will also be standard GFX editing, with maybe some more pixel based editors (for the more traditional cave style gfx)
To be honest, cave have probably used a very similar (slightly updated) version of their engine for every recent project
Most dev teams will also write custom software (in C++ again) for level layout and bullet pattern/enemy layout

CLRH2O · Post by **CLRH2O** » Wed May 25, 2005 5:44 am

So with each dev team essentially writing a custom sprite moving, bullet patterning, background scrolling engines to display everything on screen and calculate the maths for collision, hit points and timing in very likely Assembly Language - and then adding new features like expanded color palettes and higher on-screen sprite amounts as new types of DSP chips enter the market and are subsequently purchased by the developer for inclusion on a built to order PCB - and all of this is created for each new game by building off of the last code base from the previous game.....

Then - where do the original programmers who are writing in Assembly get the feature sets for each new DSP or CPU chip that they can choose from to solder onto their next hardware board revisions? I suppose the manufacture of each chip provides that info in like feature tables to people who would actually know what to ask for?

My My, this is so out of my league! LOL

And applogies in advance for the HORRIBLE grammar and run on sentances there - I'm just streaming out again

landshark · Post by **landshark** » Wed May 25, 2005 6:23 pm

i'm still guessing most of it is C. And most of the stuff is reused, such as methods of spawning bullets and patterns. Hit detection is just bounding boxes so that is likely to be reused as well.

nullpointer · Post by **nullpointer** » Thu May 26, 2005 9:16 am

SDKs are one of the key paths or dev teams on hardware specific projects, along with middleware libraries and tools. So the team doesnt have to start from scratch, but can build on and learn from SDK examples etc.

CLRH2O · Post by **CLRH2O** » Sun May 29, 2005 10:31 am

The SDK angle is actually what I was thinking of when I started this thread. I made mention to Sega’s "KATANA" Dreamcast dev system - which I would guess included an SDK as well.

Thinking on that same thread - what SDK does Joker Jun use? Or any of the CAVE guys.. the 8ing boys? What SDK (if any) did Siebu Kihatsu use? To me, Siebu was one of the greatest shooter companies EVER! And I'm more interested in their technology than nearly anyone elses' except maybe the 2003 and up CAVE / PGM hardware...

Hmmmm, that just made me think – on the current/new games by Cave - as a company they use IGS's "PGM" core hardware for all thier built to purpose PCB's now don’t they? Games like Ketsui, ESP Galuda and DoDonpachi III were all PGM based right? If that's the case - then it would stand to reason that CAVE's developers are using the PGM hardware SDK..... Maybe I'm stretching there?

It’s too bad we cant get some of those company guys on this forum to answer these types of questions….

WHERE ARE YOU GUYS!

Zhon · Post by **Zhon** » Mon May 30, 2005 7:51 pm

There also happens to be the slight obstacle in which most of them don't speak english...

CLRH2O · Post by **CLRH2O** » Mon May 30, 2005 10:30 pm

That is an obsticle I'm willing to figure out how to overcome

There are enough translattors out there.

jdsony · Post by **jdsony** » Mon Jun 06, 2005 7:30 pm

This is one area that really needs to change. Although I admire developers that use ASM more than any other, there really needs to be more tools available for artists. There is quite a division between artists and programmer's most are not able to become great and both only great at one or the other. I would have no problem creating good graphics, music and sound effects for a game very close to pro quality but my programming skills would probably only allow the display of static objects on the screen. Maybe it's an issue with me in particular but the main problem I have with coding is the lack of results in the beginning. The reason I can work with music and graphics is because you get instant results, sure it takes time to perfect something but you can see/hear your product as you work on it. With coding you often don't see results until you get all the base code completed (I'm sure good coders can visualize everything they do though). Coding is also very structured with many rules to follow which also makes it a problem for me. Although I have been working in Flash with actionscript a lot lately I do find myself getting stuck a fair bit and having to rework my plan of attack.

TGK · Post by **TGK** » Wed Jun 29, 2005 5:47 pm

jdsony wrote:This is one area that really needs to change. Although I admire developers that use ASM more than any other, there really needs to be more tools available for artists.

You raised a very valid & interesting point

As a programmer, I have these concerns too about the artist/coder relationship.

"Tools for artists" I think is a part of a larger question. For small team development, especially remote collaboration, there must be a sort of strick and standard workflow process that outline every possible development situations, to achieve these goals:

a) Get art produced as quickly as possible while keeping quality. Mostly this go back to the "what method should I use to produce this art asset" question.

b) Leave the programmer with little to no effort to integrate art. He won't have to do much resizing, offsetting, guessing where the reference point is, etc. when coding.

c) Ensure commitment. I know this depends mostly on the individual, but with a coherent project management model, a remotely-collaborating team is more likely to stick together.

Any ideas?