If he made this with Gamemaker 6, then chances are he is with gm8 or newer and probably some things from 6 would not work on 8 or should be completely changed.
Btw I tried the compiled version with gm8 and it works. It looks really advanced, though there are some graphical glitches.
[old thread] BomberKEEN
I've recieved the much more advanced Game Maker Bomberman version from the author.
The version is indeed much more advanced, and easier to mod - though damn, here characters need even more frames, what a headake
.
Currently I have problem running it or converting it - as it's 8.1 version, and my 8.0 version doesn't open it - and 8.1 lite version doesn't run or export it.
The version is indeed much more advanced, and easier to mod - though damn, here characters need even more frames, what a headake
.
Currently I have problem running it or converting it - as it's 8.1 version, and my 8.0 version doesn't open it - and 8.1 lite version doesn't run or export it.
-
Dr. Kylstein
- Vortininja
- Posts: 151
- Joined: Sat Feb 14, 2009 4:39
Cool! Seem to work fineDr. Kylstein wrote:bkeen32.exe is a version of BomberKeen that runs in 32bit DOS. It doesn't add any features, but I'd like to know if it adds any bugs. Going forward, it may save me some trouble with memory limits.
Without memory limits we can do so much more with it.And don't worry, my GM version is still relatively stuck, without a coder. Original author doesn't have the time to be a coder of this. But he offered help if I have particular questions or challenges. He also offered the same type of help for szemi.
A few direction question for the Dos version, after playing Game Maker bomberman versions.
Do we need to prepare/lay a foundation/support for future gameplay advancements?
1. Do we need to make standard character size much larger to later support riding creatures - and larger characters? Our current character size is very limiting.
2. Do we need to support more art for characters, for more advanced powerups and gameplay elements? There are special frames for hitting/"boxing" the bomb (last GM version has even 3-frame animation, but that can be too much), for carrying and throwing of the bomb (bomb throw powerup), for riding an animal, last GM versions has frames for being stun/dizzy and even for character jumping and for afterdeath mode...
If we won't expand our frameset now - it might limit us much in the future. Though it adds alof of more artwork to existing and future creatures, so mod will be harder to make and harder to mod/add custom content.
3. GM version uses bomb of different colors to separety type of bombs.
4. Afterdeath mode where you try to get back into the game after dying? Should we support it? Last GM version has it supported.
Do we need to prepare/lay a foundation/support for future gameplay advancements?
1. Do we need to make standard character size much larger to later support riding creatures - and larger characters? Our current character size is very limiting.
2. Do we need to support more art for characters, for more advanced powerups and gameplay elements? There are special frames for hitting/"boxing" the bomb (last GM version has even 3-frame animation, but that can be too much), for carrying and throwing of the bomb (bomb throw powerup), for riding an animal, last GM versions has frames for being stun/dizzy and even for character jumping and for afterdeath mode...
If we won't expand our frameset now - it might limit us much in the future. Though it adds alof of more artwork to existing and future creatures, so mod will be harder to make and harder to mod/add custom content.
3. GM version uses bomb of different colors to separety type of bombs.
4. Afterdeath mode where you try to get back into the game after dying? Should we support it? Last GM version has it supported.
In "Bomberman" (in "more than 2" players mode), player after dying moves to outside moving platform trying to throw bombs into the main arena and kill "living" players, to replace them - if hit.MoffD wrote:Usually in vs. you have 1 life and can get moreDoomJedi wrote: 4. Afterdeath mode where you try to get back into the game after dying? Should we support it? Last GM version has it supported.
This is very nice gameplay element - taking "dying" player out of the field, and yet giving him something to do while he waits a new game - with a good chance to return to the game.
-
Dr. Kylstein
- Vortininja
- Posts: 151
- Joined: Sat Feb 14, 2009 4:39
Prior to working on the 32bit version, I was trying to implement support for defining frames and animations in text files (similar to the layout files I've been using). This would cover #1 and #2.DoomJedi wrote:A few direction question for the Dos version, after playing Game Maker bomberman versions.
Do we need to prepare/lay a foundation/support for future gameplay advancements?
1. Do we need to make standard character size much larger to later support riding creatures - and larger characters? Our current character size is very limiting.
2. Do we need to support more art for characters, for more advanced powerups and gameplay elements? There are special frames for hitting/"boxing" the bomb (last GM version has even 3-frame animation, but that can be too much), for carrying and throwing of the bomb (bomb throw powerup), for riding an animal, last GM versions has frames for being stun/dizzy and even for character jumping and for afterdeath mode...
If we won't expand our frameset now - it might limit us much in the future. Though it adds alof of more artwork to existing and future creatures, so mod will be harder to make and harder to mod/add custom content.
3. GM version uses bomb of different colors to separety type of bombs.
4. Afterdeath mode where you try to get back into the game after dying? Should we support it? Last GM version has it supported.
#3 Different bomb graphics sounds feasible.
#4 I think I will try to implement bomb-throwing, but I'm afraid the additional sprites will slow the game down.
A question regarding animation definitions: Would you prefer recording the corner positions of each sprite frame in a text file, or splitting the frames into different files?
Can you explain what parameters it allows me to control?Dr. Kylstein wrote: Prior to working on the 32bit version, I was trying to implement support for defining frames and animations in text files (similar to the layout files I've been using). This would cover #1 and #2.
Game Maker version has colors for bounce bomb, wall pierce bomb...pushable bomb too? I wanted to have unique color for remote control.#3 Different bomb graphics sounds feasible.
But remote control is useful for Single Player, too much power for vs. battle.
#4 I think I will try to implement bomb-throwing, but I'm afraid the additional sprites will slow the game down.
Well... Won't look well without animation....are we THAT limited? Sad to hear, especially if we want to add game modes, creatures, features....You need to turn the bomb first into a sprite and not a tile - for all those things.
Can you explain me the difference, and advantages of each method?A question regarding animation definitions: Would you prefer recording the corner positions of each sprite frame in a text file, or splitting the frames into different files?
-
Dr. Kylstein
- Vortininja
- Posts: 151
- Joined: Sat Feb 14, 2009 4:39
The animation definitions would allow you to use frames of any size and to control the speeds and frames used by animations. You could also define new animations, but I would still need to program the game to use them.
I could handle either way of identifying frames. I want your opinion about which you think will be more work for you. Personally, I found recording the corner coordinates of each frame for my prototype tedious, but I don't know how that would compare to splitting up all the existing frames.
I could handle either way of identifying frames. I want your opinion about which you think will be more work for you. Personally, I found recording the corner coordinates of each frame for my prototype tedious, but I don't know how that would compare to splitting up all the existing frames.
I'll try to add bomb throwing frames tomorrow.
We also have bomb boxing frames, with related powerup we need to code. In general, - those are quite simular in the way they work.
Do we want dizzy frame if hit by thrown bomb? It stuns the player for a sec. Nifty element.
Can we wait for that one day? Promice an answer tomorrow.
We also have bomb boxing frames, with related powerup we need to code. In general, - those are quite simular in the way they work.
Do we want dizzy frame if hit by thrown bomb? It stuns the player for a sec. Nifty element.
I need to sleep on that. It's late here, I'm sleepy, and can't think clearly enouph.I want your opinion about which you think will be more work for you. Personally, I found recording the corner coordinates of each frame for my prototype tedious, but I don't know how that would compare to splitting up all the existing frames.
Can we wait for that one day? Promice an answer tomorrow.
Hard to decide. I tend to prefer offsets, as it makes you easier to copy/paste existing frames into new frames and actions - working within a single file. Also constant tileset frame structure makes you easy see what frames you lack for that character and monitor your progress, also the role of each frame - by their placing within the spriteset.
Also cell sctructure makes it easier for you to align sprites.
But I'd prefer that all frames will be within constant 32x32 cell, just like in my latest GM BomberKeen version - and not a random set of frames of different sizes.
This will make easier on the offsets.
The bottom center of such a 32x32 frame would match the bottom center of the battle area cell, and the rest of the 32x32 image (including transparency) will display above/aside of it.
I think it's the best concept.
The sprite mask (for collisions etc.) should stay the same for all characters - independent of their visual size...and probably match the basic cell.
Also cell sctructure makes it easier for you to align sprites.
But I'd prefer that all frames will be within constant 32x32 cell, just like in my latest GM BomberKeen version - and not a random set of frames of different sizes.
This will make easier on the offsets.
The bottom center of such a 32x32 frame would match the bottom center of the battle area cell, and the rest of the 32x32 image (including transparency) will display above/aside of it.
I think it's the best concept.
The sprite mask (for collisions etc.) should stay the same for all characters - independent of their visual size...and probably match the basic cell.
-
Dr. Kylstein
- Vortininja
- Posts: 151
- Joined: Sat Feb 14, 2009 4:39
