| |
Disthron
Account closed
Registered: Sep 2013
Posts: 21 |
Looking for C64 programmer [paid]
Hi everyone,
I've been developing a retro throw back game for the PC in the style of the Commodore 64. I'm working on a Kickstarter project to get it finished and I was thinking of having an actual Commodore 64 port as one of the stretch goals.
No one on the team has any live C64 programming experience so I'm putting the call out to people who might be interested in working with us. The artwork will have to be converted. Our artists try to stay as faithful to C64 specs as possible but little things can still slip through the cracks. Also you'll basically be on your own programming wise. If you're interested in the project please send me a PM and we can talk more about specifics.
Since this will be a stretch goal I can't guarantee this will go ahead even if we get funded. But I need to talk to someone in order to know how much it will cost, and thus how much to ask for in the stretch goal.
Thanks for reading my post.
~Disthron |
|
... 63 posts hidden. Click here to view all posts....
|
| |
Disthron
Account closed
Registered: Sep 2013
Posts: 21 |
@Hein: Well, I've worked on a bit of code but mostly I'm the producer/game designer. It feels kind of strange, on my first game I did almost everything. Witch was a big mistake, specially in the art department. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Yup, looks like a pretty huge project, especially once you add all the other stuff from the trailer to the combat you've shown here.
As for the combat:
I'm seeing up to six characters on screen at once in the youtube trailer, which would all have to drop down to single sprite width (12 multicolour pixels), three colours per character, two of which are shared between all of them. (The T-Rex at 2:06 isn't too big if unaccompanied, but also has waaay too many colours.)
If you stuck to at most four characters on screen they could be twice as wide, but you'd still have the same colour restrictions. That solid circle behind the player for the special attack would have priority issues too, unless it was a flickery every-second-frame thing.
Drop to three characters on screen, and you gain both
-an extra colour on the player character and
-a flicker free solution for the solid circle.
(alternately, never mind the extra colour, and get back some coding time, some memory, and some CPU time)
The backgrounds look more like multicolour bitmaps than character mode, so you'd have to lose either the vertical scrolling, or all of
- the top dozen lines of the display area
- the ability for enemies to walk on from the top of the screen
- a week or three's coding time
- all but two colours of an 8x1 character area somewhere onscreen (perhaps an uninteresting bit of floor?)
Keeping the foreground archway to indicate a door at the bottom of screen would also cost you; at least one enemy would have to stay out of the bottom half of the screen whenever the enemy count's maxed out. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
CJ, just cut it back some more, instead of fighting too hard, for too little gains.
bushido posted earlyer is excellent for inspiration.
- 1 spr wide characters +1 for sword swing
- charmode with d800 a trained gfxer can do wonders
- no archway
- flash player color instead of solid circle, or flicker, or just 1 sprite for circle ?
I think gameplay is more important here than being faithful for nr of colors, and sprite width, etc.
dinosaur is problematic even with colors cut back, would eat up mem like crazy.
probably it would be wise to use a cart, instead of multiload and fighting 64k limit. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
You're probably right, Oswald. I just prefer saying "This would cost you X" to saying "this cannot be done"
It's all compromises, and decisions like "six thin enemies vs two wide enemies" are ones I'd rather leave to the game designer.
I do agree that the arch adds very little for its cost, and a char mode background should be just fine if the graphicians are worth their salt. Still think I'd lean towards keeping the left-right panning, if not the up-down. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
The main question to me is whether one would want to go full softwaresprite -route, which in theory allows 1:1 porting of the characters size-wise, and with no sprite limits, just slowing down the more (and bigger) enemies there are.
If the choppyness of the video the same as in actual PC gameplay, it might even have a nice "low FPS" aesthetic. Though I wouldn't swear that the C64 could maintain that same speed, especially when scrolling a bitmap background.
However, to avoid color clashes it would likely mean only having the same 4 colors on both the characters and background, which could get dull. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
definitly no soft sprites, color clash & speed would be problematic. one could go down the speccy route with thick black outlines to solve the clash problem, but then still color memory has to be updated, and how on earth one would scroll the bg, that alone would need something like 3,5 frames (8000 bytes + lda ,x sta ,y do the math). then double buffering eats up memory.. |
| |
CreaMD
Registered: Dec 2001
Posts: 3057 |
Software sprite route would rock. In past many games got bend to hardware sprite constraints and their aesthetics was diminished. Or visual design was completely changed (like with Amaurote.. check Atari and Speccy version for isometric superriorness).
P.S.: Agrees with Oswald that it would be a very risky route though ;-) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Yes, colour clash on software sprites would be a pretty major issue, and the ram cost for the buffers would be quite high.
Scrolling's not such a problem though - $d011 tricks to the rescue :D |
| |
Six
Registered: Apr 2002
Posts: 293 |
I've been involved in such a project before (DTV/Hummer), and my observations based on that experience:
You're going to need several people, each with experience in commercial game production for the c64, with differing specialties, to make this happen.
You will need at least one person whose sole role is to produce the graphic and/or audio elements. We had one of each on the Hummer team. IIRC, Andrew Fisher was the audio guy.
You will need at least one person who specializes in conversions and tooling, and can also do some of the grunt-work coding. This was my role on the Hummer team.
You will need a very organized project manager. If you can get Robin Harbron, you should. He did amazing work on the Hummer project.
You will need at least two engine-programmers, one with a strong background in game engine development, the other with a strong grasp of VIC-trickery. This was Adrian Gonzalez and Robin Harbron on the DTV team.
Finally, you'll need a BUNCH of dedicated testers - people who have solid experience playing CC64 games, and who can handle setting up VICE, etc...
Just my advice, your milage may vary. The DTV/Hummer team could probably be put back together for the right price if you're serious. Just don't run the end product through some cost-reduction process in HK. ;) |
| |
Mr. SID
Registered: Jan 2003
Posts: 424 |
Interesting, anything you can tell us related to the budget for the Hummer project? |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
