Okay, it’s time to reveal part of My Secret Plan. Since the last day of GD2 I’ve been thinking hard about what I want to do for GD3 & 4. I ended up narrowing it down to two mutually exclusive (because I can’t combine them into one project) major ideas I’ve been mulling over. Ideas which I want to do regardless of whether I can do them for college credit or not. Depending on what Prof Morrison does, I may have to postpone both projects and do an unknown “C” game, but here’s A and B:
Game A is a procedurally generated first-person shooter I’ve mentioned briefly before. I would basically be borrowing the models from FPS Creator, but instead of using the FPSC program, I’d be loading them into my own C++ program via the Dark GDK.
- 3D Roguelike with extremely innovative design.
- I’ll be taking Comp Sci I concurrently with GD3, so I’ll be learning the next “level” of C++ as I’m making the FPP.
- This is the game I’m making the GM prototype for, so I’m already getting a handle on the essential algorithms I’ll need to translate into C++.
- It’s territory on the “frontier”. Games in the genre have been made before, but not a whole lot. DoomRL is the closest gameplay-wise and Hellgate: London is the closest graphics-wise.
- It’s tremendously interesting from a programming perspective. Not just because it would be my first major C++ project outside of a programming class that’s not a text-based game, but because the game would be based on procedurally-generated content.
- The FPS Creator modular floors, walls, and room features are perfect for this project. I just need to figure out the algorithms I need to tell Microsoft Visual Studio to make the environments.
- FPS Creator itself can serve to test some of the things I want to try out in the game.
- The source code for FPS Creator is freely available. Although it’s in DB Pro and not C++, it’s still a head start.
- Since the tech side will definitely be the most interesting part of the project for me, anyone else I work with will have plenty of freedom to figure out the story and some of the design aspects.
- Beyond the class, this would get attention from Indie news sites for being innovative and interesting.
- Possible logical destination: the IGF and/or Indiecade.
- Unless I give up on the idea of procedural content generation (which is the whole point of Game A), I can’t use FPS Creator itself for the main part of the project.
- The timing of it is such that I’ll be far beyond the rest of the class in required tech knowlege, so no one else in the class will be able to help out on the tech side.
- It’s riskier because although I can look at the advice and experience of Roguelike developers and Dark GDK developers, nothing quite like this has been attempted before. Especially if I manage to add in some of my wilder and more esoteric ideas like dynamic terrain alteration (digging tunnels, etc.).
- I’d really like to include some really risky stuff like procedurally generated plots, but that would rely on either really good HL2 style companion/NPC AI or complicated RPG elements. (The actual algorithms for the plots would be relatively simple fetch-quest/”Kill Monster Z for me” type stuff, but would require some amount of verbal character interaction which I’d need to have in place first. Easy in a text-based Roguelike, not so simple in a FPS.)
- Short of procedural plots, I’d like to shoot for procedural puzzles. Puzzles wouldn’t require any non-peaceful character interaction and I have a few ideas for implementing it, but there’s even less precedent for procedural puzzles than for procedural plots.
Game B is a Source Engine First Person Shooter set in the Half Life universe. It’s essentially a compilation of various ideas I’ve had while playing HL2 and other Source engine games, which then evolved into a distinct setting. It’s comprised of one huge level: a mysterious island surrounded by a Combine force field. There’s action and puzzles, but the emphasis is on exploration, survival, and discovering the island’s dark secrets in order to finally escape (the whole island was owned by Aperture Science at one point, and yes, there are plans for portal-based puzzles). Inspired by Myst, The Prisoner, Lost, the Half Life universe, and every story I’ve read or watched that was set on an island.
- 3D FPS with game mechanics most PC gamers are familiar with.
- The entire Source SDK is free to anyone who owns a Source engine game on the PC made by Valve.
- It would look great. The FPS Creator, and therefore Game A, looks good, but this would look great.
- The current design document is based on semi-modular (in the sense that most of them can be cut if necccesary) areas around the island and a fairly straightforward plot. Unlike Game A, the designers can feel free to add in a lot of specific detail to specific areas.
- Using the Source Engine means a heck of a lot easier job on the tech side of things. Not just the mechanics of moving and shooting, but also lots of neat AI-related things as well as the excellent Faceposer application for NPCs.
- There’s a ton of art resources available in the Source SDK for making Source Engine mods with. Even more than I got with the FPS Creator Bonanza.
- The Half Life universe is a nice, established, flexible setting.
- There haven’t been any “sandbox” games in the Half Life universe so far, nor many Source engine games where you have to explore a large area and are able to backtrack.
- Beyond the class, this would open up potential opportunities like getting attention from mod sites, and act as an awesome resume-enhancer for anyone who wants to work for Valve specifically.
- Possible logical destination: publishing the game worldwide on Steam.
- Some of the things I want to do, such as a very simple conversation system for a handful of freindly NPCs, and a simple inventory system for storing widgets for puzzle-solving, I have no idea if it’s possible without access to the source code. Which I certainly don’t have.
- While Game A involves telling C++ how to put levels together in an interesting way, this project would require a large island to be constructed by hand. This may actually be an advantage, but I don’t know if it is yet or not. I currently have less experience using the Source SDK tools than I do with C++ (though when my new laptop arrives, I’ll finally have the option to try out the Source SDK tools again). Because of the above point, I’d probably need at least one other person helping me with the mapping aspect.
- It would impose stricter limitations on the rest of the team in terms of what things look like, sticking to Half Life canon (unless we decide not to), etc.
- We hopefully, maybe could add in some custom models, but that’s another area I have zero experience with so far.
- It would require the rest of the team to stop being consoletards and get into PC gaming.
- Both of these are innovative designs (in different ways) that are likely to get attention if marketed right.
- Both of these are definitely games I would like to spend a whole year developing.
- Both are deliberately designed to have flexibility for the rest of the team to add in their own ideas.
- As I mentioned before, both of these are completely my invention and neither may fit even a little bit with Prof. Morrison’s plans for September. This is part of the reason I’m revealing them now: to get them, in this form, out on the web now in case this is as far as I’m able to take them. Some modification would be necessary regardless (no game follows it’s design document to the letter), but I might need to put them to the side entirely. Or maybe I’ll come up with a better Game C before the semester starts.
What will probably be the deciding factor between them, if both are choices, is how many other students in the class will be working with me and how many will be working on the other project being discussed for GD4. If I end up working with 1-3 other people, or just myself, I’ll probably advocate going for Game A. More than that, and I’ll advocate going for Game B.
Quick last note: I’ll be editing in a bunch of links later. I know there’s a bunch of jargon and unexplained acronyms. The links will explain everything.