"Metroid"

[Zamuel_a]

I have been developing a game for a few years now (have written alittle about it in the coding forum). It's just a fun project that I have been working on then I haven't had much else to do:) I have always liked the Metroid games and since it's hard to make a good conversion I wanted to make my own "Metroid" game. It's a platform action game with the same adventure style as in Metroid and with many similaritys (morph ball mode for example).
I have made a playable demo version now so I thought I could upload it . It's just a very simple world with some of the tile graphics ripped from Super Metroid. The sprites are made by me and the mainsprite takes over 400k with all animations so it will be a big game!
It is a STE only and uses the hardware scroller and the blitter. I change 8 colors in the palette for every 16 line (every tile line) so there can be 104 colors on screen at once (it won't show in the demo version). The remaining 8 colors in the palette are static for the entire display and has to be used for all sprites, since they can't have there colors changing if they move around:)
It needs 4Mb (which shouldn't be a problem today) and you NEED a 2 button joystick since I couldn't solve the problem with jumping/point gun up/shooting with just one button. I have testat a SEGA mastersystem pad and genesis(megadrive) pad and they work. It has to be connected to the mouse port.
I STEEM I mapped the arrow keys for joy port 0 (mouse) and then L-shift for port 0 fire button (shoot in the game) and L-CTRL for port 1 fire button (jump in the game)
Just unzip the GAME map to the harddrive and run GAME.PRG and it should work.
I have tested it on both STEEM and a real machine and it works fine.
There are some bugs and this is just an early demo version.
You can switch weapon with the NUM PAD but it's only number 1,2 and 6 that I'm pleased with, the others will probibly change or get removed.

[thothy]

Cool, looks very promising! I think this could become a really, really great game!
But I think you should solve the two-firebutton problem somehow, I don't think that there are a lot of people out there with such a joystick.

[Zamuel_a]

I can't see how to solve the fire button problem without loosing much of the gameplay (no fire up). I plan to add support for a Jaguar game pad so that will help alittle. But it's very easy to make an adapter for a simple PC gamepad (not USB).
I have always prefered to use a gamepad instead of a joystick.
I might add keyboard support to, but it's not on the higher priorities at the moment:P

[Xerus]

As Thothy, looks very promising !
Super Metroid is a great game, a clone could be awesome for STE.
After played at your demo (i found a secret passage eh eh!) your engine seems almost complete, it lacks only the slopes (not indispensable) and sounds
The playability is excellent with my Saturn pad so... nice going
A question, what is your limit for the number of sprites by VBL ?

[Zamuel_a]

I can explain alittle about the technical part of the game engine.

At first I planned to do a 8 way scroller with the technic discussed in this topic:
http://www.atari-forum.com/viewtopic.php?f=16&t=12961

I got it almost finished (had a few glitches here and there) and it didn't take to much processor power (around 10-15 % if I remember), but since I scrolled with one pixel/vbi it was abit slow. I wanted atleast 2 pixels / vbi (which is what I have in the game today) and maybe I wanted to add the ability to make the player run. 2 pixels / vbi would mean the scroll routine will be slower and maybe take up to 30 or more % of the processor power. That might had been ok, but I decided to change the scroller to a much simpler/faster one.
Since a Metroid game doesn't have a big singel area (like in Turrican) but instead smaller rooms I thought it would be easier to reserve memory for the entire room (one big screen) and then draw the room then it's loaded and then scroll around with the STE hardware registers and don't do anything else. That will take almost no processor power but will take some memory, but I don't memory is such a problem anymore. I can atleast expect anyone with an STE to have 4Mb today.
One problem I noticed then I started with this technic was that the LINEWID register is just 8 bits so the maximum horizontal screen that can be scrolled is 4*320 * Y pixels big, so one room could be just 4 screens wide. It might had been ok, but I wanted to be able to have bigger rooms so then I load a room that is bigger than 4*320 I reserve two memory areas and then I change the screen address between them dependin on were in the room I am. To make this work I need to draw last screen of the first buffer to the first screen in the second buffer so I can have a seamless transition between the areas. The two memory areas must be of the same size (I could then ignore stuff like differen screen widths depending on there I am and so on), so now a room can be 1,2,3,4,5 or 7 screens wide, which is ok for one room. The vertical resolution can be anything ofcourse.

I don't use a double buffer so everything has to be drawn in sync with the electron beam. All sprites are drawn with the blitter in the border area except the main sprite that is drawn with a software routine and that starts to draw at the begining of a new screen. I had to draw the main sprite in software since it's more interrupt friendly and I needs that since I change half the palette every 16 line.

Since I only have the border area to draw sprites in I can't have to many on screen at once. For every sprite I need to restore the old background, save the new and then draw the sprite so there are alot of work, but I created a multiplex system so if there are to many sprites at once it will multiplex so they atleast get's draw. This causes flicker ofcourse (like a NES game) but I plan to design the game so that it normally shouldn't multiplex but if there are at some point to many sprites at screen (like heavy weapn fire for a few seconds and many enemies) it can handle it. if the sprite drawing takes to much time and goes into the visible part of the screen it CRASH. I couldn't figure out a good way to calculate the time the sprites take, atleast not so that the Atari can tell me that BEFORE it crash, so I made a table there I calculated the sprite time based on statistics. I saw how many sprites of a different size I could have on the screen and then got the average value from that. Since the speed difference is rather big between one or two sprites (16x16 big) it seems to work even if the calculated time isn't so precise.

I use the blitter to change the palette to. I wanted to be able to change 8 colors and with software I could only change 4 or 5 since I had to load registers with color data at the beginning of every 16 line, OR I had to do it in the line before and then just WAIT for that line to end and the next to start, which I didn't like.
With the blitter I load the blitter registers with color data and then it's time to change palette I do the blit at the beginning of the line and then after that I reload the blitter registers with data for next palette change. Since I don't use the blitter in the visible part of the screen the blitter registers will not change so then it's time for the next palette change the registers are ready and I just do the blit.

[Heavy Stylus]

I can't see how to solve the fire button problem without loosing much of the gameplay (no fire up).

Although I haven't loaded this up yet, I completely understand your dilemma; the (secret) game project that I'm working on requires 3 fire buttons! We thought about many ways of getting it to work via single button joystick, but there was no way we could make it as playable/fair as when played via either keys or JagPad.

I personally hate action/arcade style games that require keys and joystick, and even worse are games that use weird combo moves on a single button joystick... Xenon is a real bastard, with the tank/plane transformation ocurring when you wiggle the joystick (often inadvertently whilst avoiding enemy shots).

Also, remember that a lot of people will probably play this via emulation anyway, and out of those I would imagine most will use their PC keyboard (and Steem supports JagPad emulation btw). If the options are jag pad, keys or genesis/megadrive/saturn pad, then I think you'll have most people happy. After all, those genesis pad clones sell on ebay for less than a £5.

[Zamuel_a]

I prefer a gamepad anyway so I use a SEGA pad even if I play games there I don't need the 2 buttons. I was just to nintendo then I got my Atari so then I was around 12-13 I modified a NES pad to work on the Atari. Just cut the cable of a joystick and solder it inside the NES pad, but then I connected it so A button was the same as UP, since most games used UP for jumping I could now play it as most NES games (A = jump)
I really wanted to be able to shoot in all directions since it's so much better than just be able to shoot straing ahead, so it will be a must to have 2 button joysticks:)

right now the game takes alot of memory. The demo takes more than fits on a 720 disk so I plan to compress the data in the future, but I think it will need a HD to be fun to play.

I noticed something I hadn't thought about before then I tested the game on my real Atari. It seems that TOS cache files that are loaded. I just keep ONE room in memory at a time and then you walk to the next room it clears the memory and loads the new one, so I tested to disconnect the HD from the Atari to see what would happen. I thought it would crasch since I don't have any error handling yet for missing files, but it worked! I could load all the rooms I had been visiting previous even with the HD disconnected! So TOS must cache it somehow.

[BoNuS]

Is it Falcon compatible / Hatari with Falcon TOS 4.04 ?
Would like to test it but I got a black flikkering screen.

[Zamuel_a]

I plan to make it Falcon compatible but I haven't tested it on any so I don't know if it works or not. I have to test it someday to see. I have never done any programming on the Falcon, but do you need to do anything then you run a regular STE game? I'm using standard TOS functions for disc handling and all that stuff.

[BoNuS]

I plan to make it Falcon compatible but I haven't tested it on any so I don't know if it works or not. I have to test it someday to see. I have never done any programming on the Falcon, but do you need to do anything then you run a regular STE game? I'm using standard TOS functions for disc handling and all that stuff.

I will test it on a real Falcon On the Hatari with TOS 4.04 it didn't seem to work, but that could also be settings
If you have very tight timing then ther e could be an issue, but we will see..

[Zamuel_a]

Everything is timed with Timer B and VBI interrupt so processor speed shouldn't matter, BUT you need to be in 50Hz

[Zorro 2]

Very interesting game.

Hope that it will come out soon

Devpack expert ?

[simonsunnyboy]

Technically great and I hope we will see more in the near future.

On the control method, well i personally don't like the console style multi button controls as I grew up with the Atari joystick (which never made problems for me).

However as you seem to insist on this, I'd say Jagpad support is a must for STE here

[Zamuel_a]

Is it Falcon compatible / Hatari with Falcon TOS 4.04 ?

I tested it on my Falcon and it didn't work. It didn't crash, but I just got some garbage on the screen. I tested on both VGA and TV but it didn't work. Have to look on that sometime in the future:)

[Heavy Stylus]

Technically this is really impressive. The controls should (imo) be mirrored to the ste enhanced joystick ports so people without a two-button stick can play via jag pad, and the player animation seems to be running two slow (about half speed), but that aside it is looking good.

Do you have a design set for this game, or are you just building it on the fly?

The difficult thing about a project this big is the level design and gameplay balancing - it may be worth getting together a team of other developers/designers to help you with the tedious level design/map building/tile gfx/testing parts so you can concentrate on the code. Speaking from experience, bringing in other people gives you a fresh persepctive on a game project, as after playing it yourself for so long throughout development it becomes very difficult to analyse whether or not the game is fun to play.

Anyway, thanks for sharing this - I really hope this project gets completed!

[Zamuel_a]

The controls should (imo) be mirrored to the ste enhanced joystick ports so people without a two-button stick can play via jag pad, and the player animation seems to be running two slow (about half speed), but that aside it is looking good.

I plan to have support for a jag pad and then I could map atleast two more buttons for weapon select and go to a map screen.
At first I scrolled 1 pixel/vbi with the first scroll technic, but now then I changed the way to scroll the world and got it to 2 pixels /vbi, the animation might be wrong. It's hard to "calibrate" it so the player walks the correct distance for one step he takes.
The game engine is rather complete now. Atleast so I can start with the level design. Enemies and sounds/music can be added later.
I don't know yet how I will do with music. I want to have both music and sound effect and since it's a STE game I don't want YM music. Maybe I will do the sound effects with the YM chip and the music digital.
I don't know yet if I will use MOD files or just play a pure sample. Depends alittle on the processor time I get left after everything is done.

I had to create a editor (on PC) since I didn't had any and at first I thought of doing a very simple one, but that has grown so it is a project of it's own. It's a 2 part editor. First you edit the world there you creates all the rooms and then you can go into each room and edit them separatley.
Since I can change the palette for every 16 line I had to create a smart system to handle the tiles, so I can now load in a "tile group" which has it's own palette and then for every 16 line (tile line) in the editr I can assign what group is active on that line.
Every tile has a 16 bit index number, there the first 12 bits are the tile number, so there can be 4096 tiles loaded in one map at once. The remaining 4 bits are tile properties. If it's a solid tile (you can walk on it), if it's a object, be able to blow it up with a bomb, shoot it and so on... So no tiles are defined as "background", "foreground" and so on, but instead everyone of them can be anything. The DOOR tiles are just normal tiles wich aren't solid (you can walk in them) and then they are defined as foreground so they lay ontop of the player.
I don't have to define how each room is connected to every other room. It's handled automatically then the player walks outside on room. It then tries to find the closest room to there we exited the previous map and then find the doorway in that room so the player enters the new room at the correct location.

[BoNuS]

Tried it on my Mega STE, works good Working with 2 joystick is not so good.

But animation is nice, good animated guy. Neat explosions and weapons fire.
Mapping indeed simple but it works smooth. A bit more "ambient" would be nice
instead of the loads of black But hey, its a pre-view...

Disk acces is okay, since its running from HD loading times are very short.
Keep it up, looks like we have a nice game coming in the future !!

[Zamuel_a]

The graphic is just a quick test I made (some are ripped from super metroid) just to get something going. Since my design can assign any tile to be background/foreground and so on, there can be alot of tiles at screen at once, so I don't want any solid black areas:)
The graphic I have made are the doors and objects and the sprites. The main sprite is made of two parts, upper and lower body, so I can combine them in many different ways. This saves alot of memory since the sprite then can take half the memory.
In metroid you always have to shoot the doors to get them open. I don't think I will have that in my game since it doesn't really adds anything to the game and there is a technical problem with it to (which can be solved, but I don't know if it's worth the trouble). Any foreground objects (like doors since they are drawn ontop of the player) are drawn in realtime after the main sprite is drawn, so the more foreground objects there are at screen at once, the more processor speed it takes. To make it as low as possible the foreground objects are now solid 16x16 blocks without any masking (takes half the time to draw then), but this mean that the tile has to fill the entire 16x16 block or else there will be a black part that covers the player. So if I add a door that can be shoot open (the blue cupols in metroid) they need to be 16 pixel thick, which would look abit to strange I think:)

[Heavy Stylus]

I never understood WHY you had to shoot doors to open them in metroid! That can't be a good design for interior doors

[Zamuel_a]

he he, no I don't know why they had that. Maybe it just looked "cooler" or something. I can understand the doors that you need the missiles for and I could add a feature like that rather easy to. Make the door "flash" or something until you hit it with the right weapon. It makes more sense to shoot the doors in the floor and ceiling in super metroid and I had alittle problem at first on how to handle that, but figured out that the best way would probibly be to go into the floor doors then you jump into it and be able to walk over them without falling down (you have to think 3 dimensional, the player is walking BEHIND the door, not over it ).

[StickHead]

Fantastic stuff, Zamuel! Another exciting project for the ST Very smooth, nice animation. Reminds me of the GBA Metroid Fusion, which is no bad thing. Will there be destructible blocks for the ball bomb? I seem to remember those being essential for exploration. It will be very interesting to see this develop.

I second a JagPad option, that would be nice. I have Sega pads in the loft too, so I will give those a try soon. I feel that a Metroid style game would be ruined by trying to map all the controls to one button.

Good work.

[Zamuel_a]

Will there be destructible blocks for the ball bomb?

Yes and if you walk as far to the right as you can from the starting point there are some dark blocks that you can destroy with the ball bomb. At the moment you can only destroy one block at a time, but I think I will change that in the future so it destroys the 4 surrounding blocks.

[swapd0]

It doesn't run in mac Hatari 1.3.1 with tos 1.2 neither tos 2.6

[Zamuel_a]

I couldn't get it to run on a real Falcon eather so that's something I have to look on in the future.

[EvilFranky]

Crashed for me in STEem with 2 bombs.

Tried TOS 1.62 and 1.04