Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: Zera on February 19, 2010, 07:56:40 pm
-
スペース・ファイター斬剣
(http://img14.imageshack.us/img14/7096/screen9p.png)
(for those curious, "Zanken" roughly translates to "cutting sword")
I had this random idea earlier for a top-down shoot-'em-up. I doubt I would ever have the coding abilities to pull it off, but I enjoy coming up with random ideas, no less. I have a folder full of projects and assets that never get developed. :P
The game centers around Zanken: An advanced military spacecraft tasked with navigating through hoardes of hostile invasion forces and ultimately destroying the central core of the enemy operation.
Each level consists of an area of space swarming with enemy formations. Zanken must defeat each formation in order to progress to the next level.
Zanken is equipped with a wide arsenal of weapons -- each useful in a variety of situations. By defeating enemies and collecting power-ups, Zanken may switch between the various options available.
Space Fighter Shield - Each shield upgrade (S) covers Zanken from a single hit. Zanken's shield will increase or decrease in size to indicate the shield's strength.
Power Cells - When a power cell (P) is collected, Zanken switches between the weapons in its arsenal:
L-0: Twin-Shot (default) - Fires two shots directly ahead. The weapon can be fired successively without much cool-down between shots.
L-1: Pulse Emitter - Fires a pulse laser straight ahead. The laser penetrates multiple enemies, but has a longer cool-down period.
L-2: Wave Beam - Fires a wave beam that covers a radius of three tiles, but has a slight cool-down period.
L-3: Diffusion Missile - Fires a missile with a destructive yield. The missile appears in front of Zanken and flickers for a brief moment before launching itself ahead. When the missile explodes, it damages all targets within surrounding tiles. Has the longest cool-down period.
(http://img526.imageshack.us/img526/8933/screen6k.png) (http://img718.imageshack.us/img718/723/screen5d.png)
(http://img28.imageshack.us/img28/9386/screen4g.png) (http://img294.imageshack.us/img294/4158/screen3g.png)
(http://img237.imageshack.us/img237/9831/screen2d.png) (http://img246.imageshack.us/img246/9599/screen1.png)
(http://img713.imageshack.us/img713/672/screen8kdk.png) (http://img148.imageshack.us/img148/8900/screen7.png)
To the bottom of the play area are Zanken's score, and the number of players (lives) available. By accumulating points, Zanken can earn additional players.
To the right is the display for the current level, and Zanken's shield (S) and weapon (P) power meters. Each meter indicates the current / max number of upgrades.
------------------------------
I was kind of curious how feasible such a project might be if written in BASIC. I can say a few things about it:
- There wouldn't be any masking, because it's strictly monochromatic; and each sprite generally covers the entire tile, anyway.
- I'm not sure if scrolling is feasible, but it's probably not necessary. One idea was that the graphics used in backgrounds could appear and disappear in patterns, giving the illusion of having a dynamic environment. (i.e., stars appearing and vanishing)
- I'm not sure how the sprite routine would work yet. I think maybe movement would occur 8 px at a time. (so a sprite would "jump" from tile to tile, as it would in one of those old Tiger Electronics LCD games)
- There aren't any graphics larger than 8x8 pixels. Bosses are sort of comprised of multiple, arranged tiles, but the actual target (such as the core, or a weapon) would only be 8x8 px.
-
mhmm very nice, I wonder if this would be feasible in future versions of Axe Parser? You would get even more speed than BASIC ^^
-
Ooooh that looks great, and a good idea too. I think this might be very possible in Axe, I'm thinking Basic might be too slow :( But I'm not sure, it could be done. Looks nice either way :)
-
Cool! I think this could be done in Basic+xLib. How many sprites would there be on the screen at one time (min and max)?
-
Cool! I think this could be done in Basic+xLib. How many sprites would there be on the screen at one time (min and max)?
Probably as many as 16-20 at a time? (rough approximation) I have to account for bullets, as well. The largest enemy formations might be eight or so, but I can't say how many bullets would be on the screen simultaneously.
-
Ouch, above 5 sprites at a time, it can be hard to keep a good fps in BASIC' but again, I managed to have 3 fps on a SE with 12 at once and that was in 2002 on homescreen, which is slower than using ASM libs
-
Hmmm I just did some quick tests and it seems xLibs sprite display function is more than twice as slow than output() O.o And that is without buffer update X.x
-
Let's assume it were a fixed shooter. (the player ship is restricted to a single line, and may only move left and right) There's no scrolling background, and the objective is to clear formations of enemy. (a la Galaga / Galaxian) Rather than a complex sprite routine that's going to move everything pixel-by-pixel and has to keep up with complicated colision detection, let's say everything is moved 8 full pixels at a time. (so everything "jumps" from tile to tile) If a bullet or enemy is occupying the same tile as the player ship, the player ship is damaged; and vice-versa.
That should make the whole routine less complicated. Frame-rate might not take too much of a blow when sprites are moving in such large gaps, rather than pixel-by-pixel movement. Of course, it would look like a handheld LCD game. :P
-
strange, I sweared Real(1 was faster than output(, especially that I did grayscale using sprite commands (and had stuff moving around while grayscale was running x.x)
-
If it were to be done in BASIC it'd probably be restricted to the 15MHZ calcs. If you have it restricted to a manner described two posts up, I think it'd be doable but I'm not sure how good it would look moving 8 pixels at a time as opposed to moving smoothly.
-
I've updated the mock-ups. I revisioned some ideas in regards to how the gameplay and objective would work. Each level would be a series of enemy formations, ocassionally followed by a final objective before the player could proceed to the next level. This objective could be safely navigating through a mine-field, (several mines "falling" from the top of the screen) or safely escaping an enemy base. (a series of gun turrets)
Every weapon would be equal in strength, as it would only require a single shot to destroy an enemy target. Weapon upgrades would only affect the range and area-of-effect of weapons. (and cool-down period)
The ultimate objective of the game would be to clear 8 levels before the player is presented with the ending sequence. If all eight levels can be cleared without losing any players, then the player can face 6 bonus levels with a substantially higher difficulty. (levels A-F)
There would also be a short set of configuration options to define initial lives and difficulty. (which might affect how often enemies shoot missiles) Given there is so little text in the game, I could also provide a Japanese language option just for kicks. It might help simulate the whole classic console feel.
-
Here's how fast I could keep a Shoot-em-up in pure basic in 2002, attached to this post. Note that since it was 8 years ago, my coding skills has improved since then, but I think that might give an idea of all that's feasible in BASIC.
-
Here's how fast I could keep a Shoot-em-up in pure basic in 2002, attached to this post. Note that since it was 8 years ago, my coding skills has improved since then, but I think that might give an idea of what's feasible in BASIC.
Hey not bad at all. With optimization, some more bullets, enemies and items are possible.
-
Note: that's SE speed
-
Here's how fast I could keep a Shoot-em-up in pure basic in 2002, attached to this post. Note that since it was 8 years ago, my coding skills has improved since then, but I think that might give an idea of all that's feasible in BASIC.
That's pretty cool. I figured the movement would be similar in Zanken. Not sure about the speed, though. There are so many graphical assets -- including a custom font.
-
Pardon the double-post...
What would be a good set of controls? There would only be two buttons: Fire / Confirm and Pause / Start. (of course, the D-pad would control movement) I'm debating on which keys should be assigned to these functions.
I also added an enemy rank indicator. (to indicate which enemy formation you're currently on) Also... Japanese. :P
(http://img26.imageshack.us/img26/7527/screen5hr.png)
-
The major issue that migth arise is AI: if the game requires any form of AI, it will slow down a lot. It will slow down even more with randomized enemy movement, due to the extreme slowness of Rand functions (so slow that they're used as delays (instead of doing like "For(Z,0,25:End", ppl will just do "rand" and save 8 bytes of memory) when optimizing BASIC code for size). If enemies have pre-defined movement/shooting patterns, these needs to be stored when a stage/level/world is loaded, then a variable set to 0, counting by 1 every loop, scanning through the pattern data. This can prove to be considerably faster than AI/randomizing. The only thing that might slow things down, then, is the displaying of enemies. Even in assembly you'll get slow downs when many bullets shows on screen. Iambian's game CaDan demonstrates it. It even happens in NES and SNES games.
Keep in mind that pre-defined patterns can be extremly large in memory, though, if they're long. If they're just for example enemies moving in circles, I bet these could be like 8 or 10 elements large and the counter would loop through them until all enemies are defeated.
-
There wouldn't really be any A.I. Enemy patterns would be pre-defined. I think the patterns would be relatively simple; such as the enemy group moving left to right, gradually descending toward the player, and then back up. It wouldn't be as complex as, say, Galaga, because enemies wouldn't have those convoluted appearance patterns where they fly in from every corner of the screen and twirl around. Enemy movements would probably be directly tied to the enemies themselves, or types of formations that are registered in the system. i.e., a level's data would just consist of a few pointers to call up each formation pattern that is already registered, and can be called in any level.
Now that I think about it, it could be possible to impose some kind of sprite limit that will prevent the execution of enemy missiles if the sprite boundary is already reached. If there's a clear idea of how many sprites can simultaneously be on the screen without slow-down, that could be used as a rough approximation of the sprite limit that would be imposed.
-
one key to have a decent speed in a game with multiple sprites in BASIC + libs or even with ASCII chars in pure BASIC: never use For( loops to render sprites, unless collision detection is done enemy by enemy (if the ship can touch them all the time), then it may be better. I am saying this because For( loops are much slower than just writing the code for each enemy slots. For example:
For(Z,1,8
Output(Z,1,"LOL
End
Is much slower than
Output(1,1,"LOL
Output(2,1,"LOL
Output(3,1,"LOL
Output(4,1,"LOL
Output(5,1,"LOL
Output(6,1,"LOL
Output(7,1,"LOL
Output(8,1,"LOL
Sadly, in BASIC, we have to optimize for speed instead of size in such scenarios. A prime example of this is this program by Netham45:
http://www.ticalc.org/archives/files/fileinfo/352/35264.html
It may be 1500 bytes large, but sadly, it gets the job done faster than using an additional For( loop
-
What would be a good set of controls? There would only be two buttons: Fire / Confirm and Pause / Start. (of course, the D-pad would control movement) I'm debating on which keys should be assigned to these functions.
In my opinion, I'd like 2nd=Fire and Start, Mode or Alpha=Confirm and Pause.
DJ, I like that shooter. Is it in the Download section?
This is sure a neat concept! Great job Zera!
-
(Ztrumpet: yeah, check for the game called Omnimaga Pack 25 Games In 1)
-
I just realised this topic was posted in the wrong board section. I moved it to calc-related projects and ideas instead of non-calc projects and ideas.
-
I just realised this topic was posted in the wrong board section. I moved it to calc-related projects and ideas instead of non-calc projects and ideas.
Thanks. I was going to edit a comment about that into the original post.
There are so many boards that it's easy to get them mixed-up now. :o
-
Well, the major issue is that the board was named Computer projects and ideas. By starting with Computers, it means it starts with the same letter as the word "Calculator". Since the board had similar title, it became easy to confuse both, especially considering they all moved around since last year and some of us were part of the old board, from which we took the board layout, that we stuck with for 3 years x.x
Now they're more squished, though, into subforums ^^. As admin, it sucks, now, though, because we see the big "Members-Only" notice guests sees instead of the members-only sections I added. Basically, I see both because on SMF and phpBB it's impossible to hide subforums from admins :P. Good thing we still don't have that anti spam we used near the end of the old board...
-
I've been working on some ideas for a possible sequel, using a side-scrolling style. (similar to Gradius) Unfortunately, I'm a bit insomniac at the moment. Can't focus on the details.
(http://img8.imageshack.us/img8/8814/mockupp.png)
-
Mhmm, seeing the lack of grayscale in this screenshot, it looks like it could be easier to make without programming ASM
-
@Zera, yep I instantly thought about Gradius when I saw the mockup. Looks really nice! I'd love to see this idea developed further.
-
Now that Axe allows more freedom, I am curious if such project could be finally possible with Axe? It seems like it would run pretty fast at least
-
I would love to try this project (maybe the side scrolling one better) Looks like a really awesome idea :)
-
I haven't really conceived many ideas for the side-scrolling one. All the assets and documentation are there for the fixed shooter, though.
-
This looks nice. Nice work Zera :)