Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I Write Games in C

jonathanwhiting.com

Post reply on HN
Print view View original

61–70 of 303 posts

Re: Why I Write Games in C

#61

Post by clouddrover »

egonelbre wrote: post #36
antaviana wrote: post #33

Delphi compiles extremely fast, is strongly typed, no GC, has templates, objects. Too bad Embarcadero positioning towards Enterprise with its relatively high pricing effectively derailed it as a mainstream language and killed its community.

And doesn't have console support (AFAIK).

If iOS and Android devices count as consoles (and I think some of them do) then Delphi has console support. :)

Free Pascal (http://www.freepascal.org/) says it supports the Nintendo GBA, Nintendo DS and the Nintendo Wii (to what extent and how well I don't know, never tried it). It also supports Win32, Win64 and FreeBSD so I suppose it could be made to work on the PS4 and XBox One without too much trouble.

A real strength of Object Pascal is that it can be as low level (inline assembly, manual memory management, etc) or as high level (OOP, generics, etc) as you like. It satisfies most of the article's wishlist items.

Today I happened to find a simple but still interesting programming language feature matrix on Ian Hixie's website: http://ian.hixie.ch/programming/

He'll have to update the Execution column for Free Pascal to be both "Native" and "VM" since Free Pascal 3.0 can now also compile to JVM byte code: http://wiki.freepascal.org/FPC_JVM

Re: Why I Write Games in C

#62

Post by moron4hire »

seanwilson wrote: post #55
moron4hire wrote: post #22

Incidentally, all of his reasons that don't misrepresent C are all the same reasons I write games in JavaScript. Mostly, it's about speed of development, understanding, and platform compatability. Performance is good enough and almost always my fault when it isn't. I wish for a strictly typed language, but OP isn't using one, either. I've tried several of the transpilers and have generally found the workflow lacking…

Did you try Typescript? I'm curious what you thought of it for games if you tried it. I enjoyed using Cocos2D JavaScript bindings for cross-platform game development.

Found it difficult to integrate with existing JS, such as THREE.js. Also found it difficult to create libraries (I make a RAD workflow for VR apps) that could be used in arbitrary JS projects; I want people to be able to drop my concatenated script into their page with a script tag and not have to worry sbout anything else. Also, early on I ran into quality issues with the 3rd party type mappings for popular libraries, and eventually decided it wasn't worth the hassle.

Generally speaking, gradual typing doesn't get me excited. I don't think there is a payoff to having some of your code statically typed and others not. The mismatch between the two causes problems. So TypeScript, et al are an all-or-nothing proposition, and there were big chunks in my workflow that prevented it from being "all".

If you choose to embrace dynamic code, you can write less of it and minimize your surface area to bugs. I'd prefer static checking and more code because of stricter typing, but dynamic can be done well in its own right if you approach it at a much higher, metaprogramming level. Don't half-ass two programming styles. Whole-ass one.

I also missed the fast-reload workflow of native JS. I sometimes live-edit code in the browser, and being able to go back and forth between the two with no hiccups is nice.

So while a lib layout e.g. THREE.js is "old", it at least works without major machinations on the most systems for the most implementing developers.

I might start using more ES6 features, as I could use native browser support in my browser of choice for development and a transpiler to pack up packages for deployment. But I won't be going to a language that gets between me and the browser.

Contemporary webdev workflow is designed for either A) automated setup and execution of scripts in remote, headless environments or B) getting beginners gluing libraries together quickly. These are frequently not the same thing as a great developer experience.

Re: Why I Write Games in C

#63

Post by notalaser »

abcd_f wrote: post #54
AndyKelley wrote: post #19

The thing I miss most in C when I don't cheat and use a couple C++ features is templates. Specifically, a dynamically sized List implementation that is type-generic. If you do this in pure C, you have to pick your poison: 1. preprocessor abuse 2. void * 3. multiple redundant implementations of the data structure Dynamically sized lists are used so often, that this tends to be a problem in almost every C project. I wo…

BAH! 4. The "intrusive" containers, but of course. The one true way to do it in C. For one, you can keep items in multiple containers, all being on equal footing. None of that typical C++ mess, when this list is a primary storage for items, and those maps are secondary indexes, all sprinkled evenly with iterators. Intrusive containers don't own items, they merely organize them, which is exactly the right way to go ab…

Yes yes! Yes! It saddens me that this extremely useful idiom is not more widely taught. It's a beautiful, simple concept that works for so many things.

Re: Why I Write Games in C

#66

Post by dom96 »

How about Nim? [1] [2]

To me it is in many ways a "nicer and safer C". Sure it's not as mature as C, but what is? What it does have going for it is portability (it compiles to C so it shares C's portability), a soft real-time GC which can be manually controlled [3], generics, AST macros and much more.

1: http://nim-lang.org

2: https://github.com/nim-lang/nim

3: http://nim-lang.org/docs/gc.html#realtime-support

Re: Why I Write Games in C

#67

Post by zodiac »

abcd_f wrote: post #54
AndyKelley wrote: post #19

The thing I miss most in C when I don't cheat and use a couple C++ features is templates. Specifically, a dynamically sized List implementation that is type-generic. If you do this in pure C, you have to pick your poison: 1. preprocessor abuse 2. void * 3. multiple redundant implementations of the data structure Dynamically sized lists are used so often, that this tends to be a problem in almost every C project. I wo…

BAH! 4. The "intrusive" containers, but of course. The one true way to do it in C. For one, you can keep items in multiple containers, all being on equal footing. None of that typical C++ mess, when this list is a primary storage for items, and those maps are secondary indexes, all sprinkled evenly with iterators. Intrusive containers don't own items, they merely organize them, which is exactly the right way to go ab…

What is an intrusive container?

Re: Why I Write Games in C

#68

Post by johnydepp »

I write games as well (Written more than 10 games, though they are not very large at scale) and I write them in C++. Reasons being writing networking code (TCP/UDP) is much easier & efficient in C/C++ than any other language IMHO. And most of the code works across platforms.

Re: Why I Write Games in C

#69

Post by exDM69 »

zodiac wrote: post #67
abcd_f wrote: post #54

Earlier quoted context omitted.

BAH! 4. The "intrusive" containers, but of course. The one true way to do it in C. For one, you can keep items in multiple containers, all being on equal footing. None of that typical C++ mess, when this list is a primary storage for items, and those maps are secondary indexes, all sprinkled evenly with iterators. Intrusive containers don't own items, they merely organize them, which is exactly the right way to go ab…

What is an intrusive container?

A technique commonly used in C, for example in the Linux kernel. You embed "links" to other nodes in your structs, and find the struct from the link based on offsetof. Linux kernel uses linked lists and red-black trees this way. Probably other data structures too.

Intrusive containers are cache friendly and typically require no dynamic allocations (in addition to allocating the data itself).

See the link in the post above for more about linked lists in the linux kernel.

Re: Why I Write Games in C

#70

Post by scrollaway »

ivanca wrote: post #39
scrollaway wrote: post #16

Earlier quoted context omitted.

If you're going to write a TL;DR for others, you should at least read the article yourself, don't you think?

I did, it is so abstract to pretend you can do better that there is no way to discern. He didn't even mention "unity" in his post, thats just ridiculous in 2016, but yeah, keep down voting, your implementation of 2d graphics, sound, collision, physics, plugins, marketing, sprites, menus is gonna be so much better than hundreds of engineers at unity withing 10 years straight.

You have an attitude problem.

First of all I've worked with Unity myself and I know how nice it is. It's not the end-all-be-all of game development and it's not suitable for all genres.

Second, like someone else said, this is about a language - not a framework. Unity locks you into C#.

Third, the guy says himself 'I absolutely DO NOT mean to say "hey, you should use C too".'. He's not forcing you to write games in C, he's enjoying writing games in C and explaining why.

If you want to be a good developer, especially a good game developer, consider listening to people who have opinions and experiences different to yours and are willing to explain them. Evaluate their argument. Come up with a rebuttal, share your own experience, by all means - but don't be rude, aggressive, pompous, or a number of other things you are being right now.

This is why the games industry has a NIH problem. Not because people want to develop in C, but because every single dev has their own idea of what is right, what is wrong, and EVERYBODY ELSE is wrong. You want to fix the industry's NIH syndrome? You start by listening.

And as a sidenote, the guy didn't say "Why I'm implementing my own physics/graphics/sound/UI engine". He said he's using C. There's a lot of C libs for games. I don't know if you know this, but Unity isn't the first framework and C# isn't the first language.

Post reply on HN