Vectrex Programming at German University 2018

[hcmffm]

Some more quick comments on the games in the 2018 project gallery. Please don't take my comments for too serious.

TREASURE DIVER
Wow, what a story! Is this the script for Waterworld II?

ASTEROID COWBOY
I really hope that the game play is fiction, only. The lasso bit will be an interesting part. Perhaps a good idea to have a look at the game play of Star Sling

Y.A.R.G.
- This will be a P.D.R.G. (pretty different racing game).
- I had thought in the year 2100 there would be no such thing as a "Mittelstreifen".

ASTEROIDS
Uhh, there's Minestorm, Rockaroids, Solar Quest, Omega Race, Rocks 'n Saucers, and Asteroids Deluxe, already (the latter ones are not publicibly available, yet). Perhaps various variations (e.g. different enemies, two player simultaneous, different behaviour of player vessel & shots, ...) might make a good new game.

SOCCER SHOWDOWN
I know well what "Abseits" is but I don't quite understand the game play of Soccer showdown. Will there be a ball? Graphics look quite interesting and I'm nosey what the game play will be like.

PYORO-CHAN
Game play sounds a bit like "Kaboom" but this game will be much nicer due to the cute little bird. And the angles to shoot the beans, the holes in the ground, plus the recovery beans will make the game interesting to play.

PORTAL FIGHT
The concept page looks interesting but I'm not clear what the game play is. If I understand right it's two play fields and the portal allows for moving inbetween the playfields. Might work well as a two player game, too.

KEYBOARD HERO / ASTEROID GOLF
Some years ago one of my hobby was dance games (Dancing Stage, In The Groove, Pump It Up). Music games are quite addictive and fun and it's amazing to see what some players achieve (e.g. P'nM).
Though, I'm not sure how well a music game will work on a Vectrex and how hard it is to create good music.

I might be wrong but Asteroid Golf looks like Asteroid Billiard to me. Calculation of the path might be challenging.

Both game ideas are good - hard to decide which one to implement. A prototype/spike ("Durchstich") for Keyboard Hero would be good but prototyping in Assembler or C will take quite some time. :/

A.B.Y.S.S.
A.B.Y.S.S. is a good and suitable acronym! On the Vectrex, space shooters are probably the most common games. But there's still room for another one. Abyss - perhaps the player ship could be a submarine and dive downwards and shoot the enemies that come from the depth. No need to add the water creature, though.

THE COUNT
We all have been waiting countless days for the final release. The completion of "The Count" will come true and this is what really counts. Good luck in finishing your game, Peer!

@all students: Good luck & fun in implementing your first Vectrex games!

[Peer]

Many thanks for your comments on the game ideas, Helmut. This is highly appreciated. Also thanks to you, Vectrexer and Malban, for expressing your thoughts on some of the projects earlier. I will relay your posts to the students in class tomorrow.

I am very curious about how the projects will evolve. Some of the ideas might not seem new, but I still recall that when I started programming back in the eighties, I wrote my own version of Pac Man, my own Bottom of the Screen Shooter, my own Tetris and so on. I guess many programmers did so. Picking a game you like and then trying to recreate it by yourself is fun and probably a good way to get into game programming (some of the students have never written a game before).

Regarding "The Count", yes, you got me there. The game is 98% complete, but every time I wanted to do the last 2% I got side tracked by other things. For example, by doing a complete redesign of the C interface in cooperation with Malban who integrated our C setup in VIDE. Among other things, the redesign involved rewriting the C interface of each and every Vectrex BIOS function, which was quite a bit of work and took some time. But then again, you can rest assured that "The Count" will eventually rise from his crypt. This is just the nature of the undead…

Cheers,
Peer

[Malban]

Regarding Vide - screen recording (capturing this thread :-() )...

I tried implementing a video capture - this sort of works - but is awfully slow. I should put it in an extra thread to work performantly and also should add audio (for now it is video only).
For now I pause with the implementation it seems awfully involved for such a simple thing - and there are heaps of capturing software out there.

I myself (on iMac) have no problems doing any capurings at all (see videos...). I have not tried it with fraps under windows yet.
Though out my head can't think of a reasonable explanation why parajve would work better - since both emulators use JOGL as openGL "core". When I find the time - I will explore further - until than I will let the issue rest- sorry.

Regards
Malban

[Malban]

Apr 16, 2018 8:19:20 GMT -5 Nic Lobo (pucpuc) said:

ok, tried different resolutions (configuration and desktop).
when leaving the black screen with SHIFT F, there is no VIDE Window anymore, but sound is still playing. No way to get the window back. Have to kill the process then.
No log entry. System: Win 8.1, Nvidia GTX660.

Ah...
That is a bug...
Found it - will be corrected...
(curiously - only under windows!)

Malban

[Malban]

Last one for today:

Under Windows 7, with the latest free version of FRAPS I recorded Vide vecx running fullscreen and windowed (than the complete windows screen).

Worked ok.

SHIFT F -> back bug was removed though... but that should not effect recoding itself in any way.

Perhaps this WE I'll do new beta version... with some bugs removed...

Malban

[Peer]

Hi Malban,

many thanks for your efforts, this is highly appreciated, but please do not make this (i.e. screen capturing) a priority. I explicitly state that it may very well have been due to my own incompetence when I failed at capturing the VIDE window. As usual, I was in a hurry, and I had ParaJVE running in parallel, so I just tried capturing its window instead.

Cheers,
Peer

[Peer]

Greetings everyone,

I just wanted to let you know that project "YARG!" is way ahead of schedule and that an early alpha test candidate is already available. A download section has been added to the project web page. Also, the screenshots and the demo video have been updated. The developer would be very happy to get some feedback from external testers

Cheers,
Peer

[hcmffm]

O.k., ready. Let's do it. Last year Malban's game reviews inspired me to also write some reviews for the games developed by the students at the HSPF. Given the tight schedule it was a positive surprise to see that some of feedback was considered by the developer and found its way into the game. This year, I'll also provide feedback on some games if I find the time for it.

My "disclaimer" of last year is still valid:

An important note for all my reviews:
I much appreciate the work, effort, and thoughts that all you students have put into your games! My "reviews" are rather feedback and suggestions and not so much reviews that judge whether a game is good or bad.
Criticizing a game is simple compared to writing a Vectrex game - especially the first one. My criticism is intended to give you hints and ideas to perhaps make your game even better. Some of my ideas might be simple to implement, some might mean quite some effort.
Decide yourself which ideas you pick up and which ones you don't. In no case feel obliged in any way. Even leaving your game as it is now, is fine for me. Though, I do admit that I'm picky and I do like high quality and complete Vectrex games.
If you should have questions regarding a specific suggestion you can post here or contact me via PM (English and German are both fine).

Thank you all for your excellent effort and love that you put into the development of your game!

___

Y.A.R.G!

Below please find feedback for Kevin's Y.A.R.G.. The game is in alpha status and can be played, already.

· GENERAL NOTES
The game play of YARG reminds of the racing game Pole Position. But the game itself is very different. You fly an UFO on the streets and try to avoid collisions with mushrooms. And you can beam the mushrooms. This mixture of science fiction (UFO, mushrooms) and realism (road with medial strip and traffic signs, pine trees) is quite interesting and different. Though, this mixture causes mixed feelings to me and is not quite my style. But why not - remember Jeff Minter's unusual games like the famous Revenge of the Mutant Camels. Graphics of YARG are a bit coarse (not so many details).

· WHAT I LIKE
- Good impression of driving.
- Curves look nice.
- Animated background depending on direction of driving
- The game is fast but playable and one can avoid collisions.
- Little flicker (unlike GCE's Hyper Chase)
- UFO flying in

· BUGS

Sound loop in menu
When the game ends, the menu is displayed. Sometimes the sound is not switched off and you hear the collision sound in a loop as long as the menu is displayed.

Negative energy
Sometimes the energy indicator displays negative energy (i.e. the bar grows towards the left.). Bug appeared using binary "yarg_alpha_no_overlay.bin".

Off-road driving doesn't kill
When driving off-road your vessel is damaged. Sometimes, you can leave the road and drive off-road for a while without getting damaged (the energy alternates between high and low). This can also be seen in the demo.

· SUGGESTIONS

Sudden death
Currently, the player dies and the menu is shown immediately. This means that your score(s) is lost and you might not know your score unless you've looked at the score right before you died. Would be good if there would be some end animation and/or the game would wait a bit till the menu is displayed.

Feedback on events
Currently, there's little visual or audible feedback on events. E.g. it's not clear to the player whether beaming was successful or not. Would be good if events like successful beaming or turbo would cause some sound and visible feedback. E.g. beamed mushrooms could pop into the UFO and make it shake a bit. Hitting a mushroom could also shake the UFO. While beaming there could be a beaming sound. Low energy could cause an alert, and so on. When loosing all energy the UFO could explode or just stop and sit on the road. Feedback, visual transitions, and sound will make the game more "alive" and playable.

Player 1, 2, 3?
In the menu you can choose two or even three players. From what I can see two and three player mode is not supported.

Score: Meaning of scores?
Currently, there are two scores labelled "W" & "C" in the overlay. I guess one score is the distance and the other one is the mushrooms collected. Perhaps this could be mentioned in the manual and/or a better hint on the overlay could be found (e.g. "km" and symbol of a mushroom). Personally I'd find it much better if there was one combined score, only (see next suggestion).

Score: My scores were longer?!
Currently, the scores are displayed as bars. Comparing scores is quite difficult because of the bars (especially when playing without overlay) and because there are two scores. One score for both distance and collecting displayed in numbers would be cool for the players because they could compare their scores and really compete, then.

Gameplay: Increasing difficulty
Currently, the game's difficulty seems not to increase while playing. Would be good if the game started easy and would become more and more difficult.

More sound
Currently, there's very little sound in YARG. Would be cool if there was the typical UFO sound when the UFO emerges. And there could be a permanent, low sound of the UFO engines.

Signs on the road?
Currently, there are traffic signs on the road which can kill you. Instead of the traffic signs a different obstacle might be found. E.g. there could be other cars, oil spills, or small rocks on the street. Alternatively, the traffic sign could be at the bottom (without the pole).

Game play: Game balance / role of the mushrooms
I'm not sure whether it's the problem in the concept of the game or just a problem of the game balance:
Currently, you can fly around for minutes without collecting any mushroom. After hitting a mushroom you use the turbo mode for a very short time and all is fine, again. Apart from the score (and the collisions) the mushrooms are no important element of the game.

The following changes might make the game play more consistent and challenging:
- Flying costs energy.
- Tractor beam costs energy.
- Hitting an obstacle or driving off-road costs energy.
- Beaming a mushroom is the only way to get new energy.
- Turbo mode is not needed (or could be still available but add very few energy, only).

This modification will force the player to collect mushrooms, otherwise he/she will run out of energy and the game will end.


--- Minor issues from here on ---

Tractor beam: Immediate on/off (timing)
Currently, you can switch the tractor beam on and off as fast as you want, there is no limitation. It might be more realistic and challenging if there was some limitation. E.g. after pressing the tractor beam is active for 0.5 seconds. Or: Switching the tractor beam on and off could cost energy. (Currently only the active tractor beam costs energy, switching on/off is for free.)

Tractor beam: Immediate on/off (animation)
When pressing the button for beaming the UFO is immediately at the top and the tractor beam is fully active. And when releasing fire button the tractor beam is gone and the UFO is at the bottom. This quick switching makes the game unrealistic. A quick animation might look good and right timing for beaming the mushroom might become part of the game play.

Tractor beam: graphics
Currently, the tractor beam has a horizontal line at the bottom. I wonder whether it would look better without that horizontal line.

Tractor beam: flicker
Currently, the tractor beam looks very static. Instead, the tractor beam could flicker by drawing it every second or third time or by changing its brightness.

Brightness
Currently, it seems to me that the same brightness is used for all the graphics. Suggestion: Hills in the background could be dimmer. Road segments towards the background could be a little bit dimmer.

Turbo: Checkbox
The Turbo indicator resembles a checkbox of Windows. Perhaps a different (futuristic) symbol to indicate the high/low speed could be found (e.g. "H" / "L") or a small and a large triangle.

Rectangular Sign: Graphics
Currently, the pole of the rectangular sign is a bit fat. A thinner pole might look better.

Pine tree: Graphics
Currently, the pine tree is very symmetric and the trunk of the tree looks a bit fat. The pine tree might look better if it wasn't symmetric and if it had a thinner trunk. (Some random factor which results in different tree shapes might look interesting.)

Incoming UFO: Improved animation
I like the incoming UFO. Perhaps this UFO animation could be improved a bit by...
...changing start position (left / right)
...UFO sound.
...use different speeds (fast approach, slow landing on street)


- o -

[Peer]

Greetings everyone, and sorry for the long silence.

I had meant to write (much) earlier, but somehow work and life always came in between whenever I wanted to post a few lines. To cut things short, here is the latest news:

- A beta release candidate of project YARG! is available for testing.
- An alpha release candidate of project Asteroid Cowboy is available for testing.
- An alpha release candidate of project Floor is Lava is available for testing.

- The developers would be very happy about feedback from external testers.

- The semester is drawing to a close, and there have been many updates to the project gallery and to the individual project pages.

Cheers,
Peer

[Peer]

Addendum to my previous post:

Of course it would be great to read more of your thoughts about the 2018 projects here on the forum

I know that I myself have been rather quiet here in the past, so I will try to make up for that and set a good example and post a couple of things as they just crossed my mind.

- Playing Asteroid Cowboy is much more fun on a real Vectrex, i.e. with a real controller rather than with the cursor keys on a keyboard.
- Floor is Lava features some nice background music.
- The binary of YARG! is still with the 4K boundary, which is quite amazing, considering that the game is written entirely in C (including all the overhead introduced by a C compiler in comparison to native assembly language programming). Even more so as the game now also features sound effects and a title melody, as well as several other improvements which were implemented in response to the feedback of the alpha testers (many thanks once again to everyone who sent in evaluation reports!).
- The current semester rapidly draws to a close. With the exception of YARG!, most of the other games have not yet been thoroughly tested on a real Vectrex. We will hopefully find the time for this during the next weeks. Final project deliveries are scheduled for mid of July.
- One of the students constructed and built his own flash cartridge for the Vectrex from scratch as a separate project work. The first prototype already works quite nicely, and his aim is that the final version can remain inside the cartridge slot while programming and testing (no removal necessary for flashing).
- The programmers of Treasure Diver and Asteroid Cowboy also started out with an additional project running in parallel to the course. They ported their Vectrex projects to the GameBoy. Though porting might not be the right word here. They started out by designing their C code to compile for two different target systems, basically by separating game logic from target specific implementations, which is a nice challenge considering vector-based hardware vs. pixel-based hardware. Once available, I will probably add some screenshots of the GameBoy version to the Vectrex project pages.
- Currently, yet another student (actually one of the members of the 2017 Vectrex course) is working on his Master’s Thesis, investigating the possibilities of writing an LLVM backend for Clang, targeting the MC6809 processor. It would indeed be very nice to have Clang as a compiler for the Vectrex, as gcc6809 is not continued anymore and is based on gcc version 4.3.4, which is really old by now. Unfortunately, LLVM’s intermediate code format is designed to heavily support multi-register processors with general-purpose registers, which is the exact opposite of MC6809 (and of many other early 1980's processors). As of now the chances of success are still a bit unclear.

That’s it for now

Cheers,
Peer

[hcmffm]

Thank you for these big updates, Peer! I'll do some play-testing of Asteroid Cowboy and Floor is Lava in the coming days and will provide feedback, here.

[cNp]

Cool, I'll test out YARG and Floor is Lava on real HW... the bin for Asteroid Cowboy Alpha appears to be missing...

[Peer]

Jun 20, 2018 9:20:28 GMT -5 cNp said:

Cool, I'll test out YARG and Floor is Lava on real HW... the bin for Asteroid Cowboy Alpha appears to be missing...

Many thanks for testing, and also for reporting the issue with the missing binary. There was a typo in the links on the project page. This is fixed now, and all Asteroid Cowboy files should be available.

Cheers,

Peer

[hcmffm]

"Floor is Lava" - the game title reminds me of my childhood when we played "Fire, Water, and Air" in physical educations at primary school. Already, "Floor is Lava" is well made and quite interesting and challenging to play. The varying platforms make the game interesting. A very good thing is that level design is fix (and not random), i.e. you can learn the order and mechanics of the platforms and get better by the time. My best score so far: 26 passed platforms.

FLOOR IS LAVA

· GENERAL NOTES
The game play of Floor is Lava is a bit related to last year's "Kingdom of Heaven" and "Doodle Jump". The isometric perspective makes the game look and play quite interesting. Floor is Lava is a one player game and has two difficulty levels. "Game 2" starts at maximum speed and that is indeed quick and difficult to play. The various platforms types are very cool.

· WHAT I LIKE
+ Varying platform shapes and platform behaviour
+ Cracking platforms have a nice animation
+ Background music (my daughter's current favourite hit, btw)
+ Volcano in background (seems to be animated, too)
+ Isometric perspective
+ Fix level design (i.e. the platform always occur in the same predefined way)

· BUGS
Immediate jump after game start
Currently, when starting a game by pressing button 4, the game starts and the player jumps immediately.
Suggestion: The player should only jump if button 4 state changes from "not pressed" to "pressed".


· SUGGESTIONS

Horizontal walking
The player can jump from platform to platform and walk on platforms.
Currently, horizontal walking is not needed much because when jumping you can do a huge jump to the left or right.
Suggestion: Use the walking on platforms as a required element of the game.

Diagonal jumping and scrolling

Currently, the perspective is isometric while the player's jumping is straight upward.
Suggestion: Jumping should be isometric, too. I.e. when jumping the player should jump diagonally towards the top/right. And the platforms scrolling should be diagonally, too. This diagonal jumping would increase the impression that the player actually jumps horizontally from platform to the next.
(Note: This diagonal jumping and scrolling might not work out well for various reasons. But it might be worth a try).

Game difficulty
Currently, the difficulty of the game at the beginning is rather high. Especially the moving platforms at the start make the game quite difficult for novice players.
Suggestion: Game difficulty could ramp up gradually and start a bit easier. Moving platforms should be introduced a bit later in the game.

Usage of platform types/Level design
The various platform types (moving slow, moving fast, melting platform, stable then moving platform) are very cool.
Currently, most platform types (I guess) are shown after the first 20 jumps.
Suggestion: Start with simple (non-moving) platform types and gradually introduce/use new platform types.

Wide/narrow platforms
Currently, most platforms are quite wide and simple to land on them.
Suggestion: There could be platforms which are more narrow. (Perhaps more narrow platforms are used later in the game, already)

Delay between jumps
Currently, when the player lands on a platform it takes a short while till he/she can do the next jump. This is a bit irritating.
Suggestion: Make landing and delay till player can do next jump a bit shorter.
EDIT: I just realized that you can keep button 4 pressed and one jump after another is performed. This makes the game comfortable and quick but much easier because you don't have to care for the exact timing of your button pressing (at least for the first 15 platforms).
Suggestion: Player jumps only when button state changes from "not pressed" to pressed.

__
Minor issues from here on:

Brightness for depth
Currently, all graphics seem to have the same brigthness.
Suggestion: Volcano in the background could be darker. Platforms in the background could be also darker.

Rectangular platforms
The various platform types are very cool (did I say that before?). Most platform types look very natural.
Currently, the rectangular platforms look artifical and not natural.
Suggestion: Make the rectangular platforms also look more natural by making them less rectangular. (see also next issue)

(Partly) random platform shapes
Currently, there are various platform types but after playing few times you know what the platforms look like.
Suggestion: Adding some random number to some(!) of the shape coordinates (while keeping the coordinates of the valid area always the same for easier "collision" detection). This will make the platforms look more natural and make the game graphics varying.


Approaching the volcano
Currently, the large volcano in the background is visible from the very start.
At the start of the game the volcano might be small and at the very right. While playing, the volcano might get larger and larger and move from the very right towards the middle. This way the player gets the impression that he approaches the volcano and actually passes a distance.

Active volcano
Suggestion: Would be cool if the volcano would be every now and then active and fire-spitting like in the background of Stramash Zone.

Platforms graphic w/o bottom line
Currently, all platforms have a bottom line.
Suggestion: Platforms might look better without the bottom line. See grapic example below.
Notes:
- This would even save processor cycles which could be used for something else.
- This might not work out well because of the sinking platforms which appear later in the game.



Player's graphic
Currently, the player's graphic is quite simple.
Suggestion: It's quite difficult to create good vector graphics of humans with few lines only. A bit more complex but still simple graphic might work out quite well. Even a funny player graphic might be used. Player graphic below is one polyline with 11 coordinates. (Kennt eigentlich noch jemand Karl Klammer?)



Some more drafts. Please let me know if more drafts or graphic coordinates are wanted.



- o -

[volcanus]

hcmffm : Thank you so much for testing my game! I highly appreciate your detailed and constructive feedback and all the suggestions that were made. Let me go step by step through them to give you a bit of an impression about my thoughts:

Jun 20, 2018 16:39:19 GMT -5 hcmffm said:

Immediate jump after game start
Currently, when starting a game by pressing button 4, the game starts and the player jumps immediately.
Suggestion: The player should only jump if button 4 state changes from "not pressed" to "pressed".

I just realized that problem while recording the latest game play video, which is why I immediately died after changing to Game 2.
This is going to be fixed as soon as I continue developing the game. 

Jun 20, 2018 16:39:19 GMT -5 hcmffm said:

Horizontal walking
The player can jump from platform to platform and walk on platforms.
Currently, horizontal walking is not needed much because when jumping you can do a huge jump to the left or right.
Suggestion: Use the walking on platforms as a required element of the game.

I pretty much like that idea. By adding walking on platforms as a requirement the overall game difficulty will slightly increase, which is why I don't need to speed up the platforms that much. However, it might be a bit tricky at some point to prevent the player from getting into impossible situations. Anyway, let's give it a try!
Additionally, I am planning to implement a simple player animation for walking, which fits perfectly to this suggestion.  

Jun 20, 2018 16:39:19 GMT -5 hcmffm said:

Diagonal jumping and scrolling

Currently, the perspective is isometric while the player's jumping is straight upward.
Suggestion: Jumping should be isometric, too. I.e. when jumping the player should jump diagonally towards the top/right. And the platforms scrolling should be diagonally, too. This diagonal jumping would increase the impression that the player actually jumps horizontally from platform to the next.
(Note: This diagonal jumping and scrolling might not work out well for various reasons. But it might be worth a try).

In an earlier version of Floor Is Lava, the platform scrolling has already been diagonal. For some reasons it turned out that some players were irritated by the accelerated platform movement while jumping, which is why this feature was removed from the game. I definitly see your point regarding to the isometric perspective and I will try to add this feature again, combined with your other perspective related suggestions below. 

Jun 20, 2018 16:39:19 GMT -5 hcmffm said:

Game difficulty
Currently, the difficulty of the game at the beginning is rather high. Especially the moving platforms at the start make the game quite difficult for novice players.
Suggestion: Game difficulty could ramp up gradually and start a bit easier. Moving platforms should be introduced a bit later in the game.

Usage of platform types/Level design
The various platform types (moving slow, moving fast, melting platform, stable then moving platform) are very cool.
Currently, most platform types (I guess) are shown after the first 20 jumps.
Suggestion: Start with simple (non-moving) platform types and gradually introduce/use new platform types.

Currently, the difficulty is increasing very quickly from the beginning to prevent skilled players from getting bored over the first platforms. Starting with a couple of non-moving platforms might not be a bad idea though. Anyway, I would like to keep the steeply rising difficulty, since players will come quickly in a game flow after playing a few rounds.
Maybe it might be helpful to wait for some more opinions here...

As an alternative, the game could be splitted up into two seperated games with different difficulties, where the first game features platform introduction for novice players and the second game starts on an average level. 

Jun 20, 2018 16:39:19 GMT -5 hcmffm said:

Wide/narrow platforms
Currently, most platforms are quite wide and simple to land on them.
Suggestion: There could be platforms which are more narrow. (Perhaps more narrow platforms are used later in the game, already)

Rectangular platforms
The various platform types are very cool (did I say that before?). Most platform types look very natural.
Currently, the rectangular platforms look artifical and not natural.
Suggestion: Make the rectangular platforms also look more natural by making them less rectangular. (see also next issue)

(Partly) random platform shapes
Currently, there are various platform types but after playing few times you know what the platforms look like.
Suggestion: Adding some random number to some(!) of the shape coordinates (while keeping the coordinates of the valid area always the same for easier "collision" detection). This will make the platforms look more natural and make the game graphics varying.

Totally agree with you! The platform shapes you just uploaded look splendid and gave me a helpful impression of how the pattern for creating new platform shapes could look like! I will gladly replace the rectangular platforms with some more interesting ones.  

Jun 20, 2018 16:39:19 GMT -5 hcmffm said:

Delay between jumps
Currently, when the player lands on a platform it takes a short while till he/she can do the next jump. This is a bit irritating.
Suggestion: Make landing and delay till player can do next jump a bit shorter.
EDIT: I just realized that you can keep button 4 pressed and one jump after another is performed. This makes the game comfortable and quick but much easier because you don't have to care for the exact timing of your button pressing (at least for the first 15 platforms).
Suggestion: Player jumps only when button state changes from "not pressed" to pressed.

Only execute jumping, when the button state changed, definitly makes sense. However, playing the game in the ParaJVE, I did not realize any delay between landing on a platform and jumping again. I will have a closer look on that after I fixed the button pressing thing.

Jun 20, 2018 16:39:19 GMT -5 hcmffm said:

Brightness for depth
Currently, all graphics seem to have the same brigthness.
Suggestion: Volcano in the background could be darker. Platforms in the background could be also darker.

Another great idea! This will be very helpful in terms of making the game more realistic and isometric.

Jun 20, 2018 16:39:19 GMT -5 hcmffm said:

Approaching the volcano
Currently, the large volcano in the background is visible from the very start.
At the start of the game the volcano might be small and at the very right. While playing, the volcano might get larger and larger and move from the very right towards the middle. This way the player gets the impression that he approaches the volcano and actually passes a distance.

Active volcano
Suggestion: Would be cool if the volcano would be every now and then active and fire-spitting like in the background of Stramash Zone.

Currently, the vulcano already scales for a small amount (so small that it's quite hard to see) after passing a platform. Here it might be reasonable to underline that more by increasing the scale factor.
As I mentioned before, the movement of the vulcano from outside into the centre has already been in the game ealier, but was rejected as it did not achieve the desired effect. Anyway, I am planning to try this again later.

Jun 20, 2018 16:39:19 GMT -5 hcmffm said:

Platforms graphic w/o bottom line
Currently, all platforms have a bottom line.
Suggestion: Platforms might look better without the bottom line. See grapic example below.
Notes:
- This would even save processor cycles which could be used for something else.
- This might not work out well because of the sinking platforms which appear later in the game.

This was part of the game as well, just before the alpha release. After adding the bottom line the game looked much more impressive for some reason, which is why I kept that style over the release.

Jun 20, 2018 16:39:19 GMT -5 hcmffm said:

Player's graphic
Currently, the player's graphic is quite simple.
Suggestion: It's quite difficult to create good vector graphics of humans with few lines only. A bit more complex but still simple graphic might work out quite well. Even a funny player graphic might be used. Player graphic below is one polyline with 11 coordinates.

I thought about changing the simple player graphic to a more complex one, but due to my lack of creativity, I just kept it simple for now. Since you offered me a lot of cool drafts, I will definitly change that in the future, eventually strongly inspired by one of your graphics. The complexity of the players shape will depend mostly on the machine cycles I have left, preventing the game from falling below 50 Hz.

Again, thank you for suggesting a lot of great ideas - I enjoyed all of them!
Unfortunately, I have some exams to do for now, which is why I can't continue developing until July.

- Volcanus -