next »

[happymonster]

Yes, I have to do one for the demo.

[Franklin's Ghost]

Looking forward to the demo and nice to see such continuous updates.

[happymonster]

Cheers!

[happymonster]

Don't you just love game-stopping bugs that only suddenly appear in release builds.. 

[happymonster]

The last few days have been a total b*tch.. The release build managed to break zlib's gzip functions, but in a very specific way. It would open a gzipped map file with no errors but the very first byte read (and all subsequent ones) would come back as End of File reached.

I thought it was some kind of memory corruption issue, so I moved the code that loads a map progressivly up the called functions of the game setup to find out where it was going wrong. I ended up putting the code at the very start of my game (after the engine has setup first) and it still went wrong. Now, the engine is by a friend of mine who has used it for some successful shareware games and I've never seen this issue before, nor has he. I doubt zlib is broken in this way either so I thought it must be in some other code. But I have nothing in header files that would seem to cause any memory corruption.

So, here it gets weirder..

As part of the testing if I called the load_map function 10 times in one part of the code it would fail on the first 3 attempts and then work fine on the next 7. Always in the same pattern on every run. If I added a line of code that had no effect on anything else (just calling a function to set a variable) it worked. If I uncommented out a line of code that is never executed it failed the first two times then worked every time after.

The last test I did after moving some code again it worked 11998 times (yes, I did a repeat loop test that many times), and then failed on the last two tests in the same for-next loop!

As this bug only happens in release mode and every time I change a line it can alter the pattern it's been impossible for me to fix. 

I don't like doing it as it feels like the game is built on sand rather than a solid foundation, but for my own sanity I've switched the map loading and saving to using uncompressed files. Bigger maps, but it works every time now. I have no idea why this error occurs..

However, you can now expect a very early demo this weekend..

[eigenbom]

I'll drop my 2 cents here..

Sounds like a classic memory violation issue, like writing past the end of an array. The debug build adds extra stuff in memory and on stack, so the overflow probably doesn't write over anything important in debug mode, but in release mode ... kazaammm! So check all your arrays and make sure you aren't writing past the end of them, including char buffers. Also, double check you are using the release builds of all the libraries too.

[happymonster]

Yeah, I thought that too. But I'm getting this effect at the very start of my code after the Engine has setup, which is why I'm wondering if it's actually in the Engine and not in anything I'm doing.. I might have to switch to another engine at some point down the line.. :/

[happymonster]

Demo 1

No sound, but it's Demo time!

Firstly: I hope it works!

Second: Use arrow keys to move and left control and a direction to shoot. Pressing Escape exits to the editor. Pressing Escape in the editor will quit the game. If you delete the test.map file in the map folder then you will have a blank map to edit when you rerun the game.

There are still some issues I'm aware of, and bugs to fix.

But.. does it feel like it could be fun? This level is very action orientated, once I add more puzzle tiles it will be possible to make those kind of levels too.

http://www.retroidea.com/Blue_I_Demo_1.zip

All graphics (and the name) are placeholders. C&C is welcome!

[eigenbom]

It works! Had a quick play, I like the in-built editor and the game runs smoothly.

I can see the game having potential, but it's still a long way off and it's hard to see where it's going. I think you have to choose a direction: Gauntlet, Saracen, Adventure, Rogue, ... and push the game in that direction. That will determine the features you focus on, and the level design.

At the moment it feels like you've got a bunch of simple mechanics (keys, doors, brickwalls, ...) and seem to be attempting to make a level that uses them. They have no limited connection to the enemies, apart from releasing them from their closed off compartments.

Moving and shooting with the same direction keys is too awkward. Those arena shooters usually have dual joysticks, or mouse-click to shoot, don't they? But if the game was more strategic, with fewer enemies that move slower, the current method may be fine.

I don't think the diagonal movement of the creatures works. The entire game is grid oriented, so having things move diagonally breaks that, especially when they move through a corner wall. Maybe this would be fine for special 'ghost-type' creatures that break the grid-rules.

Anyway, good luck!

[happymonster]

Thanks for trying! I'm glad it works ok.. :D

I think you have to choose a direction: Gauntlet, Saracen, Adventure, Rogue, ... and push the game in that direction. That will determine the features you focus on, and the level design.

Well, the core idea I want to keep is that this is more of a Sandbox. I want the player to be able to create the type of level (and game) that he wants. Whether that is pure action, puzzle or something in between.

At the moment it feels like you've got a bunch of simple mechanics (keys, doors, brickwalls, ...) and seem to be attempting to make a level that uses them. They have no limited connection to the enemies, apart from releasing them from their closed off compartments.

I thought that was how people made levels? Can you clarify what the alternative is you are suggesting? I'm not sure I quite understand what you mean here.

Moving and shooting with the same direction keys is too awkward. Those arena shooters usually have dual joysticks, or mouse-click to shoot, don't they? But if the game was more strategic, with fewer enemies that move slower, the current method may be fine.

Really? I thought one joystick and one fire button was the norm in a lot of the older games. Maybe that's the issue. Do you think people will see this as wrong because they are used to dual joysticks or mice?

I don't think the diagonal movement of the creatures works. The entire game is grid oriented, so having things move diagonally breaks that, especially when they move through a corner wall. Maybe this would be fine for special 'ghost-type' creatures that break the grid-rules.

I don't agree on the diagonal movement (though moving through a corner wall looks odd). I think I will have other enemies that only move in 4 directions and level settings to limit player movement and firing to 4 directions as well if the player wants to use them.

Thanks for the C&C!

[surt]

Works under Wine for me, though for some reason I have to manually alt-tab into it to get input to work.

Moving and shooting with the same direction keys is too awkward.

Worked for Gauntlet. Though a more modern option (wasd move, cursors fire) would be a nice option.

I reckon the diagonals is cool as is.

[happymonster]

Cool, thanks for trying it!

[siskavard]

Holding CTRL + arrow keys to shoot is way too clunky. You should maybe consider a Binding of Isaac style control/shooting scheme.

Other than that I would tend to agree with eigenbom's feedback. Feels like it could go in any direction.

[happymonster]

Thanks siskavard!

I think the control scheme is related to the fact that this is how Dandy works and suits my playing style. You have to advance and retreat (without shooting) and then pick off enemies all around you. It's a bit like a Sniper style. I can see that those who lead to wade in shooting everywhere would find the current method not suitable.

I'll try adding in a WASD fire key pattern as well as a second fire button which lets you shoot and move. I'll see how that works.

I'm also going to start adding in more puzzle based tile types (inspired by Chips Challenge and other games).

[Udderdude]

This looks interesting and reminds me somewhat of some of my own games, will try it out later.

Edit: Yeah this could really benefit from WASD firing and also allowing the player to fire while moving, unless you don't want the player to be able to do that.

I also felt it was rather boring sitting in front of a narrow chokehold killing enemies that were endlessly streaming through while holding down the fire button.  Having the player sit there and do that isn't paticuarly interesting.  IMO the enemy spawners should only activate when the player is close to them.

[eigenbom]

Thanks for trying! I'm glad it works ok.. :D

I think you have to choose a direction: Gauntlet, Saracen, Adventure, Rogue, ... and push the game in that direction. That will determine the features you focus on, and the level design.

Well, the core idea I want to keep is that this is more of a Sandbox. I want the player to be able to create the type of level (and game) that he wants. Whether that is pure action, puzzle or something in between.

Yeah but in a Sandbox the player has freedom to do pretty much anything in the game, and make their own goals, and/or can build things in the game. Providing a level editor doesn't make the game a sandbox, otherwise Duke Nukem3D, Doom, etc., would all be considered sandboxes.

At the moment it feels like you've got a bunch of simple mechanics (keys, doors, brickwalls, ...) and seem to be attempting to make a level that uses them. They have no limited connection to the enemies, apart from releasing them from their closed off compartments.

I thought that was how people made levels? Can you clarify what the alternative is you are suggesting? I'm not sure I quite understand what you mean here.

I'm not talking about levels, I'm talking about the process you are using to make the game.

An alternative would be to design a level on paper and then, from that, infer or design the primitives of the game. I'm not sure what you exactly did, but all I said was that it "felt" like a bunch of disconnected mechanics trying to be arranged into a level.

Moving and shooting with the same direction keys is too awkward. Those arena shooters usually have dual joysticks, or mouse-click to shoot, don't they? But if the game was more strategic, with fewer enemies that move slower, the current method may be fine.

Really? I thought one joystick and one fire button was the norm in a lot of the older games. Maybe that's the issue. Do you think people will see this as wrong because they are used to dual joysticks or mice?

Well in Saracen you only ever have one item, and the projectiles have a pre-specified direction. So, e.g., you pick up a left facing arrow, then pressing fire will shoot it in the left direction. This constraint actually led to some really great puzzles. Other games, like Wizard of Wor, iirc, shoot in the direction you are facing. Not sure about older C64 arena shooters.

GL!

[happymonster]

I'll have to think about all of this. Clearly some issues with the game at the moment.

[happymonster]

I've taken a break for some days to think about where I want the game to go. I'm currently leaning towards the idea of making it more puzzle focussed, with larger tiles so you can see less of the map at once. Also a new graphical style (less iconic).

Still debating it all though..

Any thoughts?

[eigenbom]

Play saracen!

[siskavard]

I really like the bold, iconic graphics.