Great start!
Like you said...
Myndale wrote:Personally I like the design philosophy that Yoda Zang seems to stick to of making his games as close to the original as possible but within the confines of the device. This title is a bit tricky though because there are so many "originals" to choose from and the game really does need display resolution that the Gamebuino simply doesn't have.
Agreed, but I still prefer to borrow some game mechanics from the many sources and possibly come up with an original Gamebuino title.
The resolution display is a challenge to fit gameplay but at least it is a fixed resolution.
While I prefer original work, I´m fine with making a close port too, my guess is that it really depends on what you want to push/experiment through this development.
Also, I have no idea of what is actually possible or too much for a gamebuino to handle, so here I will be shooting for no boundaries just like if everything is possible so then we can pick what works and fits and whatnot for the final game.
Myndale wrote:...
Areas that I think need to be addressed first include:
1 Do we keep the ship aligned upright or does it rotate?
2 Do we only do landings? Or does the ship take off and fly over to different screens?
3 Do different pads affect the fuel budget? Or is the goal just to get the highest score with fixed fuel for every landing?
4 Do we have a height-field like the Atari version or more complex geometry like the TRS-80 version?
5 Black & white, gray-scale or both? (My vote is an option, but I'm not doing the art).
6 Fixed landscapes? Or procedurally generated?
First, as a concern to the screen size, we have an issue about ship´s size against scenery and ship´s movement.
A.The smaller the ship, the more scenery we can pack on screen but less precise will be the ship´s fine tuning notion of movement.
B.The bigger the ship, less scenery we get but a better notion of fine movement.
Both ways are fine with me as we can bend the gameplay and enrich the choice we take.
Also, I could work a hud to depict velocity vectors for the fine tuning moments.
For the sake of creating a layout, I came up with 2 example sketches depicting the A and B cases, but of course we could also work in between.
The smaller ship size for a game like this would be a single pixel, so set A has a 3x3 sprite depicting the ship where the collision point against walls could be its inner single white central pixel. Set B has a bigger scenery and an 8x8 ship´s sprite, I believe a bigger ship then this would render the scenery curves too unimportant, so I set this as the biggest size.
1-Could be either or both, I´m more found of the upright version but here I believe we could create an original way of controlling the ship.
This issue may also concerns how we play the game control wise. Here an idea:
In set A, the ship is able to rotate into 2 extra positions sideways, a 22.5 and 45 degree angles, where its main thrust could push the ship diagonally too. You can still use the smaller weaker left/right thrusts that acts based on the point of ship rotation.
This would be for the "maneuvering mode", where you can toggle on/off by pressing a button
The other mode would be the "landing mode", here the ship automatically aligns upright and deploy its landing gears. On this mode, only the smaller weaker left/right/down thrusts are available, it is for fine tuning the landing procedure. I´ve got some ideas about this control scheme I could describe if you think this path is a good idea.
2-Could be both too, I personally prefer the taking off as it brings an exploration element to the game and strives away a bit from the simulation of landing only. If we consider set A, we could have a single screen/scrolling game, set B may require scroll only screens.
3-Both score and fuel are fine, I thought maybe we could also add more to this, I will describe this later.
4-I´m more for complex geometry, but we could have both.
5-B/W or grey or both, I´m fine with all, it depends here on what you may want to push visually on this game.
Most of the time, the grey version is easily convertible to a B/W design.
I recall you were looking into the visual libraries of gamebuino so maybe there is something specific you would like to try?
6- Again, I´m fine with both, but I have an idea about it too together with issue 3.
---
Ok, let´s look at set A from the point of view of a full game (again, excuse my daydreamings
).
A mission based landing/taking off, a bit open ended, game. It could read the mission from SDcard and later we could work on an app to create the missions. Here I could also help code a version for windows/mac/linux/android/etc.
The mission would comprise a set of 9 connected screens with tile based scenery, similar to the racing game Rodot did.
There would be a first and last pad to land to end the mission but some of the inbetween pads may give you alternate routes or ask you to go land on a specific place for a reason. The pads here would be able to give you, other then score (more like an achieving gauge 0-100%), different set of fuels, open new paths and probably some sort of power ups.
Since the ship is small, we could also add some environment challenges like falling meteors, bubbling lava, etc.
Another thing to think about would be if it is possible to have a destructable map, but I didn´t think much about this yet.
Let´s look at set B, while pretty similar to what I said already, here we could work a ´field of view/light/shadows' with dither, so the game would be more about exploring the unknown with care other then the action based idea of before.
We could also have a parallax scroll for background scenery too, but I´m unsure this would be too much.
Anyways, these are just some crazy sketch ideas to boot so we can shape a final idea layout based in accordance to what we can achieve.
- landing.png (6.85 KiB) Viewed 11079 times
