Game programmers

[Cronnoc]

Just out of curiosity who here is programming to actually become a game programmer and has anyone made a decent game (text, 2d or 3d)?

[NUj6URfi]

Me but I have a dual goal to build an operating system.

[N36fSL3A]

Well it's a hobby for me, I can't actually do anything legally.

I'm working on a 3D RPG.

[Disch]

I've started and gotten midway on some of decent games and plenty of crappy ones. Though I tend not to finish game projects.

The closest thing to a game that I've actually finished is probably an NES emulator =X.

[N36fSL3A]

What's your latest project?

[Cronnoc]

i am currently making a 2d space shooter/action/adventure game where you can currently fly around (i have made it so that it takes a little to get to maximum speed and it takes a little to slow down to stop), use abilities and shoot opponents. i am going to make missions, AI, inventory system and space stations

[Disch]

Work sort of saps my creative energy.

Though over the past week or so I've been making a utility for seamless reading/writing zip files... mainly to be used with SFML... but not limited to just that. I know there's a million and one libs to do that already, but I have yet to find one which has an interface I'm happy with.

[N36fSL3A]

Seems interesting. Are you planning on writing your own compressed format?

[Disch]

Nope. Though I have some experience in that area. Specifically with writing compressors for obscure formats. I used to be in the ROM hacking scene (modding retro video games)... and a lot of old NES and SNES games had custom compression formats. Part of my hobby was figuring out the compression, then writing utils to compress/extract game data.

[N36fSL3A]

Any resources you've learned from? What language did you use?

[Lachlan Easton]

I'm working on two projects at work at the moment, one is a 3D sci-fi hover taxi simulation called Collateral http://dancingdinosaurgames.com/collateral/?cat=7
as well as a contracted game. It's a fairly big team (I think we're sitting at ten at the moment, with others that have come and gone).The game is made using UDK.

[3qX21hU5]

Ohh ya was meaning to ask how did the kickstarter campaign go Lachlan? Remember seeing it a few months ago and the game looked quite interesting.

[Disch]

Any resources you've learned from? What language did you use?

In those days it was all C++ and 6502/65c816 assembly.

I think a few compression formats were already documented, but for most of them I went in and figured out the format by looking at the disassembled game code.

[N36fSL3A]

I might look into that. And what was your decompiler?

[Disch]

I don't remember. There's a million and one 6502 disassemblers to choose from. Or you can just use the debugger in emus like FCEUX.

If you're looking for romhacking resources:
http://www.romhacking.net/

If you want an example... I disassembled and commented the format for GI Joe (NES) passwords. The outline + disassembly is here:

http://www.romhacking.net/documents/378/

[Lachlan Easton]

how did the kickstarter campaign go...?

Reached our goal and then a little (16000 out of 15000), the game's currently in closed Beta for Kickstarter backers.

[chrisname]

@Disch
That's funny, I was just thinking about writing a library that handled IO with compressed files/archives. I was probably just going to wrap libarchive with an iostreams interface though.

[Disch]

@chrisname:

That is kind of funny. I've looked at libarchive before... and it's one of those libs that I referred to before... functional, but I cant stand the interface.

The goal with the lib I'm working on is to make the fact that the file is in an archive completely transparent. I do this by abstracting the file system into a class, and using inheritance to create other "filesystems"... treating each archive like they're their own filesystem.

The interface ends up being like this:

// 'fs' is a global object to access the disk file system.
auto zip = fs.openArchive("myzip.zip");  // open an archive

// here, you can iterate over files/directories, rename/copy/create/delete files
//  and directories in 'zip' just as you could in the 'fs' global file system.
//
// And also open new files just as you would in the global FS:
auto file = zip->openFile("path/to/myfile.xxx");

// file would have read/write/etc functions just as a normal file would. 

That's it. Write to the file and the changes will be recompressed and saved upon exit (though from your program's perspective, they'll appear to be saved immediately -- if you open the file again it will remember the changes).

It works by caching the extracted files in temporary files on disk. Then when the archive is closed, it just goes through all the cached files and rebuilds the zip from them.


I'm actually very close to done with it. Everything is working except for 2 key parts:

- Copying files between file systems
- Actually saving the .zip file =P (though that's not as big of a job as it sounds)



I eventually plan to create wrappers for SFML's InputStream class and possibly even std::iostream. I also want to add a "mount" feature that allows you to treat an archive like a path name. So you could do this:

fs.mount("path/to/myzip.zip"); // mount the zip to make it "just another directory"

file = fs.openFile("path/to/myzip.zip/file.xxx"); // opens a file from the zip 

This would just be syntax sugar though... so I'm going to finish up the other stuff first. Though it would spare you the need of having to hang on to that 'zip' object.

[N36fSL3A]

I'll have to check your link out at home, here at school the rom hack website is blocked for "security.hacking".

[chrisname]

Disch wrote:

I've looked at libarchive before... and it's one of those libs that I referred to before... functional, but I cant stand the interface.

The same for me, I hate the interface but I don't want to replicate all its file format support, hence the wrapping.

Disch wrote:

I also want to add a "mount" feature that allows you to treat an archive like a path name.

I'd suggest making the mount operation transparent, which you could achieve in your openFile function by splitting the path into /-delimited sub-paths and then testing whether each one (excepting the final part, the target) is a directory, archive or regular file. If a given sub-path is a directory, then you treat it normally; if it's an archive, then you mount it and treat it as a directory; if it's a regular file (or unsupported archive format) then you can throw an exception about the caller trying to sub-path something that isn't a directory or an archive.

This way, a program that uses your library could have its resources moved into or out of an archive (provided the path was the same, or if it read the path from a different file at runtime) without being recompiled because your code would detect what was being used at runtime. It would be a little slower, but it's nothing compared to the amount of time your code spends waiting for synchronous hard disk I/O anyway, and besides, the caller probably won't be opening lots of files over and over again in tight loops where speed really matters, unless he doesn't know what he's doing.