I don't know about the scrolling..... Doesn't it distract from the real gameplay? Do you know any games that use this technique? I thought the C64 version of Ghoust n Goublins use this tech. But I was wrong....It didn't.

My aim for the game was a Goonies kinda game with a Usas/KingsvalleyII/Maze of Galious theme. In short a platformer (collecting x items to open next stage, while dealing with some enymies and minor puzzle ellements).

I don't want to make it too special. The reason all other efforts I/we made in the past ended up in nothing. I've been working on quite a few games which never made to a final. Shooters/Racing/RPG/Puzzle/Beat 'm Up. I tried it all. But it was all to ambitious.
Thats the reason konami did make great games. Make then 'simple' but addictive.

Another obstacle is my work/private live. I don't have to much time to spend on developing a game.

Quote:

I don't know about the scrolling..... Doesn't it distract from the real gameplay? Do you know any games that use this technique? I thought the C64 version of Ghoust n Goublins use this tech. But I was wrong....It didn't.

Do you mean my proposal to scroll half page at time?
No, but IMHO it can work very well if you choose the
parameters and the boundaries correctly.

Quote:

My aim for the game was a Goonies kinda game with a Usas/KingsvalleyII/Maze of Galious theme. In short a platformer (collecting x items to open next stage, while dealing with some enymies and minor puzzle ellements). I don't want to make it too special. The reason all other efforts I/we made in the past ended up in nothing. I've been working on quite a few games which never made to a final. Shooters/Racing/RPG/Puzzle/Beat 'm Up. I tried it all. But it was all to ambitious. Thats the reason konami did make great games. Make then 'simple' but addictive.

It is just matter of thinking a larger room and a larger puzzle.
Maze of Galious whould be perfect for having larger rooms with scrolling.

In any cases you could also do a fake scrolling. I mean that the game is still divided
in rooms 32x24 but passing from two adjacent rooms happens with a scroll of a full
page (not half a page this time). This is only a visual effect and does not imply
any special development skill.

Quote:

Another obstacle is my work/private live. I don't have to much time to spend on developing a game.

I cannot develope a game for the same reasons, this is why I was counting on you

Well, I think its a good idea to try the scrolling you proposed. I never saw it on MSX it might work very well.

Quote:

I cannot develope a game for the same reasons, this is why I was counting on you

With help from you this effort could succeed.

First now would be to make simple map editor. Any ideas?

Before the map editor, few questions about the map itself:

How do you mean to code and store the map in ROM? character by character or block by block?
You could store the level maps as blocks and expand them in characters in RAM.

This allows you to interact with the map, having e.g. breakable walls, or collectable items, stored as characters in RAM.

Each time you leave the level the map info are lost and the new level is expanded in RAM.

If you build the map as blocks the editor could deal with blocks.
How large do you want to do the levels?
Do you think to special items with which you can interact. Do you want to store the “interactive info” in the block code or in some special attributes of the area of the map ?

I mean, you have the options

a) the explosion happens if the sprite goes in position (111,56)
b) the explosion happens if the sprite overlaps character n. 125

About ready to go tool I can suggest Magoo's work at http://vscreen.hypercu.be/vscreen-editor.htm

Well, I had the following idea.

- Store the levels in blocks of 16x12 (or 16x16 blocks) thus a 1/4 of screen in ROM. Making it easier for the scrolling i think. Perhaps using the bitbuster EX would be a good idea. This way you'll need 12 blocks in RAM (about 3KB) to scroll any direction anytime. But if we can code to make it realy fast perhaps only 6 blocks (4 visible + 2 which scroll in) using 1,5 Kb.

- Store all interactive info of each block of a level in RAM so that will be remembered each time you enter a screen (but not after a level change).(location/status of enemies (sprite and non sprite) and items/objects).

- Store the map (connecting the level blocks) in another section (possibly in ROM?)

Pro's
- Using the packing makes it possible to store more levels.
- It's possible to make enemies/objects to respawn or not after finishing them off.

Con's
- The scrolling uses more RAM when not scrolling (3KB vs 768 bytes)
- Enemies freely wandering around the level is impossible. (But they can follow you from block to block as long as they are in the 'visible' area.

How big I want the levels to be? I don't know. I think I want to use a max of 6 KB of level data (active screen + level info(enemies, objects)).

Very nice! Looking to your graphic I could say that you could
design and store in ROM the game as 16x16 pixel blocks (4 char's),
to be mapped in char's in RAM each time you expand the level.
Naturally I mean that we should use bitbuster EX to encode the map data in ROM.

When I said "expand the level" I was meaning to expand the whole level,
not only te current room and half a page of the adjacent rooms...

Nevertheless, for horizontal scroll, I think that your idea of expanding the level
in RAM as macro-areas of half a page could be feasible while scrolling and save ram.

All we need is the RAM for of two rooms i.e. 768*2 bytes 11=1.5Kbyte.
Actually, we could restrict the requirements having only 768+768/2 = 1,125Kbyte.

I am not sure about the feasibitity of this idea for vertical scrolls (I am thinking to
the data arrangemet in RAM) and of the possible slowdown due to the extra CPU
time that whoul be required to expand the level while scrolling...

The main point I see in expanding the level "live" (i.e. while scrolling)
is that we need to store somehow infos about the objects that have changed,
like collected items, open/closed doors, fallen walls, disarmed traps ecc.

This info cannot be saved in the map itself (at it is always in ROM) and should to be
stored elsewhere.

About the sprite managment, they cannot interact with the map when they are
outside the visible screen, as the map outside the visible screen is only in ROM
and in compressed form.

In this case you could have a minimap where each solid 16x16 block is mapped
in a single bit, so the whole leve is compressed 8 times, and the enimies have infos
like "walk" "don't walk" here for moving in the whole level.

I get the feeling its getting a bit more complicated then I intended. But let's do the following:

- Only horizontal scrolling. up and down doesn't scroll but swaps to the next screen.
- Level is horizontaly split up into blocks of 16 columns.
- For every level there is a chain of enemies(sprites), objects, and animated enemies(patterns).
- For scrolling 2 fullscreens are stored in RAM (for better enemy ai. This way they can wander over 2 screens).
- For every level there is a block chain that connects all levels parts.

Future additions to add when the above is working:
- Enemies wander around freely.
- The levels build up out of 16x16 blocks (4 pattern chars)

Ok?

--------            -------------
|room A|    <->     |   room B  |           -------------------------
--------            |           |   <->     |           room C      |
                    -------------           -------------------------

My proposal:

Any room can have any MxN size, but a max size of 3-4Kbyte in RAM.
Any room is fully in RAM while the main char is in it and compressed in ROM while the main char is outside.
While exploring an active room you have a horizontal/vertical scroll (half page at time, easy to do, as all
the room is in RAM as characters).

When passing to a new room you expand the data of the new room in RAM (and overwrite the previous room).
You can pass between two room with a fake scrolling effect (easy to do as if we freeze/disable any sprite
while scrolling).

This imply that enemies are local to the rooms, (unless we want some enemies pass between adjacent rooms),
and that data about objects and walls have to be stored apart form the map or will be lost when passing among
two rooms.

This proposal seems very close to your original idea, with the difference that the rooms now have variable size.

Deal,

Now for the editor. Any good ideas for a fast solution?

have you already seen this http://vscreen.hypercu.be/vscreen-editor.htm ?
The files we need are the files ".STG"
Look at them, they are good as they are bulk raw byte data, as the exta infos
(that we do not care) are in the file ".LEV"

The main limit is that in this editor, the rooms have size multiple of one page
I.e. you can have a room of 32x24 or of 64x24 or of 32x48 or of 64x48, but
not a room of 48x12 for example.

Never the less it seems a good starting point.

OK, I'll try to convert the polka gfx to .sc4 for vscreen.......

polka -> vscreen = not working I'm gonna give up for now

Polka has its own format, the idea was to keep all polka thingies inside polka and only use export formats, for the moment you could try to export to asm or raw files, if you have the raw files it's piece o' cake for any programmer to make a small converter.

One of these days I'll do a new Polka btw.. (*with* proper importers/exporters )

Where can I find the format (.sc4) specs. Is thought I could just paste a 24byte header (16x 3 x4 bits for rgb colors) + raw output. Don't know how i came to that idea (must have been some old 'faulty' knowlegde)