I ended up going with a very simple overall design for my V4D game: A text adventure in the spirit of the Zork games. And so far, i'm finding it a pleasant project that doesn't leech my mental energy in mysterious ways each time I open the folder it resides in.
For once, I'm getting to make proper use of polymorphism, inheritance, and all that stuff I figured out about text parsing, and so far: 'tis been fun.In other news, somebody actually donated some money to me, which kinda… surprised me. Seriously, I wasn't expecting anybody to take me seriously. Oh well.I'm actually having to keep a bit of cash in my PayPal account just in case I need it soon. Living costs and coffee costs up. But I'm hoping to finally find some gainful employment in a part-time position soon.Parsing sentences at a glanceThere are two approaches: The brute force approach (Which is almost always slow) and the smart-but-takes-long-to-implement approach (Tree based). For this comp, I'm using the Brute force method, because it's a game that runs at the command prompt, and nobody cares just so long as the game works as advertised.Now, consider the following sentence:"EXAMINE THE DOOR"First of all, I have a function that throws away all ambiguous words/articles, such as THE, AN, etc. The same function returns the string in lower-case for easier processing (In computing A and a are two very different things; different by 32 to be precise).Once that is done, the first word is passed to a long switch statement/if-else block (Depending on the context), and checked against the verbs I've added to the game.Once the verb is determined, a function is used to check, in this order, the lists containing the Room's objects and Player's objects (Using strstr() to check for sub-strings, meaning that even if DOOR is supplied when the name is LOCKED DOOR, it'll still pick it up).Each item in the game is a class, and each class has a basic set of event functions, something like this: int ev_look(); // Called when the room is looked at, for special cases
// "The awesomeness of the glass chandelier blinds you"
int ev_exxamine(); // For when the item itself is examined/looked at
int ev_take(); // For when the player attempts to take the item
int ev_drop(); // "Your gold watch just rolled down a hole"
int ev_throw(); // Just in case...
int ev_use(m_item* other);
int ev_use(); // For singlular context use
int ev_eat();
int ev_drink();
// etc...
Romantic text adventure? It gets my originality stamp (as far as I know).
Dev logs are interesting to read. Each time I read one I tell myself I should keep one for my own projects.Regarding the challenge, I personally don't think you're going to get much interest here, as code-specific blogs are somewhat rare. You did give me an idea though, and that is if we're going to have bi-monthly gamedev competitions, we could vote or have someone choose the host for each competition, and then said host could decide the theme of that particular competition. For instance, should you be host, you could decide to place more emphasis and importance on code (and maybe implement a checksum calculator as a game mechanic somehow idk if that made sense at all as idk wtf a checksum calculatori s D:)A checksum calculator traverses all the bytes of a file and adds them into a 32-bit (Or 64-bit, etc) integer value, aka the "checksum" of the file.
You could use the checksum as a random-seed for a level generator, I guess, but that's a bit… odd.EDIT: About dev logs. I write them for a good reason, and that's to determine the validity of what I'm doing. The plausibility.I work it out like this: If I can't describe what I'm doing or trying to do in a readable document that I'm not afraid to upload to the internet, then I probably shouldn't be doing what I'm doing.