Consider using regex for room data parsing

[mspraggs]

I'm not dead! And neither is my sense of moral outrage! Props if you got my reference to The Simpsons. If not never mind.

I'm very impressed with the new level designs and so forth. Looks good, and I actually spent a bit too long trying (and failing) to pass some of the levels this morning. It's cool to have the life/score counters also appearing at the corners of the screen. Looks professional!

Anyway, my significant absence is mainly due to just being swamped with work (e.g. thesis, papers, demonstrating etc.) and other life-related stress (e.g. landlord selling our flat and having to move). As a result I'm creating a new category called "code improvements", where I will make possible recommendations on how the code could be tidier, but which you're totally at liberty to ignore, given my minimal level of involvement.

Anywho, I had a look at World.cpp and noticed something immediately. How about using the C++11 regex library to parse the world data files? I haven't a great deal of experience with it, but in principle it should be possible to find all the relevant information in a relatively succinct way. Anyway, just a thought.

[DivFord]

Thanks Matt! I think part of the challenge comes from the weird jumping, but I'm flattered nonetheless. By the way, your level code was lovely to work with: it was a huge relief not to have to fiddle with the char map or the python script. They worked fine, even after I changed a bunch of other stuff.

I did consider using regex, but the files were so simple that I didn't think it was worth adding another library. My regex experience is with javascript though, so it's possible the C++ is more elegant. I'll have a look into it.

[mspraggs]

Thanks, I'm glad it worked well.

Regarding regex, my experience is that it's less elegant than Python, but then I find Python to be elegance... personified? Anyway yeah it's a bit fiddly if I remember correctly, as you have to create and pass in a special match object. Details here. Doesn't look so bad in hindsight, so may be possible. Up to you.

[Fyll]

And neither is my sense of moral outrage!

O.o Oh no, did we do something terrible!?

Props if you got my reference to The Simpsons.

Phew! You had me panicking for a second. Slight scare aside, welcome back.

The new levels do look great, although they have suggested to me that something needs to be done about floating/sinking props moving into narrow spaces. They've also taught me that it's hard to play one-handed....

[DivFord]

Wait, your floating/sinking blocks screw up in narrow spaces? Mine only behave properly if they have walls to channel them… If I put them in an open space, they ping around the map and send all the other props flying through the walls.

[Fyll]

I just mean that they bounce off of corners. I haven't seen them in an open space yet, so couldn't comment on that.

As a quick point, you seem to have missed the air block at (5, 1) on the menu screen. It's not in levels.cpp, and I don't believe I should be editing that, and haven't got the hang of the editor yet.

[DivFord]

It used to add an air block when it spawned an entrance, exit, prop or unit, but that caused the new system to segfault, so I took it out. In theory the editor should be placing air blocks anyway (and I think the double-placement was causing the crash), but it misses them in some cases. It's on my list of things to fix.

[Fyll]

What if the entrance and exits were no longer Blocks, but were just bits of data passed in in the rooms properties? Then we could get rid of the Entrance and Exit Blocks from BlockList, and could allow you to enter or exit the levels on non-air tiles.

Also, what does the meta-data do/look like? I've been thinking of trying to pass it through to the AI (so we can do path-following enemies) but don't know what the format will be like. I suppose I could just pass it as a string, then do whatever the AI would like and hope that the types match....

[DivFord]

That works for me. Would we want the level format to change (eg. listing entrance/exit under properties instead of blocks) as well?

Meta-data is inherently vague, since it's basically trying to account for every edge-case where we want to track extra information in the save file. I think it pretty much has to be a string, which occasionally gets parsed into an integer. So far, I think we've proposed the following kinds of metadata:

• Interactions between props (eg. key and gate) - Integer?
• Timer values (eg. for traps?) - Integer? Float? The latter would likely cause problems.
• Patrol Paths - Coordinates, therefore integers?

I feel like we'll want the option to use strings, but so far I can't actually think of an example that isn't an integer or boolean.

[DivFord]

I missed the "what does it look like" part of your question. Basically, if "El(3,1,L)" is a left-facing lizard at (3,1), "El(3,1,L,4,1)" would be the same lizard with two meta-data values (4 & 1). Presumably the other end of his patrol path. Essentially, anything after the default data (for units, x-coord, y-coord and facing) and the closing bracket is metadata.

[Fyll]

I'd imagine it'd be better to change the format that faff about with Blocks-that-aren't-Blocks.

If it just gets read in and passed around as a string until it's where it needs to be, then translated, we could just use the parseToWhatever() functions I wrote for the UnitData parser. If you haven't looked at it, I wrote a function for every type I could think of that converts a string into that type. They're currently inaccessible outside of the .cpp they're in, but it shouldn't be too hard to work around that. That way it could use floats or Vectors or vectors of Vectors or anything (on this end at least).

[Fyll]

I've added the ability for the AI to read the metadata, and consequently the floating platform is back in, except now with the option to make it follow any path you want! :D

I've also added a thing that lets you put a message into the Unit files, which will be printed when the game runs. The idea behind this was that people could just add Units (or eventually Props, etc.) with as little information as they want, but stick a note in it saying "Get this working somehow" or "Needs graphics" or whatever.

Okay, Github kind of does this already by way of us creating issues for things, but I've always felt that making an issue for something was making something of a fuss about it (i.e. issues are for biggish things in my head). Should I have bothered?

(P.S. The -dh flag has some added functionality now, in that it also draws the metadata paths in green.)

[mspraggs]

To the latter point regarding notes in the Unit files: I like this, it sounds like a good idea :-)

Also, generally speaking, single-line comments that start with TODO are generally picked up by editors and highlighted differently, so this is sometimes a good way to indicate a small thing that needs to be addressed at some point, even if it isn't urgent.

[Fyll]

True, but I often forget that they're there until I look back into the file (and I'm usually back in there to fix the problem anyway!). I'm also thinking of adding a flag to print them, instead of just auto-printing them, as it's very quickly become a little bit annoying.... :P

EDIT: Okay, this flag has been added and pushed. Append -msg to make it print out any messages.

[Fyll]

Blocks and Props now also use this system. That I can tell, everything still works the same, but the data files have all been turned into .txt's (hooray!). I'm not sure if it's worth converting Bullets, Guns, and Menus over to this system to, so haven't (and won't be until someone persuades me otherwise) bothered with that.

I did remove the Gate Prop in the process, because it did absolutely nothing, and probably didn't work at this point anyway. I was having a slightly dodgy time with regards to Props that are bigger than a tile (so Explosions may be a bit funny for now), and figured it wasn't worth the hassle of keeping it in and having to write out a data file for it until I sorted this out.

[DivFord]

I love the new data files. Definitely easier on the eye (and the brain) than the old header files.

My one complaint is that none of the props seem to have art anymore. I just get weird black shapes. Does this happen for you two, or is it just me?

Actually, two complaints. Rising blocks don't rise properly. I seem to remember you mentioning that they wouldn't go into narrow spaces for you, which is what I'm seeing now, so I might just be late to the party.

[Fyll]

Maybe try repulling? I didn't notice the Prop issue when I first pushed, but noticed it yesterday (ebd8020) and think I fixed it (they're fine for me now). The problem was that I'd accidentally zoomed them in.

I may have also fixed the Rising props problem. I definitely fixed a problem they had in that push, and they also seem fine for me now.

Yeah, that push did seem quite lazy in retrospect. I guess I should have checked things beyond the menu screen....

[DivFord]

Yup, it's fixed now. Good job.

I may have identified a bug with the freeze ray, but I'll need to try reproducing it.

[Fyll]

I've added example data files (with comments!) for each of the Objects, so hopefully it should be really easy to add things now (e.g. I'll leave adding an invincibility Pickup to someone else :P).

Okay, that's enough user friendliness. Now back to fiddling with the collision engine....