[ 3 / biz / cgl / ck / diy / fa / ic / jp / lit / sci / vr / vt ] [ index / top / reports ] [ become a patron ] [ status ]
2023-11: Warosu is now out of extended maintenance.

/jp/ - Otaku Culture


View post   

File: 875 KB, 800x1016, 1729.png [View same] [iqdb] [saucenao] [google]
11255547 No.11255547[DELETED]  [Reply] [Original]

How do I learn how to create games in C?

I already know how to use pointers and things like for and while.

>> No.11255561

NOT otaku culter PLEASE delete thread and leave to >>>/g/

>> No.11255577

>>11255561
I want to create doujin game

>> No.11255601

Learn game theory, just the basics, if you don't know them already, no book will teach you as much as trying to make games yourself so pick a framework and learn by example/doing yourself.
Leave optimizations aside unless really needed.

Try doing these in this order:

1 CLI adventure game
2 Pong/tetris clone
3 basic rpg/crawler

Read the source of a small finished game if you insist into doing it the inefficient way.

>> No.11255641

If you know C, then you have everything you need.
Games don't need specific skills. Just use a 2D library, like SDL. (Or a 3D lib if you want a 3D game, like OpenGL)

>> No.11255710

The most powerful programming language is Lisp. If you don't know Lisp (or its variant, Scheme), you don't know what it means for a programming language to be powerful and elegant. Once you learn Lisp, you will understand what is lacking in most other languages.

When you start a Lisp system, it enters a read-eval-print loop. Most other languages have nothing comparable to read, nothing comparable to eval, and nothing comparable to print. What gaping deficiencies!

Lisp is no harder to understand than other languages. So if you have never learned to program, and you want to start, start with Lisp. If you learn to edit with Emacs, you can learn Lisp by writing editing commands for Emacs. You can use the Introduction to Programming in Emacs Lisp to learn with: it is free as in freedom, and you can order printed copies from the FSF.

To study Scheme, and a deep understanding of program structures using Scheme as a vehicle, I recommend Structure and Interpretation of Computer Programs, by Abelson and Sussman. This too is now free as in freedom.

>> No.11255879

>>11255710
i giggled

>> No.11255946

>>11255710
lol

>> No.11255968

>>11255710

I'm on Chapter 3 of SICP.

How long til I'm programming master

>> No.11255976

http://alleg.sourceforge.net/

>> No.11255977

>>11255968
Are you doing all the exercises?

Do all the exercises.

>> No.11255979

>>11255977

Yes, thats why its taking so long.

>> No.11255985

>>11255547
Download SDL2 and start making games.
C is very simple, and SDL2 is fuggin fast.

>> No.11255987

>>11255968
Until you've written a Scheme interpreter and compiler.

>> No.11255993

>>11255987
>and compiler.
Will it compile to native code?

>> No.11256008

Is there a language agnostic guide that explains how games work? I get that there's a main loop that polls for input, processes events, then draws the screen, but is there any book or website that expands on that?
I know how to blit surfaces and test for input and all that jazz in SDL, I just don't get how to implement a game. There must be some general rules that all games follow.

>> No.11256016

>>11256008
Just pick a language you want to use and find a book/tutorial on it for games.

There's not really much point in a book about only those concepts, most books will teach you those concepts through application in a specific language.
The important thing is the concepts you'll learn will apply in any language really.

Also SDL has tons of game tutorials, look well.

>> No.11256019

>>11255993
It runs on a register machine simulator you write, though you could adapt it to x86 or whatever you like.

In fact, the final exercise of the book is to alter your compiler so that it compiles to C code.

>> No.11256017

>>1125600
The hard part is actor managment. Everything is done with actors/entities that are spawned in and run in the gameworld.

>> No.11256027

>>11256019
>simulator you
So its only an interpreter? Eh that's boring.
>In fact, the final exercise of the book is to alter your compiler so that it compiles to C code.
Okay that's cool, still I don't really see the appeal of scheme. I'd rather just use C and whatnot.

>> No.11256030

>>11256016
>Also SDL has tons of game tutorials, look well.

The problem is that, the last time I checked, all the tutorials were C++. I don't mind C++ so much and I know it a little, but I'd like to stick with C if I can, to improve my C programming. Not to mention the SDL documentation uses C. And it's pretty good documentation too, but it doesn't teach you how to make games or anything like that.

I feel like a book like this should be written. Something that doesn't teach you how to make games in C++ with DirectX, but rather, how games work. You could swing it so that it's interesting to both programmers and gamers. Some people just like knowing how stuff works even if they don't want to replicate it.
Get to it, /jp/ devs.

>> No.11256034

>>11256030
As a C programmer, for games, I recommend using a C++11 compiler and just using certain standard data structures in place of the C equivalent -- but keep everything else like C.

>> No.11256044

>>11256027
>So its only an interpreter? Eh that's boring.

No, you write an interpreter first. The simulator is more like a virtual machine. I can't remember if the instruction language is a "real" one or something like MIX, but it makes sense. Not only are you writing a different kind of program and learning how machines work, but it also keeps the book from becoming dated.

>Okay that's cool, still I don't really see the appeal of scheme. I'd rather just use C and whatnot.

Read the book, if you haven't already. Scheme is a really fun toy (and I mean that as a compliment).

>> No.11256049

>>11256030
That's because C++ works damn great in games, OOP offers flexibility for systems you just can't get with plain C and structs without a lot of work, so its natural for most people (and the industry) to just use C++.

That said, its very feasible to write in C.

Here's a simple game a /jp/sie wrote in C and SDL, give it a look (source is there)

http://pastebin.com/Qyjj9d2P

I might make a platformer tutorial in C and SDL if I see anyone interested.

>> No.11256059

>>11256044
>virtual machine
Well yeah that's what I meant by interpreter, its not native code so its interpreted by the vm.

>> No.11256074

>>11256049
What's wrong with structs?

Simple C++ classes are just structs (they're syntactically equivalent). C objects work just fine.

>> No.11256086

>>11256074
Sure you can make a basic class with a struct and function pointer but that's obviously not what I meant, OOP is only that.

>> No.11256091

>>11256086
OOP isn't* only that.

>> No.11256097

>>11256059
If I write a Game Boy compiler, compile a program, then run it in VisualBoyAdvance, I have written a Game Boy compiler.
You could design a real machine to run (in hardware) the exact same program that runs in your simulator. It's a sequence of machine code instructions, not a list of Scheme expressions running on an interpreter (which you do write in an earlier exercise).

>> No.11256121

>How do I learn how to create games in C?
Learn trigonometry (at least the formulas).
Learn threading*.
Learn how to make 3D sprites or 2D if you want to make a 2D game

*better learn OpenGL or SDL instead.

>> No.11256125
File: 7 KB, 220x210, S-expression_tree.svg.png [View same] [iqdb] [saucenao] [google]
11256125

You know what would be HELLa cool? A visual language based on S-expressions where you draw-code an actual tree, like you can add nodes and shit. That'll be less confusing than a clusterfuck of parentheses and indentation.

>> No.11256132

>>11256097
I get what you mean dude, I'm just going by the common definition of an interpreted language.
Code that isn't compiled into a native executable is interpreted.

>> No.11256140

>>11255547

what kind of stuff you have written with c? name and explain 3 test programs or utilities you have written.

>> No.11256180

>>11256132
>Code that isn't compiled into a native executable is interpreted.

It is compiled into a native executable, for a register machine. Your program spits out machine language instructions. It doesn't take a sequence of expressions in an interpreted language.

Of course, the line can start to blur a little. As mentioned, in one of the final exercises you compile to C. Maybe someone has created a virtual (or real) machine that can natively process C instructions, as inefficient as that would be. I know some ARM chips have a unit that can natively run Java bytecode.

>> No.11256184

>>11256140
hello.c
tempconv.c
count.c

>> No.11256184,1 [INTERNAL] 

otaku
noun (plural same)

  (in Japan) a young person who is obsessed with computers

>>
Name
E-mail
Subject
Comment
Action