Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Making a Game

Name: Anonymous 2013-07-18 17:41

Srs thread plz.

I've been meaning to make a game for a while now, tentatively as a hobby. For convenience it will be on the "PC platform".

Although of course, technically game development is only half about programming, the other half being the design/creative aspect, which I understand. Naturally I care about creating the underlying program first, e.g. with moving rectangles that I can later put graphics on top of.

My experience with programming and learning about computers in general has been one of solitude, and I can hardly see myself working with another person on a game, but at the same time I feel like there's too much reinvention of the wheel going on by doing everything myself. Therefore I'm making this post as a somewhat general advice thread.

For now I plan for it to be a 2D platformer game, as it seems to be simple yet not boringly simple to expand upon. Inspiration comes from games such as Cave Story, MapleStory, IWBTG, Super Smash Brothers. There's something about the 2D platformer that fits real-time simulation. The birds eye view style seems to be best for story-based games, which I'm not much into. Although, I don't dislike the thoroughness of simulation that a 3D game can provide (RuneScape, OoT, First Person Shooters). But for now, the relative simplicity of 2D will do. The game also must have a networking feature for interpersonal gameplay. It seems that nowadays it's simply a feature that can't be ignored in terms of availability, relativity, and the amount it adds to gameplay variation.

I'm not a complete noob; it's been somewhat of an aspiration of mine for several years now. I'm fluent in C and have a basic understanding of the compilation process and a general understanding of the x86 architecture. I also have some experience with the UNIX-like environment if that matters.

The reason why I don't like Java or other high-level languages is that C seems to have the most native support for APIs/libraries, and I feel that it gives the most flexibility/control. That, and language constructs above C seem to be somewhat extraneous, though I do admit things like lambda expressions work really well where they work best. C seems to be the best language for practicality.

I have some code written already, and some tentative thoughts on the underlying engine. But I find myself starting over and over from some design flaw. At some point I thought that I'm simply doing it wrong for starting from scratch. To those experienced in the field, do you think it's worth coding a game in low-level C nowadays? I know there are libraries such as Allegro and SDL that take care of the implementation side of things. But perhaps my thinking is old? Being such a broad topic, and of somewhat universal interest, there's alot out there and I acknowledge that. By now there's a myriad of ways to "make a game", ranging from using an "engine" or some other high level environment to "writing code" of a particular language. Should things be done through high-level game engines or is C still relevant? Because it's an unavoidable fact that not everything goes on in the CPU, in particular things like graphics is done on the graphics chip which we don't necessarily program except in cases like OpenGL. Perhaps it's better in the long run to use some established game development package?

Anyway. Not even sure if I'll get any meaningful responses on here, probably because I don't know exactly what I'm asking for. At the very least I'd appreciate some pointers to people who know what they're talking about. The typical google for forums/IRC shit isn't quite what I want, but maybe I wish for too much.

Name: Anonymous 2013-07-19 0:08

Thanks for the serious replies.

>>11
Yeah, I figure coming up with a solid game design before programming would help make things move more smoothly. I dunno, but it seems easiest when I have some code looking back at me as I continue with what design aspects naturally follow. I also don't believe in the formal design spec crap, I have a few papers laying around that I sketched out some ideas/visualizations on.
Btw isn't Touhou made by 1 person? Or are you talking about translations/fangames?

>>12
I was in a talkative mood for some reason. I wasn't really asking anything in OP to be honest, just wanted to hear what other people had to say about game development I guess.
The flaws that I encounter are fundamental ones, and naturally I would just find a workaround/alter the design somehow. But at some point I thought someone else must have been faced with the same problem I'm facing, and it just seems redundant thinking it all out.
And yeah, I already have a lot of objecty constructs. Structs and procedures are somewhat clumsy, though I don't think it's worth the overkill switch to classes.

>>13
The flaws I encountered before posting this thread was that of thinking ahead of the game's network protocol and management of the game's "state". I'm definitely going to make it support players "joining" the game in the middle of it, rather than forcing everyone to join before and start the game synchronized (Counter-Strike 1.6 vs StarCraft 1). So somehow I have to make it so that the "objects" (basically rects with velocity/position/length information), and "event" procedures are able to be sent to a joining player. Though there are objects and events that don't need to be sent, so I had to classify the objects and events as being "local" or "global", after which I found it hard to put it into the big picture. Probably doesn't make sense, but I would have to explain the game's design in detail, which I don't think many people are interested in.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List