Crimsonland...?

[magus57]

After playing Alien Breed IV, I remembered playing a game called Crimsonland, which is a very similar game. In Crimsonland, you are on a flat map, and all you have to do is kill enemies, and you don't even have to move. The differences between Crimsonland are that in Crimsonland, the only objective is to kill enemies (which can take many shots to be killed), the main character can do full 360-degree turn to shoot, and collects powerups/weapons/ammo by killing enemies, along with experience, which can be turned into new abilities/strengths.

My question is, is it possible for (even a primitive version) to be "ported" to the calculator? I'd like to know if the following would be possible:

-Enemies dissapear automatically after being killed instead of slowly fade away
-No terrain (just plain white screen, not even grayscale)
-All or most weapons/abilities/powerups/etc.
-6 types of enemies (small spiders, large spiders, small skeletons, large skeletons, small zombies, and large zombies), with 3 sub-types based on health as the game progresses in difficulty (with sligtly different sprites to know which is which)
-Character can move 360 degrees based on how long they hold the directional buttons (not just one-button turns), and enemies turn like the character
-Experience system with powerups

Obviously, this would take assembly, and maybe even a TI-89 instead of a TI-83/84 as I was thinking originally. So is this possible? Because the original game is really fun and it would be great to have on a calculator. However, I have about no knowledge about programming.

[Sage Orator]

There is absolutly no reason it would take assembly. Not having terrian is a huge advantage. Same with not having to move. Do enemies move though? It actually wouldn't be too difficult to make without terrain except for holding buttons down, but that could be simulated well enough. Just shooting, enemies, turning, and enemy location are the thinks to focus on. Assembly would just make things quicker, smoother, and better looking.

[Vinthian]

I think the only reason why people use asm is because it makes the game look better and run faster. If you have a solid gameplay, it'll be a good game. Fading effects and grayscale is eye candy, but it won't hurt if you didn't have some.

[magus57]

The enemies and the character both move, and the enemies respawn a certain number of times each level.

If you want more info on the game, just download the demo, because even the demo is fun to play.

And the reason I want it in asm is so that the character/enemy movement is smoother.

[skier]

Ive played cimsonland! Great game. No disrespect to sage orater, but i think this game would be much better off in assembly. Basic just wont be fast enough... i dont know about 89 basic though.


Its going to be a pretty tough game to make. It'll be hard to make the character spin 360 degrees, maybe just do 16 or 32 directional movement.


It would be really cool if it were ported to the calcs

[Sage Orator]

I've never played it so you guys have a better idea of it. It would be tougher if the character has to move. Go ahead and use assembly if you want to.

[DarkerLine]

The only problem in Basic would be if the screen had to scroll. This is nearly impossible in 83+/84+ Basic without libraries. (possible very slowly, or on the home screen, or when there are few objects on screen)

[Liazon]

wait, this isn't a pseudo fps where all you can do is spin around like a turret right?

we're talking 2D with some kind of turret in the center?

[magus57]

No, this game is a birds-eye third-person shooter. The character does move like a turret, but can also move in any direction (in order to evade enemies or get weapons for example).

As for the screen, I was thinking of making it 9x the size of the TI screen, making it a real-time scrolling map. When I say 9x, I mean a 3 screens side-by-side for length and width to makes the map, with the enemies respawning randomly at the edges for a set number of times.

I made some 8x8 sprites, and here is what they are:
Small spider 1
[attachment=997:attachment]
Small spider 2
[attachment=998:attachment]
Large spider 1
[attachment=999:attachment]
Large spider 2
[attachment=1000:attachment]
Small skeleton 1
[attachment=1001:attachment]
Small skeleton 2
[attachment=1002:attachment]
Large skeleton 1
[attachment=1003:attachment]
Large skeleton 2
[attachment=1004:attachment]
Small zombie 1
[attachment=1005:attachment]
Small zombie 2
[attachment=1006:attachment]
Large zombie 1
[attachment=1007:attachment]
Large zombie 2
[attachment=1008:attachment]
Main Character
[attachment=1009:attachment]

So is there anybody who would like to help in this? This game could technically be based off Alien Breed IV (or II), with the differences being in the weapons/upgrade/experience, the map, the movement, and the enemies.

[Weregoose]

I have a hunch that people will get lazier after the first download, so I converted
all of them to PNG and zoomed in 200% just to make sure that people will see it.

Small spider

Large spider

Small skeleton

Large skeleton

Small zombie

Large zombie

Main Character

[Sage Orator]

The small ones look wierd, what size are they?

[Fallen Ghost]

the small ones are like 1 pixel smaller than the big ones, so it isn't easy to see the difference fast like in an ASM game, but in Basic, we will have plenty of time to look at them.

[magus57]

Thanks for the help with the pics, I couldn't figure out how to do that picture thing. The only way in the real game to tell the difference between enemies (except for physical appearance) was color and size. Since I obviously can't add color, I had to use size (and some black-white differences) to create them. Even then, I can't make the size difference too small or else the small enemies won't be recognizeable.

Guessing that a 360-degree motion would be hard to do, is there any possibility of at least 8-position motion (for both the enemies and the character)? If it's in 4-position, then it'll pretty much be another Alien Breed game. And when I mean 8-position motion, I mean the four regular directions + diagonal directions (when two directions, such as up and left, are held together).

And one last question: is there any chance of being able to use a USB mouse? There's a driver for it, but I have no idea on how (or if) it could be implemented into a game. Then it would be easier to play.

[skier]

[threefingeredguy]

My basic snake game had 16 directions. It's pretty easy to do.

[Super Speler]

I beleive you would just use sin( and cos( for that many directions.

[kermmartian]

[magus57]

But what about the USB mouse idea? If you had the cable for it (like I do) along with a USB mouse?

[Fallen Ghost]

That could probably not be handled by a Basic Program, and even if so, it would just make the game very, way too much, slow.

[magus57]

What about assembly? Or flash?