Colossal Cave Adventure diary

+DZ-Jay · February 7, 2012

Another useful note: The CTRL_CHECKKEY decoder only triggers events on "key-down." That is, when keys, buttons or the disc are pressed; not when they are released.

Again, this was all based on the code I made for Christmas Carol and the requirements were simpler. I should generalize it better.

Eventually I'll update it to do both "key-down" and "key-up" events.

-dZ.

vprette · February 7, 2012

it works!

a restart of the pc has helped...

So I handle now the controller keys :-)

I need to add a new state now! this gonna be fun.

when in the (LEVEL, Init, cNormal)

I call the first procedure that is the INTRO

during INTRO, that stand for 3 seconds, I NOT want any key to do actions, to I cannot proceed to SET_GAME_STATE(LEVEL, Play, cNormal)

but I need to proceed to some SET_GAME_STATE(INTRO, Wait, cNormal) where I redefine the state like

; ------------------------------------------

; STATE: Intro

; ------------------------------------------

; State: Controller: Dispatch:

; -------------------- ----------- -----------

@@__intro: DECLE ST_INTRO_WAIT, CTRL_NONE, NO_DISP

DECLE @@__dead, CTRL_NONE, NO_DISP

at the end of the INTRO procedure I set SET_GAME_STATE(LEVEL, Play, cNormal) again... I hope this work

To clarify: as you see in the actual rom: during the 3 seconds on teh INTRO message "welcome stranger.." the game accept keypad inputs... I want to avoid this.

col.zip

Edited February 7, 2012 by vprette

+DZ-Jay · February 7, 2012

To clarify: as you see in the actual rom: during the 3 seconds on teh INTRO message "welcome stranger.." the game accept keypad inputs... I want to avoid this.

Wait, I don't understand. Are you saying that you want to delay for three seconds without accepting input? All you need to do is to switch to state "Level-Wait" prior to setting calling STARTTASK with the 3 second delay trigger. In the routine that is called when the timer is up, you switch the state back to "Level-Play" to continue normally.

This is why all levels contain a "Wait" sub-state, so that you can have delays and other transitions that do minimal background stuff and ignore input if you want to.

In Christmas Carol, I have two wait sub-states, "WaitKey" and "Wait". I use "Wait" for delays that must not accept input (like during the "Get Ready!" sequence); I use "WaitKey" for delays that may accept any key (like during the introduction sequence animation, so that the user can skip it).

If your remember the dispatch table, the "Level-Wait" entry has no input decoder and just calls the "Wait Engine".

So, you can do something like this:

       ; Whenever you want the delay...

       SET_GAME_STATE(LEVEL, Wait, cNormal)
       ; ...
       STARTTASK
       DECLE Task.Delay
       DECLE MY_CONTINUE
       DECLE (60 * 3 * 2) - 1
       DECLE 0

And in the continue routine:



MY_CONTINUE  PROC
       BEGIN

       ; Delay is up! continue as normal
       SET_GAME_STATE(LEVEL, Play, cNormal)

       RETURN
       ENDP

Does this make sense?

-dZ.

Edited February 7, 2012 by DZ-Jay

+DZ-Jay · February 7, 2012

You don't have to create a state for the intro unless you have considerable logic for that state that should be treated separated from the "game/level" state.

If all you need is a short delay or a transition, then you can consider that delay or transition a sub-state of the "Level" state. However, it's up to you. P-Machinery will support any number of states.

-dZ.

vprette · February 7, 2012

To clarify: as you see in the actual rom: during the 3 seconds on teh INTRO message "welcome stranger.." the game accept keypad inputs... I want to avoid this.

Wait, I don't understand. Are you saying that you want to delay for three seconds without accepting input? All you need to do is to switch to state "Level-Wait" prior to setting calling STARTTASK with the 3 second delay trigger. In the routine that is called when the timer is up, you switch the state back to "Level-Play" to continue normally.

This is why all levels contain a "Wait" sub-state, so that you can have delays and other transitions that do minimal background stuff and ignore input if you want to.

In Christmas Carol, I have two wait sub-states, "WaitKey" and "Wait". I use "Wait" for delays that must not accept input (like during the "Get Ready!" sequence); I use "WaitKey" for delays that may accept any key (like during the introduction sequence animation, so that the user can skip it).

If your remember the dispatch table, the "Level-Wait" entry has no input decoder and just calls the "Wait Engine".

So, you can do something like this:
	; Whenever you want the delay...

	SET_GAME_STATE(LEVEL, Wait, cNormal)
	; ...
	STARTTASK
	DECLE Task.Delay
	DECLE MY_CONTINUE
	DECLE (60 * 3 * 2) - 1
	DECLE 0
And in the continue routine:
MY_CONTINUE  PROC
	BEGIN

	; Delay is up! continue as normal
	SET_GAME_STATE(LEVEL, Play, cNormal)

	RETURN
	ENDP
Does this make sense?

-dZ.

yes!

your MY_CONTINUE is my LEVEL_INTRO in this case

and the wait status is already available in LEVEL as you say... I was trying this, but I need some sleep

vprette · February 8, 2012

New update

"Wait" state works, but...

I still need a new sub-state!

I explain: from a user point of view I can be in 2 states:

- when intv expect my input (I handle this with "Play" sub-state)

- when intv show one of several text pages of a long description of 2-3 pages: in this case the ONLY input accepted is the disc pressure

to handle this I need a sub-state PAGE and I can still use the ST_LVL_PLAY procedure but using as controller the CTRL_GAMEPLAY that only accept disc input, right?

So I would change in "state.const"

; STATE: Level

DEFINE_ENUM(GST_LEVEL,

ADD_ENUM_ELEMENT(Init )

ADD_ENUM_ELEMENT(Wait )

ADD_ENUM_ELEMENT(Play )

ADD_ENUM_ELEMENT(Retry )

ADD_ENUM_ELEMENT(Death )

ADD_ENUM_ELEMENT(Done )

ADD_ENUM_ELEMENT(Page )

END_ENUM

and change in "st_dispatch.asm"

; ------------------------------------------

; STATE: Level

; ------------------------------------------

; State: Controller: Dispatch:

; -------------------- ----------- -----------

@@__level: DECLE ST_LVL_INIT, CTRL_NONE, NO_DISP

DECLE ST_WAIT_ENGINE, CTRL_NONE, NO_DISP

DECLE ST_LVL_PLAY, CTRL_CHECKKEY, MY_INPUT ;handle keeypad commands

DECLE ST_LVL_RETRY, CTRL_NONE, NO_DISP

DECLE ST_LVL_DEATH, CTRL_NONE, NO_DISP

DECLE ST_LVL_DONE, CTRL_NONE, NO_DISP

DECLE ST_LVL_PLAY, CTRL_GAMEPLAY, TEST_INPUT ;handle disc pressure only

DECLE @@__dead, CTRL_NONE, NO_DISP

??

Edited February 8, 2012 by vprette

+DZ-Jay · February 8, 2012

New update

"Wait" state works, but...

I still need a new sub-state!

I explain: from a user point of view I can be in 2 states:

- when intv expect my input (I handle this with "Play" sub-state)

- when intv show one of several text pages of a long description of 2-3 pages: in this case the ONLY input accepted is the disc pressure

to handle this I need a sub-state PAGE and I can still use the ST_LVL_PLAY procedure but using as controller the CTRL_GAMEPLAY that only accept disc input, right?

So I would change in "state.const"

; STATE: Level

DEFINE_ENUM(GST_LEVEL,

ADD_ENUM_ELEMENT(Init )

ADD_ENUM_ELEMENT(Wait )

ADD_ENUM_ELEMENT(Play )

ADD_ENUM_ELEMENT(Retry )

ADD_ENUM_ELEMENT(Death )

ADD_ENUM_ELEMENT(Done )

ADD_ENUM_ELEMENT(Page )

END_ENUM

and change in "st_dispatch.asm"

; ------------------------------------------

; STATE: Level

; ------------------------------------------

; State: Controller: Dispatch:

; -------------------- ----------- -----------

@@__level: DECLE ST_LVL_INIT, CTRL_NONE, NO_DISP

DECLE ST_WAIT_ENGINE, CTRL_NONE, NO_DISP

DECLE ST_LVL_PLAY, CTRL_CHECKKEY, MY_INPUT ;handle keeypad commands

DECLE ST_LVL_RETRY, CTRL_NONE, NO_DISP

DECLE ST_LVL_DEATH, CTRL_NONE, NO_DISP

DECLE ST_LVL_DONE, CTRL_NONE, NO_DISP

DECLE ST_LVL_PLAY, CTRL_GAMEPLAY, TEST_INPUT ;handle disc pressure only

DECLE @@__dead, CTRL_NONE, NO_DISP

??

You are right! That's exactly how P-Machinery should be used in such circumstances. Then you have your normal "Play" sub-state (which you can rename if you wish) where full input will be expected (eventually from the ECS keyboard, right?). Then you have a "Page" sub-state where only the disc is accepted so the user can read more than one page of text.

You can then use the "Wait" state for delays and transitions between these states.

Your assessment on the changes are correct. Although you can remove "Retry" and "Death" if you're not planning on using them. Just remember that the names defined in the "state.const" file are used for the SET_GAME_STATE macro and such, but that the actual sub-states are defined in the dispatch table in "st_dispatch.asm" file. Also that each sub-state defined in the table must correspond to a state handler routine.

They should respectively match in order, and there must be 8 records defined. Any unused sub-states must be mapped to the "@@__dead" state, which is ignored.

Those are the requirements for defining states in P-Machinery. It's that simple.

-dZ.

Edited February 8, 2012 by DZ-Jay

+DZ-Jay · February 8, 2012

As promised, Big Fonts! I also have numbers if you need them... Actually, I have a full "printable character" ASCII set, including lower-cased letters.

-dZ.

fonts.asm

vprette · February 8, 2012

New status (Blue is done, Green is faisable, Yellow is difficult. Red is very hard to code for me)

I totally discarded the graphic screens...

- TITLE SCREEN: ok (custom screen)

- INTRO: ok (welcome message)

- INIT: ok (integrate tracker and start demo music)

- FONT: ok (custom)

- CONTENTS: insert all levels message text descriptions 20%

- MUSIC: translate mod to decles of custom music "shadows"

- PLAY ENGINE1: implement PAGE state and transition from PAGE to PLAY by reconnaising disc pressure 5%

- PLAY ENGINE2: ok (inputs from keypad reconnaise 8 directions, "Clear" as music pause and disc touch)

- PLAY ENGINE3: implement text input from keyboard

- PLAY ENGINE4: implement level logic transition machine (game walkthrough)

- PLAY ENGINE5: implement the parser to reconnaise text/keypad commands inserted to be used by login transition machine

- PLAY ENGINE6: implement music pause

- SCORE: implement scoring

- BOX: 80%

- OVERLAYS:

- MANUAL: 5%

Overall: 12%

Edited February 8, 2012 by vprette

+DZ-Jay · February 8, 2012

New status (Blue is done, Green is faisable, Yellow is difficult. Red is very hard to code for me)

- TITLE SCREEN: ok (custom screen)

- INTRO: ok (welcome message)

- INIT: ok (integrate tracker and start music)

- FONT: ok (custom)

- CONTENTS: insert all levels message text descriptions 20%

- MUSIC: translate mod to decles

- PLAY ENGINE1: implement PAGE state and transition from PAGE to PLAY by reconnaising disc pressure 5%

- PLAY ENGINE2: ok (inputs from keypad reconnaise 8 directions, "Clear" as music pause and disc touch)

- PLAY ENGINE3: implement text input from keyboard

- PLAY ENGINE4: implement level logic transition machine (game walkthrough)

- PLAY ENGINE5: implement the parser to reconnaise text/keypad commands inserted to be used by login transition machine

- PLAY ENGINE6: implement music pause

- SCORE: implement scoring

- BOX: 80%

- OVERLAYS:

- MANUAL: 5%

Overall: 12%

Great work! I will also help where I can. I have ideas on how to implement the parser, and I plan on writing an ECS Keyboard scanning routine for P-Mach.

You can go ahead and change "PLAY ENGINE6" to green. It's very easy. If you want to stop the music, just call TRKINIT. If you really want to pause so that it later continues where it was, you just silence the PSG and switch to a sub-state that does not update the music tracker. I can give you some very short code that silences the PSG.

-dZ.

vprette · February 8, 2012

.

You can go ahead and change "PLAY ENGINE6" to green. It's very easy. If you want to stop the music, just call TRKINIT. If you really want to pause so that it later continues where it was, you just silence the PSG and switch to a sub-state that does not update the music tracker. I can give you some very short code that silences the PSG.

-dZ.

for precision, I need to pause/unpause the music by pressing Clear button on the controller

+DZ-Jay · February 8, 2012

New status (Blue is done, Green is faisable, Yellow is difficult. Red is very hard to code for me)

- TITLE SCREEN: ok (custom screen)

- INTRO: ok (welcome message)

- INIT: ok (integrate tracker and start music)

- FONT: ok (custom)

- CONTENTS: insert all levels message text descriptions 20%

- MUSIC: translate mod to decles

- PLAY ENGINE1: implement PAGE state and transition from PAGE to PLAY by reconnaising disc pressure 5%

- PLAY ENGINE2: ok (inputs from keypad reconnaise 8 directions, "Clear" as music pause and disc touch)

- PLAY ENGINE3: implement text input from keyboard

- PLAY ENGINE4: implement level logic transition machine (game walkthrough)

- PLAY ENGINE5: implement the parser to reconnaise text/keypad commands inserted to be used by login transition machine

- PLAY ENGINE6: implement music pause

- SCORE: implement scoring

- BOX: 80%

- OVERLAYS:

- MANUAL: 5%

Overall: 12%

Great work! I will also help where I can. I have ideas on how to implement the parser, and I plan on writing an ECS Keyboard scanning routine for P-Mach.

You can go ahead and change "PLAY ENGINE6" to green. It's very easy. If you want to stop the music, just call TRKINIT. If you really want to pause so that it later continues where it was, you just silence the PSG and switch to a sub-state that does not update the music tracker. I can give you some very short code that silences the PSG.

-dZ.

Oh, I just realized that you want to give the player the ability to pause the music during the game. Then it is still easy! Instead of calling TRKPLAY on the "Level" state directly, you set up a variable as a flag and you test it before. If the flag is set, you call TRKPLAY, otherwise you don't. Then when the user presses "Clear" you silence the PSG volume registers and toggle the flag.

Easy! Definitely "Green".

-dZ.

vprette · February 8, 2012

Oh, I just realized that you want to give the player the ability to pause the music during the game. Then it is still easy! Instead of calling TRKPLAY on the "Level" state directly, you set up a variable as a flag and you test it before. If the flag is set, you call TRKPLAY, otherwise you don't. Then when the user presses "Clear" you silence the PSG volume registers and toggle the flag.

Easy! Definitely "Green".

-dZ.

I guess I'll do the same to transition from page to page when in PAGE state:

if the disc is pressed I update a variable, I chekc teh variable and call corresponding page

So if I'm at page 1A the variable is 1, when disc pressed variable is 2, I check and CALL page 1B.... so for each page... since in the game logic I always proceed forward never back...

vprette · February 8, 2012

I realize we need a bug testing phase... I have some crash after going through 15 pages...

- TITLE SCREEN: ok (custom screen)

- INTRO: ok (welcome message)

- INIT: ok (integrate tracker and start demo music)

- FONT: ok (custom)

- CONTENTS: insert all levels message text descriptions 21%

- MUSIC: translate mod to decles of custom music "shadows"

- PLAY ENGINE1: implement PAGE state and transition from PAGE to PLAY by reconnaising disc pressure 15%

- PLAY ENGINE2: ok (inputs from keypad reconnaise 8 directions, "Clear" as music pause and disc touch)

- PLAY ENGINE3: implement text input from keyboard

- PLAY ENGINE4: implement level logic transition machine (game walkthrough)

- PLAY ENGINE5: implement the parser to reconnaise text/keypad commands inserted to be used by login transition machine

- PLAY ENGINE6: implement music pause

- SCORE: implement scoring

- BUG TESTING

- BOX: 80%

- OVERLAYS:

- MANUAL: 5%

Overall: 12%

+DZ-Jay · February 8, 2012

I realize we need a bug testing phase... I have some crash after going through 15 pages...

Can you provide some details? What changes did you do?

+DZ-Jay · February 8, 2012

Oh, I just realized that you want to give the player the ability to pause the music during the game. Then it is still easy! Instead of calling TRKPLAY on the "Level" state directly, you set up a variable as a flag and you test it before. If the flag is set, you call TRKPLAY, otherwise you don't. Then when the user presses "Clear" you silence the PSG volume registers and toggle the flag.

Easy! Definitely "Green".

-dZ.

I guess I'll do the same to transition from page to page when in PAGE state:

if the disc is pressed I update a variable, I chekc teh variable and call corresponding page

So if I'm at page 1A the variable is 1, when disc pressed variable is 2, I check and CALL page 1B.... so for each page... since in the game logic I always proceed forward never back...

Remember to define variables using SCRATCH or SYSTEM macros. In this case, 8-bit SCRATCH should be fine, and it will give support up to 256 pages (0..255).

-dZ.

vprette · February 8, 2012

I do not care much of the crash so far.... I think is due to unlukely reproducible situation: I let the levels call in cascate without waiting... up to 10 level it start writing slow on screen.. If I put 15 levels (that is written pages) in cascate it crashes like some overflow happened.... but this will not be the case of play state since we are supposed to wait for user input.. still, i wonder what is the reason (cp1600 or emulator?)

Edited February 8, 2012 by vprette

+DZ-Jay · February 8, 2012

I do not care much of the crash so far.... I think is due to unlukely reproducible situation: I let the levels call in cascate without waiting... up to 10 level it start writing slow on screen.. If I put 15 levels (that is written pages) in cascate it crashes like some overflow happened.... but this will not be the case of play state since we are supposed to wait for user input.. still, i wonder what is the reason (cp1600 or emulator?)

Valter, send me or post the code that you use for the paging and I'll try to find out what's wrong.

-dZ.

+DZ-Jay · February 8, 2012

I do not care much of the crash so far.... I think is due to unlukely reproducible situation: I let the levels call in cascate without waiting... up to 10 level it start writing slow on screen.. If I put 15 levels (that is written pages) in cascate it crashes like some overflow happened.... but this will not be the case of play state since we are supposed to wait for user input.. still, i wonder what is the reason (cp1600 or emulator?)

I was thinking about what you said and I think it could be a task queue or a stack overflow. I added some debug code to Christmas Carol to trap errors such as these and display state information prior to crashing. I can send you this code and add it to P-Machinery in the future.

Note that by default, P-Mach sets the size of the task queue to 8 (0..7 in TSKQM/MAXTSK) and the stack to 16 (STACK_SIZE). This should be sufficient for most applications, but it can be incremented to 16 (0..15). The stack can be incremented to about 40.

However, keep in mind that incrementing the sizes will take more System RAM, which is precious. You are very early in your development, and you haven't many tasks to deal with nor much nested logic, so if these resources are being exhausted right now it is most likely either a bug, or something that can be easily optimized.

In any case, you can play with the numbers and re-assemble, and see the usage change in the assembler output message.

-dZ.

Edited February 8, 2012 by DZ-Jay

vprette · February 9, 2012

I made a new brand for this project and hopefully further ECS projects of mine in the future :-)

do you like?

About the test variable, I defined this on the "cart.mac"

; --------------------------------------

; Variable for Page state (from page to page)

; --------------------------------------

PAGESTEP SCRATCH 1

now what I need to do is add in the MY_INPUT_DISC proc check of the variable and CALL to correspondent page, plus incresing the variable.

In basic terms (blue being not-asm code to be translated)

MY_INPUT_DISC PROC

; --------------------------------------

; Event Dispatch Table

; --------------------------------------

DECLE D_DISC ; Disc

ENDP

D_DISC PROC

BEGIN

; PAGE CHANGE - Handle disc input

CMPI #CTRL_DISC.Right, R2

BEQ @@disc

CMPI #CTRL_DISC.Left, R2

BEQ @@disc

CMPI #CTRL_DISC.Up, R2

BEQ @@disc

CMPI #CTRL_DISC.Down, R2

BEQ @@disc

@@disc: ; choose page

IF PAGESTEP = 1 then

CALL LEVEL_2B

PAGESTEP = PAGESTEP +1

ELSEIF IF PAGESTEP = 2 then

CALL LEVEL_2C

PAGESTEP = PAGESTEP +1

...

RETURN

ENDP

how do I handle an IF... ELSEIF logic?

Edited February 9, 2012 by vprette

+DZ-Jay · February 9, 2012

I made a new brand for this project and hopefully further ECS projects of mine in the future :-)

do you like?

Looks nice.

About the test variable, I defined this on the "cart.mac"

; --------------------------------------

; Variable for Page state (from page to page)

; --------------------------------------

PAGESTEP SCRATCH 1

now what I need to do is add in the MY_INPUT_DISC proc check of the variable and CALL to correspondent page, plus incresing the variable.

In basic terms (blue being not-asm code to be translated)

MY_INPUT_DISC PROC

; --------------------------------------

; Event Dispatch Table

; --------------------------------------

DECLE D_DISC ; Disc

ENDP

The dispatch table for CTRL_CHECKKEY needs to include event handlers for all input types. You can just simply return with no code in the ones you don't want to handle, but they need to be there.

D_DISC PROC

BEGIN

; PAGE CHANGE - Handle disc input

CMPI #CTRL_DISC.Right, R2

BEQ @@disc

CMPI #CTRL_DISC.Left, R2

BEQ @@disc

CMPI #CTRL_DISC.Up, R2

BEQ @@disc

CMPI #CTRL_DISC.Down, R2

BEQ @@disc

It looks like you are doing the same for all directions. If this is the case, you do not need the comparisons. The event will be called whenever any direction is pressed on the disc, so just execute normally when that happens.

@@disc: ; choose page

IF PAGESTEP = 1 then

CALL LEVEL_2B

PAGESTEP = PAGESTEP +1

ELSEIF IF PAGESTEP = 2 then

CALL LEVEL_2C

PAGESTEP = PAGESTEP +1

...

RETURN

ENDP

how do I handle an IF... ELSEIF logic?

IF...ELSIF logic is handled using the test-and-jump pattern: you test for a condition and jump to a branch if true or false. You do this for all conditions you want to test. For example:

      MVI       PAGESTEP, R0

      ; IF (R0 = 1) THEN GOTO LEVEL_2B
      CMPI     #1, R0
      BEQ       LEVEL_2B

      ; ELSEIF (R0 = 2) THEN GOTO LEVEL_2C
      CMPI     #2, R0
      BEQ       LEVEL_2C

      ; ELSE

However, I am curious why you need a different procedure for each page? If you store your text in ROM and you index them with a table, then you can use the same routine to print the text always, just change the pointer to the table, no?

-dZ.

+DZ-Jay · February 9, 2012

Oh, by the way and unrelated to this last issue, I meant to mention before that there's a macro in P-Mach to convert screen coordinates into BACKTAB addresses. I noticed that you hardcode the position where you want text to appear when you call PRINT.FLS, and I thought you could use this instead to make it easier:

      CALL PRINT.FLS
      DECLE   C_GRN, BTAB_ADDRESS(col, row)
      DECLE   'This is my text'

Where "col" and "row" represent the screen column and row, respectively. Columns are from 0 to 19, rows are from 0 to 12.

-dZ.

vprette · February 9, 2012

The dispatch table for CTRL_CHECKKEY needs to include event handlers for all input types.

yes I noticed, in fact I have cutted part of the code to make the post simplier, sorry :-)

It looks like you are doing the same for all directions. If this is the case, you do not need the comparisons. The event will be called whenever any direction is pressed on the disc, so just execute normally when that happens.

that's what I imagine, so I can cut all that code and write directly the IFTHEN part..

However, I am curious why you need a different procedure for each page? If you store your text in ROM and you index them with a table, then you can use the same routine to print the text always, just change the pointer to the table, no?

-dZ.

I will consider this, that would mean to have only 2 proc, one for Play sub-state and one for Page sub state.. I have to think about this

Edited February 9, 2012 by vprette

+DZ-Jay · February 9, 2012

The dispatch table for CTRL_CHECKKEY needs to include event handlers for all input types.

yes I noticed, in fact I have cutted part of the code to make the post simplier, sorry :-)

It looks like you are doing the same for all directions. If this is the case, you do not need the comparisons. The event will be called whenever any direction is pressed on the disc, so just execute normally when that happens.

that's what I imagine, so I can cut all that code and write directly the IFTHEN part..

However, I am curious why you need a different procedure for each page? If you store your text in ROM and you index them with a table, then you can use the same routine to print the text always, just change the pointer to the table, no?

-dZ.

I will consider this, that would mean to have only 2 proc, one for Play sub-state and one for Page sub state.. I have to think about this

Sure. You know, on the "thinking" part, when I started working on my Pac-Man port, I spent months working on the theory of the game before ever writing a single line of code. I did not know much Assembly Language, had no idea about programming for Intellivision, understood very little about the colour and graphics restrictions, etc., so I concentrated on "thought experiments" to consider how to build the game in concept.

I took over an entire year of on-and-off "design" and "theory" work. At the end, I had a very clear idea of how to implement the game logic, for instance, how to track the pills eaten by Pac-Man, how to store the maze design in ROM in a way that encodes all path information, and how to maintain a table of parameters that change on every level. I also came up with a state machine model that I could use to handle the game engine.

Most of that theory resulted in P-Machinery and eventually culminated in Christmas Carol.

It's fun to start coding and see things happen right before your eyes, but sometimes it's more fruitful to spend some time considering how the entire thing would work, and how to put it together. It's boring stuff sometimes, and it's most in your head; but it leads to a more solid program.

This is your project, and you should do as you wish with it. There are probably ways in which I would do it differently, but I wouldn't want to impose my personal ways on you. After all, I'm also starting as a game programmer.

That said, I'll assist you in any way I can, just let me know if there's anything I can do. I just want to see other projects succeed.

-dZ.

vprette · February 9, 2012

To increase the variable and reconnaise the page I wrote this.

D_DISC PROC

BEGIN

; handle "next page"

MVI PAGESTEP, R0

; IF (R0 = 1) THEN GOTO LEVEL_2B

CMPI #1, R0

BEQ @@2B

; ELSEIF (R0 = 2) THEN GOTO LEVEL_7B

CMPI #2, R0

BEQ @@7B

; ELSE

BEQ @@ELSE

@@2B:

INC PAGESTEP, R4

CALL LEVEL_2B

return

@@7B:

INC PAGESTEP, R4

CALL LEVEL_7B

return

@@ELSE:

RETURN ;return della procedura D_DISC

ENDP

but the procedure always call 2B... so the variable is not incremented in fact.... what do I wrong?

Edited February 9, 2012 by vprette

Colossal Cave Adventure diary

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Recently Browsing 0 members