mspraggs / potentia Goto Github PK

I'm not sure if this is because Iain's fixes haven't been pushed yet, but this was still happening for me.

@Fyll : I'm setting up the tiling refresh like we talked about, but it mucks up every time I destroy a block. When blocks get destroyed, are they replaced with air blocks, or just removed altogether?

It seems like gravity is a lot lower since the last update. Have you changed it?

Eventually we should sort out sound so it can play on any machine. OpenAL has proven itself to not be up to the task, so, any ideas?

What's nice is that the sound is almost entirely self contained, so if anyone wants to try any alternatives out, they need only change one file (hint hint).

Swimming upwards is needed, and water should flow.

At some point, we will want additional worlds, so there are a few changes to make before we get there.

• I'm going to be organizing tiles into generic tiles (rock, earth, water, ice, etc.) and specific tiles, which will only be found in a given world. Hopefully all on one tile sheet, which means the block ID and the tile ID will need to be separate, if they aren't already.
• We probably want to load and unload tile sheets when we change world.
• Eventually, guns will be assigned to a particular world. Not sure if this affects level naming.

Makes sense to my mind, seeing as it's called Potentia, not GameJam2015. It will require all devs to change the git remote url to point to the new repo, using these instructions here: https://help.github.com/articles/renaming-a-repository/

Let me know if you guys are comfortable with this. If so I'll go ahead and do it, and post here when it's done.

The thing that prints the current room into the console is neat, but seems to be printing each room twice, and printing a load of other rooms first. Are we loading all those extra rooms and throwing them away, or is the bug in the printing function? I'm getting three extra rooms (printed twice each) every time I suicide. The first appears to be the retry room, but the others are just random rooms.

Ideally, I would like to replace the crate smash animation with a particle effect. I'd also like to replace fire, and it would be nice to have particles for block changes (dig and freeze).

In theory, this should be completely encapsulated. It would draw over the top of everything else, and wouldn't interact with the physics. We'd want the following parameters:

• Particle Count
• Particle Size
• Particle Sprite (with animation?)
• Particle Gravity
• Particle Initial Velocity (possibly separate parameters for velocity away from the origin, which will allow particles to explode outwards, and general velocity, which will allow particle effects to have direction - flames rising, for example)
• Particle Lifetime
• Random variation to the above
• Change over time for the above

This is a more long term goal, but it'd be good to refactor and neaten things up to improve maintainability. Some ideas:

• Consistent naming convention. (Camel case?)
• Comments where needed.
• Improve encapsulation.
• Const correctness.
• Implement a model-view-controller paradigm, i.e. separate game logic and graphics as much as possible.

Magnet hand shows firing anim when not firing, and vice versa.

Fire is good, everyone loves fire.

Should we replace the retry screen with something akin to the intro screen? As in, should we replace the balloons with two exits?

The balloons seem stick out a bit, and need some odd code to accomodate them. They're already in and work, but I think it might be nicer in the long run/look nicer.

Suggestions:

• Bigger rooms
• Procedural patterns (fixes #29)
• Level design
• Game progression/lives
• Game score

The mole-mitt is kind of boring at the moment. It functions, but it only does one simple thing, and that's either really easy (run forwards while smashing everything) or really harsh (level 25), which is partly due to its inaccuracy, so doesn't seem fair.
Lv22 is interesting, as is Lv15, but I think some gameplay changes are needed if we want to build many more fun mole-mitt rooms.

(and yes, I should probably make some better animation for it…)

Some adversaries will make the game more engaging.

There appears to be a new bug where projectiles sometimes don't disappear, and sometimes bounce off props they should be affecting.

David has experienced this, but I'll run it through gdb later to see if I can replicate and get a call trace.

The retry screen retries or quits before the third frame of the animation plays.

On the level where there are crates held up by dirt, when two crates fall at once, the upper one falls halfway through the lower one.

Game over...    
Loaded 1 guns
Info: Loading room file david levels/Lv3.txt
Loaded 2 guns
Info: Loading room file david levels/Lv16.txt
Loaded 1 guns
Info: Loading room file david levels/Lv8.txt
Loaded 2 guns
Info: Loading room file david levels/Lv22.txt
Loaded 1 guns
Info: Loading room file david levels/Lv29.txt
Loaded 1 guns
Info: Loading room file david levels/Lv4.txt
terminate called throwing an exceptionAbort trap: 6

I'm pretty sure this is a different bug to the one we had before, because I'd only played six levels.

It would be nice to add bounding boxes to props, with sizes other than the sprite size.

Do we not have a gun in the intro scene? Because firing in the into crashes the game. Would it be worth adding a "None" gun that we assign at startup?

Sometimes, the injury animation just makes the character disappear. Are we resetting the frame to zero when injury plays, or just using the current frame?

On the level where you cross the dirt bridge with random blocks falling from under it (Lv21.txt), it's possible for one random block to spawn inside another, and for both of them to get stuck. We should probably space random block updates at least far enough apart that a block can fall one space. Either that or collision test before spawning a new block.

The character slows down in water, but drop blocks don't. Not sure if this is a bug or just not implemented yet.

@DivFord:

How many signs (like the start and quit ones) are going to be in the game? If it's just those two, making them a special type of block which has those signs on the relevant bits of the spritesheet would probably make that lot of code a lot easier.

Also, the point of the title, is the way the spritesheet is done really the best way to do it? There are several repeated blocks and by my count, there're ~200 missing tile possibilities. Also also, why aren't they all on one line?

Dropping a block on my head fails to kill me, it just gets me stuck, then segfaults.

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libbackend.dylib 0x0000000103f1c22b Block::collide(Object_) + 11 (Block.hpp:33)
1 libbackend.dylib 0x0000000103f2cd34 Object::collideEx(Object_) + 100 (Object.hpp:70)
2 libbackend.dylib 0x0000000103f28542 Game::collisionCheck(Object_, Object_) + 1218 (Game.cpp:212)
3 libbackend.dylib 0x0000000103f285e0 Game::collisionCheck(Object_, Object_) + 1376 (Game.cpp:216)
...
511 libbackend.dylib 0x0000000103f285e0 Game::collisionCheck(Object_, Object_) + 1376 (Game.cpp:216)

I just ran the game, compiled from the latest source, through valgrind's memory checker. I'm getting a lot of memory leaks coming from the graphics code. I've attached the output from valgrind. It shows the call trace for each call to malloc that results in a memory leak. I think we just need to make sure there's proper cleanup/deallocation code in the Window class to make sure all the relevant SDL/GL resources are correctly deleted when the window is closed.

Also, looking at how the Game and World handle the vector of Objects, I'm wondering whether it's worth using smart pointers to handle memory allocation, simply because that way we can be sure all the Objects will be garbage-collected properly.

EDIT: I wanted to upload the leak log, but GitHub doesn't do plain text files, so I'll email.

Eventually we're going to have to handle window rescaling. My question is, do we want to just stretch everything to fit, stretch everything to fit while keeping everything square, leave everything the same size, or something else?

Could someone put a border of blocks around the edges of the room that you can't fall off of (aka left and right, plus top if we're ever going to let the player off of there. It'll just make the code a lot easier with respect to walking out of doors and shooting through them. There's currently a bit of a hacky fix to allow you to shoot through doors, but not walk through them.

The character currently feels very "slidey". Could we add a friction property, similar to viscosity, but checking the block just below the character? Should probably use the highest out of this and viscosity, otherwise walking on underwater rocks will be very slow.

You can die if you jump while running into a wall...

When the character lands, we get a flicker between the falling and idle anims. I'm pretty confident this can easily be fixed by using different distances for the ground check based on whether he's grounded or not. If the check distance is longer when he's already on the floor, tiny bounces shouldn't trigger the anim.

I'll leave this one in your hands, since I can't find that code, and it's probably better if I don't muck around with it anyway.

I'm planning to re-do collisions.

• Collision will be a class.
• It will have the current room and the player as members.
• It will have functions to check for collisions with player, blocks and props.
• Among other things, that should allow props to check for player collisions on canMove, and, if they return one, to call Push on the player. If the player can move in the direction pushed, he gains velocity, if not, we kill him. That allows rise blocks to lift the player, and only kill him if they crush him against something.
• If projectile checks for collisions on all blocks, it can then choose to affect movement based on the isTraversable property, and apply effects independently of that.
• I may as well implement bounding boxes while I'm at it...

Thoughts?

A bit of an aside, but it appears the next Ludum Dare jam is on the last weekend of the Easter vacation...

After playing the ten levels required to win, then clicking the retry balloon, an exception is thrown because a vector is being indexed out of its bounds. Console output:

You won!
Loaded 1 guns
Info: Loading room file david levels/Lv6.txt
terminate called after throwing an instance of 'std::out_of_range'
what(): vector::_M_range_check
[1] 3631 abort (core dumped) ./game

I feel like at the moment we're running into a slight problem with our game design. We said we wanted this to be hard, and for people to replay over and over to see how far they could get. And we've made it a puzzle game. So sooner or later, players will have seen all the rooms a few times, and there won't be any puzzle left, because they'll know all the solutions.

My proposed solution is to introduce more procgen into the rooms. At the moment, most of our rooms fall into one of several patterns:

• Obstacles to clear out the way.
• Steps to construct.
• Platforms to jump between (possibly positioning them first)
• Pits/Pools to get over.

So the theory is that we can mark areas of the rooms not with specific blocks, but with one of these patterns instead, then insert a variant of the pattern before creating the room. Any or all of the room could still be hand authored, by specifying a block rather than a pattern.

The main benefit of the system would be that if multiple patterns were included in one room, as in the last example, the overall puzzle would be different each time. This would work most effectively if the patterns were right up against each other, causing the player to see them as a single puzzle, rather than recognizing the individual elements (not the case in my diagram - whoops).

As far as implementation goes, I think if you marked the top left corner of the pattern with an identifier, and filled in the rest with some kind of 'null' character (say, -), we could just do a pass to find patterns, and replace the characters at appropriate offsets with the characters from that pattern.

[ As an aside, we should maybe sort out our map codes. They're kind of crazy at the moment. Could we maybe make a single cell be two characters, one to specify the type of cell (eg. B for block, P for prop, O for obstacle pattern…) and another to specify the particular variant? Maybe just use the row numbers from the sprite sheet, since assigning letters has become so confusing.]

Wooo! Wall of text. What do you think?

I should be able to push the graphics update tomorrow morning, before anyone starts on bug fixes. I have a couple of questions first though:

1. Where is the background loaded? It doesn't seem to be in file paths.

2. Is there a reason my lovely tiling code is gone? It will be a lot easier to paste my new version in that to adapt it to your replacement. Not to mention considerably shorter.

Following from the refactorisation issue, I think this deserves it's own issue, since it'll probably be one of the more straightforward things to implement.

One idea I did have for the rooms is this. The char type is basically just an integer that can run from -128 to 127 (or 0 to 255 if unsigned). So, I thought a good way to obfuscate the level files would be to run through each room file, take the numeric value for the chars, cast them to integers, then write those out to file as binary data, combining all the levels together in the process. The disadvantage of this would be that the files would end up four times larger than they need to be.

I see someone pushed a design document or three. It's probably going to be easiest if we actually get together to discuss what the plans are now that we're not on a 48 hour time limit.

I have a living room, and can potentially acquire a whiteboard.

Thoughts?

After shooting the yellow balloon, the next level loaded, but with the retry text still there. I suspect the colliders were also there, though not the balloon sprites, since it quit unexpectedly while firing two levels later, but didn't throw an exception.

Info: Loading room file david levels/Lv23.txt
Loaded 1 guns
Info: Loading room file david levels/Lv21.txt
Info: Loading room file levels/Retry.txt
You won!
Loaded 1 guns
Info: Loading room file david levels/Lv18.txt
Loaded 1 guns
Info: Loading room file david levels/Lv19.txt
Freedom!
dhcp-48-171:GameJam2015 Div$

I missed the updateTiles function when I rewrote the tiling code. I'll see if I can find a way to make everything play nicely without having two functions doing the same thing...

David, could you make the water tile see through? I think it would look better if we did that, then drew the water ontop of the player instead of the other way around. It'd have the added advantage that when a block falls on your head, you will disappear behind it, rather than staying in front like you do at the moment.

The ice wand no longer freezes water. All the EFF flags are still in, and the logic is still there, so I assume something is wrong with water collisions.

When I wrote the new system, I originally forgot to put these in before I pushed (in case anyone noticed). I then quickly put something in that seemed to work, but I'm not certain how they were supposed to work in the first place.

Looking through old comments on here and old code, were they supposed to regularly appear from the spot, or just once? Or more to the point, which do we want from now on?

Is it possible for a prop to have a sprite larger than 64x64?

Specifically, I'd like to double the height of the gate sprite so that it overlaps above and below.

Can we set up sprite sheets so that instead of passing an x and a y coordinate, we pass a base vector and an offset? So Rock would have a base of of (0,0) and could be offset horizontally and vertically.

That would allow me to use space more efficiently in my textures, reducing file size, and would help with implementing internal corners.

For example keys and items to gain points, additional abilities.

So, I'm trying to work out a way to improve water….

We have this weird thing at the moment that we get gaps between water and other tiles. I don't really want to remove the gaps, since they look good when not bordering water. Could we add two more layers of tiles? So we would draw backdrop tiles (the rocks and sand in the photo above), then the PC, then transparent water tiles (everywhere we have water blocks, and in spaces horizontally adjacent to those), then the normal tiles.

Something like this:

It doesn't need to happen right away, I just want to know if you think it's viable before I start making the new tiles.