| |
Richard
Registered: Dec 2001
Posts: 621 |
NEW GAME: GALAXYS
I have produced a new retro-style C64 game called 'Galaxys'
You can download the game from this URL below:
http://www.redizajn.sk/tnd64/download_games.html
I await any reactions :) |
|
| |
fade
Account closed
Registered: Mar 2002
Posts: 290 |
Hey Richard, you seem to make a lot of small games, why not work on something a bit more daunting and complex than collecting cherries and not running into moving bricks?
Something like Wonderboy 2 or Mean Streets by Access.
Just a suggestion.. |
| |
Rough
Account closed
Registered: Feb 2002
Posts: 1829 |
i told him the same a few days ago. 8) |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
A quite long analysis follows... this is not meant in any cold, evil, sarcastic or malicious way but to examine why Rich may not ever do more complicated games. (I might be wrong, let's wait for the horizontal-scrolling SEU he threatened to make)
I believe that when a person has reached a certain level in programming (usually doing something away from C64, like C coding, helps to see the "bigger" picture of problems, algorithms etc.) he will know how to approach almost any coding problem, and because C64 games have a quite limited scope, he can create an arbitrarily complex C64 game. Of course the technical skills (knowledge of C64 hardware, asm optimization) may still limit but generally they aren't much of a problem at this point.
But, Rich has not reached this level yet. He clearly lacks some fundamental knowledge of maths in C64 asm, bit manipulation etc. and also some concepts like state machines, that are required for more advanced gameprogramming. But he has quite successfully "fooled" us all to expect something more, by using his limited skill set pretty much to the maximum in creating those small C64 games. And he has even been expanding his skill set little by little, for example the wrap-scrolling BG graphics in Bomb Chase.
Rich may not possess the required imagination or perseverence to reach the "next" level in programming, in which almost everything becomes possible. Or he might simply enjoy creating these little games too much, to actually learn something higher. After all, C64 hobby coding is not a job, where you're expected to learn more... :)
I'm sure, even now Rich could create quite a complex game (for example a scrolling SEU) with someone's pretty much constant assistance. But would that be worth it? Isn't the point of C64 coding in knowing how to create things yourself?
Ok, end of analysis & rant. Agree/disagree, anyone? Because I'm a self-taught programmer, my view can be somewhat skewed (I just don't think programming can be taught beyond a certain point -- at some point a lot of own imagination & creativity is going to be required.) And to repeat, I hope I didn't offend Rich with this analysis. |
| |
JCB
Account closed
Registered: Jun 2002
Posts: 241 |
Agreed :) I'm self taught too and started a job as a games coder 15+ years ago and if I knew then what I know now WOOT :P Sometimes I wish I could travel in time, even now I remember bits of code I wrote and think "hey, if I did that this way it would have been way faster" but then there are things I coded on c64 which I probably still couldn't beat today.
I think Richards problem is a lack of someone to challenger his current fluffy warm state of being one of the only game producing sceners around so he keeps releasing "little" games and he's happy with it because theres nothing to make him think "jeez my games are lame compared to that".
I noticed on the Lemon forum he (you if you're reading Richard) asked "what game shall I do now" and it turns out people want Chaos Engine, I say go for it, they may have been joking but even attempting it would be a good learning experience, working out how to do the 8 directional scrolling (you could probably lock it to 4 directions which would help), I think it would need colour ram scrolling too, a multiplexer, a "goals" based system (the bitmap brothers had 1 basic editor which they made lots of games with using trigger points and puzzle "rules"), keeping track of a world's worth of enemies and what you've destroyed/picked up already etc etc the list does go on and on but it's not THAT hard. |
| |
Warbaby
Account closed
Registered: Mar 2002
Posts: 60 |
JCB:
Chaos Engine for the c64?!?! Would be great, but finding a decent colorscheme could be difficult. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Lots of grey, perhaps some green... :) Especially the sprite colors would be pain. Perhaps it'd require overlayed sprites for more colors.
I might have overestimated the difficulty of doing ChaosEngine on C64 (in the lemon64 post), but, don't forget the AI controlled player! (I'd say that's quite a challenge, as he can dodge the bullets, collect things on his own etc.) |
| |
JCB
Account closed
Registered: Jun 2002
Posts: 241 |
Colours would be a pain but it doesn't have to look exactly the same as the 16bit versions. I had the idea of plotting only selected areas of colour ram (for certain tiles) with a little "cleanup" thing for the areas they've just scrolled from so you could have colour scrolling without using too much processor time. Sprites, yeah, be nice to have a 2sprite per main guy thing going on for extra colours/definition. As for the AI guy, I've coded quite a lot of AI/NPC stuff in the past and that one is pretty stupid imo :) shouldn't be hard to do.
-disclaimer-
JCB is in no way saying HE is going to write C64 Chaos Engine :P I wish I had the time then I would (and I'm sorely tempted to just start anyway) but I've got soooo much other code to do even starting would be a bad idea. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Yes, I agree he sometimes moves quite randomly when he doesn't have bullets to dodge, but he stays alive fairly well :) (lot better than I)
But then again, it was on Amiga, which has a lot more of CPU cycles than C64. I guess A* pathfinding (or what the hell that is called) or any other sophisticated algorithms are out of question? :D |
| |
JCB
Account closed
Registered: Jun 2002
Posts: 241 |
The pathfinding (I don't think it's got a specific name) isn't that complex to do, think about a game like paradroid, yeah they robots are all set on fixed paths to begin with but when you get in a fight they wander from those paths to attack you then trundle back when they/you are done. Theres lots of ways to handle something like that that don't take much processing power. |
| |
Richard
Registered: Dec 2001
Posts: 621 |
The 'Chaos Engine' sort of game sounds good, but it would be really difficult. As the people above mentioned I lack confindence with 'Map-scrolling', as it is so difficult. I could do with the 'Firebird' graphic editor (as TMR mentioned) is there anywhere on the net where I can download that?
Also map scrolling would not be that easy, because there's more than meets the eye compared to scrolltext messages. It would help if I studied more about the scrolling. I remember a small routine supplied Amebas Graphics Editor for 'Turbo Assembler', where you can mapscroll. Maybe I could use a char editor to do the graphics using Dooso's 'Amebas' editor to put the chars into blocks and map these, and then study the horiz-scrolling routine and make notes about it. - Not code-ripping of course, because lamers don't do that.
I hope to use that sort of engine for Fruit fighters and a Christmas game for December 2002 ;) |
| |
JCB
Account closed
Registered: Jun 2002
Posts: 241 |
Map scrolling is honestly not that hard to do. it's just a level of indirection from a message scroller plus basically repeating the same code for the whole screen.
I'm not sure how you code your message scrollers but if you do the "move screen contents left then add next letter from message to the end" way then you're halfway there. In it's simplest form it goes something like this. Just take each message "letter" as being a block number, say a 2x2 block, so shift it left 2 to multiply it by 4, that gives you your block offset. You also need to keep a toggling 0/1 value somewhere that you flip every 8 pixel scroll, add that to your offset and you have your current characters to print ,just put that in X then lda tiles,x store to screen then lda tiles+2,x and store that on the next line down.
Thats basically it for a horizontal tile map scroller. Like I say, it's the most basic way of doing it, you're limited to the number of tiles because of the multiply by 4 with no carry check, if you need more tiles just check the carry and alter the actual address of tiles on the lda tiles,x bit above, maybe use zeropage indirect addressing to save some time. Maps (or at least sections of them) can be pre-decoded to an area of ram to save time calculating the tile data offsets, you'd probably do this while the smooth scrolling was happening. You can also use 2 screens for a front/back buffer thing and decode the pre-scrolled map onto the back buffer while the smooth scroll is happening but this brings limitations of which direction are you going, if it's fixed then fine, if it's 8 (or even 2) directional then when do you decode the next directions map?, what if they change direction suddenly etc (look at Citadel and notice what happens when you move your ship, you don't have FULL control over it once you start moving) I think he uses the "window" method where the screen only scrolls when your ship reaches a certain point on the screen, that way he can almost always guarantee which direction he needs to scroll, the screen then scrolls a fixed amount in that direction, when you turn around he doesn't automatically neeed to start decoding in the other direction because you've got to move your ship to the other side of the "window" before it will scroll again..
If you want to try to code one and get stuck then I'm happy to help out, I can't remember if my email is on here but if it isn't you can get it from one of my lemon forum posts. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Hmm...this pre-decoding sounds complex, and strange?! Maybe Walker just split the screen-copying on several frames and that explains the delay.
Anyway, I use startaddresses of blocks stored into a lookup table and bytes from the map are indexes to this table, this way deciding what to draw on the edge of screen is quite fast "on the fly", without any precalculation.
(in any kind of precalculation one's still shifting data around, I prefer to keep that to minimum as a LDA or STA is always a painful 4 cycles...)
And how I keep track of the map position is following: (for 4x4 blocks)
* variable "blockx" - indicates what char of block (0-3) is in the top-left corner of screen, in horizontal direction
* variable "blocky" - same in vertical dir.
* variable "mapx" - what block is in the top-left corner, measured from map's left edge (0-n)
* variable "mapy" - same for vertical, measured from map's bottom (0-m)
Things get fun when you have to account for sprite position changes due to scrolling. Simply put, this is achieved by converting the top-left screen position to pixels (multiplication) and subtracting that from all sprite coordinates before displaying
(here assuming that sprites positions are specified in "world" coordinate system - I never like to store them in "screen" coordinate system, too raw for me, although might be faster)
|
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Ah, of course not measured from "bottom", but "top" |
| |
JCB
Account closed
Registered: Jun 2002
Posts: 241 |
Don't forget mine was supposed to be for Richard who doesn't understand how to do one, I can't go giving away all my secrets :P |
| |
Rough
Account closed
Registered: Feb 2002
Posts: 1829 |
I disagree.
I believe Richard is the kinda person who wants to have the results quickly on the table and cant await until a good program "ripes" (does this word exist?) in its progress. that's why he also lets us constantly know about the progress of his programs cause he wants our attention on his work (which is an understandable and very human attitude, i know from myself) - if you, richard, would more concentrate on the work itself and make it your way than on the people's opinions about it during development you'd surely find the time and joy for a big project.
@jcb: you're not the only one. i also often wished to travel back into 1984 for and code something like 'wizball' 8) |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Yeah JCB, I merely wanted to provide a second, contrasting view to the thing...
|
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
rOuGh, your arguments are also valid, but I'd like to suggest 2 tests/questions to determine whether Rich is actually up to writing more complex games:
1) Programming a music replayroutine? Not necessarily anything to rival DMC- or JCH-playroutines, but something that can handle note pitch, their duration, and instrument parameters (ADSR, wave etc.)
2) Programming a fully functional Tetris clone?
These tasks may seem trivial but both involve data structures and logic that's more complicated than any of his games up to date.
|
| |
T.M.R
Account closed
Registered: Dec 2001
Posts: 749 |
Erm, *i've* never coded a music driver or Tetris clone...?! |
| |
Pater Pi
Account closed
Registered: Jan 2002
Posts: 121 |
You aren't Richard.
You are The Magic Roundabout! |
| |
T.M.R
Account closed
Registered: Dec 2001
Posts: 749 |
Ah, i'm glad we've cleared that up... i think? |
| |
JCB
Account closed
Registered: Jun 2002
Posts: 241 |
Boing... time for bed hehe |
| |
Shadow
Account closed
Registered: Apr 2002
Posts: 355 |
>Sometimes I wish I could travel in time, even now I
>remember bits of code I wrote and think "hey, if I did
>that this way it would have been way faster"
Yeah, I've thought the exact thing many times.
"If I knew then what I know now, I would have been one badass C64 coder!"
|
| |
Richard
Registered: Dec 2001
Posts: 621 |
I have released version 1.4 (latest bugfixed version) of POING. This is because some bug had been found in the Game Over code after a delay, the game had crashed to the READY. prompt, but now I have fixed this problem. I have realised what the error is, and that is because I had forgetten to turn off the IRQ routine players. After turning those IRQ routines off the game works 100% a treat.
In future when I produce games, I should look at the game more before releasing it, else I probably end up having a hellish nighmare of releases of the same game. I suppose that's typical of me ;)
You can download the game from the url below:
http://www.redizajn.sk/tnd64/poing.zip
Time for me to work on some more games I think, rather than piss about on these message boards lol! |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
When your production is on the complexity scale between Turrican - Enh.Newcomer, a few patches should be allowed :)
But yeah, sure it's good idea to keep small games bugfree in the first place. |
| |
Richard
Registered: Dec 2001
Posts: 621 |
Quote: When your production is on the complexity scale between Turrican - Enh.Newcomer, a few patches should be allowed :)
But yeah, sure it's good idea to keep small games bugfree in the first place.
I've done a Christmas game for the CSDB compo, I've sent it and YES it is 100% bug free ;) |
| |
Rayne
Account closed
Registered: Jan 2002
Posts: 30 |
Richard: eehm, i've found a very little bug in Poing 1.4. I was able to switch the Charset by Pressing SHIFT and C= which makes the in-game screen look ugly, just lock the ability to switch the Charset in your next version :) |
| |
TDJ
Registered: Dec 2001
Posts: |
Quote: Richard: eehm, i've found a very little bug in Poing 1.4. I was able to switch the Charset by Pressing SHIFT and C= which makes the in-game screen look ugly, just lock the ability to switch the Charset in your next version :)
Sorry Trance,but you're wrong. Richard has stated that this is the 100% version so there are no bugs. The only bugs are those in your head .. ;) |
| |
Pater Pi
Account closed
Registered: Jan 2002
Posts: 121 |
He said this about his Christmas Demo Compo entry, not about Galaxys I think....
|
| |
Rayne
Account closed
Registered: Jan 2002
Posts: 30 |
TDJ: Micro$oft also released "final" versions of their operating systems. do you think the bugs in this damn o/s are also in the heads of its users? :) |
| |
Richard
Registered: Dec 2001
Posts: 621 |
Hmm, I think most of my games uses the Shift+C= keys, but that cannot be helped because I don't know how to convert the basic code PRINT CHR$(8) into assembly code. Can anyone help? |
| |
Rayne
Account closed
Registered: Jan 2002
Posts: 30 |
well, PRINT CHR$(8) is
LDA #$08
JSR $FFD2
in Assembly :) |
| |
Richard
Registered: Dec 2001
Posts: 621 |
Ah, thanks dude :) |
| |
CyberBrain
Administrator
Posts: 392 |
An even better solution is to turn off all the kernal-nonsense. (including the interrupt that checks SHIFT+C= ofcause) |
| |
JCB
Account closed
Registered: Jun 2002
Posts: 241 |
Agreed.. Turn off all the roms, vector through $fffe-$ffff for your IRQ, do a keyboard matrix read yourself if you need to read keys and hey presto :) saves processor time too, no more leaving irq routines via $ea31 (or whatever it was soooo long ago I can't remember) just either push/pop a,x and y or store them in zero page or even store them in coresponding lda #?? ldx #?? ldy #?? instrucions at the end of the irq code. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
If there's no specific need to use 100% CPU power,
LDA #$80
STA $291
will also disable the C= + Shift combination conveniently. |
| |
Richard
Registered: Dec 2001
Posts: 621 |
How about random counters. Say when I produce a game, I wanted to do random graphics appearing (Someone suggested I do an improvement to PoInG, by adding 1 player option, and also random graphics. - They loved the game as well. I was thinking of recycling this game, making it 10 times better and fun, compared to the original release.
Can you tell me what the assembly routine for random generations between 1 and 6 are?
X = INT(6*RND(1))+1
|
| |
Stryyker
Registered: Dec 2001
Posts: 468 |
If you can spare a 256 byte table, create a repeating table that goes 1,2,3,4,5,6. Then develop some random number routine using maybe the seed values, maybe using CIA timers or SID voice 3 output with some adding/shifting etc. Even if value is anything from 0 to 255, you use this as offset to the 256 byte table and it's scaled down. |
| |
Richard
Registered: Dec 2001
Posts: 621 |
Quote: If you can spare a 256 byte table, create a repeating table that goes 1,2,3,4,5,6. Then develop some random number routine using maybe the seed values, maybe using CIA timers or SID voice 3 output with some adding/shifting etc. Even if value is anything from 0 to 255, you use this as offset to the 256 byte table and it's scaled down.
I remember writing a routine for Heavy Metal Deluxe, which had randomized the colours when the player shoots each block and the block appears at the top of the screen. I used .BYTE 1,2,3,4,5; according to colour and created a routine, which I usually use to put .BYTE 5 into .BYTE 1, like with the colour roll routines. Taking the last byte and replacing it with the first byte, and pulling the bytes along inside a loop. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
I practically always use values fecthed from the code by a zeropage or selfmodifying pointer, and ADC, EOR, ROL etc. them together. This could be used as an index
(you can use a shorter table, like 32 bytes, when you AND the index before use, AND #$1F in this case) |
| |
T.M.R
Account closed
Registered: Dec 2001
Posts: 749 |
SEUCK does something similar for the 8 way firing routine, just reads a chunk of the editor code and uses it to pick one of eight directions - that's why the random routine sometimes needs repointing if you clean the editor out and don't re-use that RAM... =-) |
