mspraggs / potentia Goto Github PK
View Code? Open in Web Editor NEWSouthampton Game Jam 2015
Southampton Game Jam 2015
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.
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.
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).
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…)
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.
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.
A bit of an aside, but it appears the next Ludum Dare jam is on the last weekend of the Easter vacation...
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.
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)
The retry screen retries or quits before the third frame of the animation plays.
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:
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?
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.
I'm not sure if this is because Iain's fixes haven't been pushed yet, but this was still happening for me.
Fire is good, everyone loves fire.
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.
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.
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$
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.
You can die if you jump while running into a wall...
It would be nice to add bounding boxes to props, with sizes other than the sprite size.
Swimming upwards is needed, and water should flow.
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?
At some point, we will want additional worlds, so there are a few changes to make before we get there.
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:
It seems like gravity is a lot lower since the last update. Have you changed it?
Suggestions:
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 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.
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?
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
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?
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.
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.
@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?
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?
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...
I'm planning to re-do collisions.
Thoughts?
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:
Where is the background loaded? It doesn't seem to be in file paths.
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.
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.
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.
This is a more long term goal, but it'd be good to refactor and neaten things up to improve maintainability. Some ideas:
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?
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.
For example keys and items to gain points, additional abilities.
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?
David has experienced this, but I'll run it through gdb later to see if I can replicate and get a call trace.
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.
Magnet hand shows firing anim when not firing, and vice versa.
The character slows down in water, but drop blocks don't. Not sure if this is a bug or just not implemented yet.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.