Japanese game source code?

For me, it's the hardest thing to find... ever. Why must open source be such a "foreign" concept to Japan? I guess I could understand them not wanting their secrets out in the wild, but wow, I have yet to come across any [full] source code for any Japanese games (both homebrew or commercial), only bits and pieces.

Why do I want this? Well, after working on emulators for quite some time, I noticed a major difference between the game's coding structure; it tends to be more efficient, lower level and less PC-like than most American made games (except Azurik, that game engine was highly efficient). Their general coding style intrigues me, and I want to learn more

I've been working on a game for a friend that tries to replicate their programming style to a certain extent (using C, no class crazy C++, which is what I prefer anyway). It's coming along nicely and I've already gotten a few compliments on it too, lol.

Thanks in advance.

 

I think I once came across the source code for one of the BeatMania games for PSX, I think it was on this very forum. I'm afraid I don't have it anymore though. I had a very cursory look at it, and I was actually surprised by the level of abstraction employed. Not very low-level at all!

 

That's surprising. I'll do a search for that. Thanks.

 

Of the few JP games i've seen the source to, I don't really think their style is worth emulating. It works well in a 1 off environment but is horrible as a means to build another game off. I had a coworker who worked on the PC port of FF7 and told me about the mess that game's code was.

I've heard they've gotten better in current gen stuff.

If you need a style to emulate, I still feel American coding standards are a ok balance between Japanese and European standards. I should note that I find European code to be way too abstract with too much class stacking and complicated templates.

 

I still disagree with the American code thing, as I've seen Americans write some of the absolute worst game code I've ever seen in my life. Since I am an American, I've written my fair share of horrendous C++ code.

I guess a better style to emulate would be low level C/C++, and making it as efficient as possible. C is my preference though.

 

C is still alive and kicking...hell yeah!

Right now i'm working on a little multiplatform game engine, written in C. I got some inspiration/learning reading source code from projects like MAME, Id Software's games and some indie games.
I don't know any commercial japanese game with available source code, but maybe you can take a look in Kenta Cho's games:

http://www.asahi-net.or.jp/~cs8k-cyu/index_e.html

 

What kind of code though, hobbyist or commercial code? There is a huge difference. Working commercially in Montreal for so many years (almost 10 years) I've had the chance to see the coding styles of people from many different places (japan/china/America/Europe) and by far I find American style to be a good balance. European code I find to be the most overly written, sure it's clean and well documented but it's also bloated and slow.

On the other hand if you're talking hobbyist code that's a whole different ballgame. I've seen tons of hobbyist code that is a total mess, even when the person is properly trained and went through Uni. The reason for this is hobbyist are more concerned about getting their idea done quickly then they are about making structured code to build off on.

-edit-
I should add that just because you're American doesn't make your point more valid. I am American as well (though I live in Canada, I am not canadian).

 

If there is going to be any Japanese source code that is going to be good, it would have to be the code from the Super Famicom game, Super Aleste. That game pushes loads of stuff around the screen complete with special effects, kick arse music and full screen without a hint of slow down. Even konami's games slowed down like hell and they were seen as the kings (not like the shit they turn out these days).

yakumo

 

I don't doubt that in the least.

 

LAWL. =D

 

^ lol

Both. Commercial games tend to be better, but it can be just as bad as indie games. I liked what I saw from Unreal's source, even though it was a bit more complex than I thought necessary at the time, but I've also seen some downright horrific game code in commercial games that either stem from a rushed job, neglect, elegance over efficiency, laziness, or all of the above. Btw, there's no such thing as clean but bloated code.

IMO, id Software's engines are well written. I like their style. Freespace 2's engine IMO was overkill. Alien versus Predator's engine was just right (although that was written by Rebellion, a British game dev company). I just hate the over-usage of C++. Nothing wrong with using good C++ code, but I've seen Americans take it too far too frequently.

How many Japanese Xbox1 games have you played?

 

If you know the style you like, why do you need source to emulate? Learn more of what? Low-level algorithms? Are you talking about 2D or 3D games?

After working on emulators you should be well versed in efficient 2D engines at least.

I also strongly prefer straight C, for its elegance, but I still write a lot of pseudo-OO code, it's kind of hard to implement scalability without it.

 

None, why? What's that got to do with the Konami of today or the quality coding of Super Aleste?

 

Out of curiosity, why would you want to replicate the Japanese style?

I can understand the C vs C++ thing, for the most part. But, can't understand how a specific Japanese style would benefit you.

 

Awesome, thanks for the link (bookmarked). Too bad it's written in D, was hoping for C/C++, but that's okay, I'm still interested in these.

I'm also writing a multiplatform game using C and OpenGL for a friend (yes, a girl). It's esentially a clone of Panzer Dragoon and Eden's Aegis in the form of a 2D top scrolling Japanese style arcade game. It's coming along nicely and I hope it gets done sometime in the near future. Right now, it's about 60% complete. All I need to do now is finish putting together the OST, find some more suitable sound fx, and start designing some waves of enemies for levels and what not, then it should be ready for a beta release, then I'll have a handful of bugs to sort out.

An alpha screenie:


And yes, my game has faaaiiiiries! :nod:

Well, I don't exactly need to emulate it, I just thought I could learn a thing or two in general. And I'm talking about 2D and 3D games.

If you're curious to know, this is my preferred programming style: low level C with OpenGL. The following source file was taken from my game as mentioned earlier: http://pastebin.com/pPMjeWLr

I'm glad you ask. It doesn't have much to do with today's games, but has more to do with your prior statement about older famicom games being the most efficient Japanese games. Since I haven't seen any of your country's game programming style, all I have to go by is what performance I've seen, what I've emulated and a few obscure articles. One thing I noticed is that Japanese made Xbox1 titles generally had constant frame rates and smooth gameplay the entire game. Not a single one of my Japanese Xbox1 titles showed fps drops or bugs (except JSRF and Wreckless: The Yakuza Missions, which I liked btw).

They also use alot of non-PC standard functionality to get the job done that most American games don't ever hardly touch. Example: I have yet to see one American or European Xbox1 title that uses D3DDevice::BlockUntilVerticalBlank() for syncronization of threads, audio and other timing sensitive things (and this actually works quite well). Not saying American titles don't use efficient techniques though (I've only seen American titles use GPU fencing, like Azurik: Rize of Perathia which was unfortunately not released in Japan) most most of them seem to conform to the PC programming style, which was not the most efficient way to code for Xbox. I hate it when console game programmers do this.

And while I'm at it, let's take in this example of a Konami game on Xbox, Castlevania: Curse of Darkness. Afaik, this game was released on PS2 before Xbox, and Konami didn't want to redesign the architecture of the rendering engine, so they left it in the same fashion as PS2-style rendering. All of the vertices were transformed using custom vertex shaders instead of using D3DDevice::SetTransform and friends, or just used pre-transformed vertices. The game turned out well with no fps drops and ran smoothly the whole time.

This is partly why I assumed that Japanese game code was more efficient. Probably not the best way to come to conclusions though.

Btw, since you're from Japan, tell me what you think of my coding style, please.

Well, like I stated earlier, I thought I could learn something from it.

 

Sorry if off-topic, but I always wondered. When did the "united-staters" decided they have the monopole on the word american? I mean, as I'm canadian, ain't I in america too? Hence I'm an american. But if I say I am american, everybody thinks united-states... I can see the same point for central/south america.

On-Topic: IMO there's a whole lot of people in AmericaS taking programming classes. And a lot of people graduate without being that good. Whereas people in Asia tend to be far more elitist, and teachers more "cruel" (impossible homeworks/exams) with students, which in turn creates better programmers.

My own coding style is awful, bash, c++,pyton all mixed together in a complete mess. As a scientist, I'm the only one using it though...

Just my 2 cents.

FG

 

^ Well said on the first two paragraphs. The US tends to think that they are "the best, the greatest and the most entitled" in the world, creating an egotistical mindset which eventually becomes embedded into the culture. Let's not go too far offtopic here, I'd rather keep this issue in a seperate thread.

Btw, I find this article rather interesting:

Japanese: http://www.geocities.co.jp/HeartLand/8281/fb.html
English: http://translate.google.com/transla...BLEND_CONSTANTCOLOR&hl=en&safe=off&prmd=imvns

 

Whattt everything is inline, hardcoded and preallocated. It's driving me crazy. You know you can design an efficient game engine that is a lot more flexible and maintainable without any real overhead by dynamically allocating game objects. It's like you unrolled a game's structure so it's flat... that's only suited to pong and tic tac toe, even most Japanese 8-bit games objectify things. I'm not sure but I suspect my Atom netbook would chug with your game.

When I think low-level 2D game engine I think:

-Custom surface blitter and sound mixer
-Texture and sample caching
-Transparent resource loading like streaming music and backgrounds
-Strict use of cached RAW bitmap and sample resources during gameplay to reduce CPU load, disk I/O and latency
-Tile "sprite" sheets
-At least a PCM music engine ("mod player") if not some sort of sound synthesis
-Spawnable metasprites with animation, bounding boxes, AI/physics
-Scrolling pseudo-background/foreground layers comprised of animatable metatiles
-Object to object and object to background collision
-Beautification objects (cutscenes, HUD, NPC/falling leaves)
-Frame-atomic timing where an arbitrary number of objects are processed per frame
-Fixed point math where suitable

It sounds like a lot but for a 32-bit grade game it shouldn't be more resource intensive than an 8-bit MAME driver, well, unless you're working at HD resolutions.

 

You might want to message 'pixel' the creator of 'cave story'.

Mind you he was a hobbyist
There is a fair amount of hobbyist code flying around, especially for shmups

Here is one : http://i-saint.skr.jp/exception_conflict/

I work for a Japanese game company - in Japan most things are hard coded and hardly ever recycled. It is the epitome of inefficient. (most but not all - I am generalising here)
I hope to change that eventually

 

:banghead:

Oh wait, I forgot to tell you that there's a handful of hard coded stuff in there because much of the game still works in sandbox mode! Sorry about that. I've been meaning to tidy up that particular source file, but generally speaking, that's how I like to code my "low level" stuff. Quite frankly, it works pretty well without any frame rate issues and minimal bugs if any. Rendering isn't optimized because I've been more focused on getting things to work properly. Well, allocating a structure with a handful of function pointers would likely make the code more reusable and expandable. This is what I was taught in my beginning stages of programming, "optimize your code after it's working, not as you go". It's a mistake I've made numerous times and I refuse to do it again.

Also, your definition of low level is different from mine. My definition of low level is using the thinnest layers possible between the API and the customized game functions accessing them without needing to expose the actual APIs used for greater portability, or writing basic code with minimal layers to take advantage of hardware directly or indirectly.

Sorry if that source example was painful to read. I wrote another game tutorial in C about 2 years ago. It was a 3rd person shooter tutorial for OpenGL. How does this read for you?

http://pastebin.com/UYGE560T

This is what my initial assumption of what Japanese game code is like, but clearly your definition of efficient differs from mine. When I talk about efficiency, I'm speaking of speed, performance and/or optimal, not re-usability. Sure, it's more time efficient to have a re-usable code base, but I'd rather have code that's low level and to-the-metal than high level with a ridiculous number of functions blanketing the underlying API/hardware.