Selling 'Homebrew' games in Rom form?

[Mr SQL]

@Rev: Don't worry about it. In my mind its a valid topic for discussion for homebrewers, publishers and game purchasers. Anyways.... We have a much better idea about Inty homebrew sales numbers now.

X2 GroovyBee, this is a great discussion topic revolutionika!

 

Multicarts open up new possibilities for playing and buying games in ROM format that we are going to see more of; games that are either more ideal for the multicart or expressly designed to take advantage of it's expanded features.

 

I've released BREAKANOID in ROM format for the Atari 2600 as a series of four game ROM's with the option to put one of them on cart, but the series is designed for the Harmony and comes with a Level Editor for windows that lets you build additional game ROM's; these aspects of the release have influenced more than one gamer to also buy a Harmony cart.

 

And as far as piracy it's a minimal issue compared to the 80's just as the market is minimal; fans and collectors support homebrew development

[GroovyBee]

Cool, now how are your games coming along? Any progress?!?!?!

 

The XM games are still taking all of my spare time at the moment. I had hoped to start Inty programming after Easter but that didn't happen. As soon as I have completed a few more titles the Inty will be getting some love again.

[townparkradio]

It's Donkey Kong ... let's face it, if you created an app for the iPad exactly like this, Nintendo would be on you faster than Rev on a Golden Girl ... this escapes through because it's created for a system that most of the rest of the world have forgotten about.

 

People still buy Intellivisions (I still sell them on eBay quite well!) but they buy them to relive their favorite games. That creates a market, but only for old existing games that people played as a kid. Some people, such as myself, will stumble onto this board and find the wonderful world of Intellivision here and see the value in new games ... but not most. I think that you need to appeal to them in one of two ways. First, bring a popular game onto the system (such as D2K has done) or second, to create a sequel to existing Intellivision games (who wouldn't want to buy Night Stalker II or Super Pro Snafu, etc). They get a new game AND a sense of nostalgia. I understand there are potential legal issues with either of those plays but are they realistic as selling cartridges does not seem to conflict with the current Intellivision owner's game plan.

 

They did propose a sequel to Night Stalker once. I believe the proposed title "Lady Stalker" wouldn't go over as well now as it would have in the 80's.

[+Gemintronic]

I already posted my idea to wrap the ROM in a single game emulator to solve the App Store no general emulators unspoken rule. No feedback there.

 

How about just prototyping your games directly on a PC/Mac/Linux box? If it sells well enough as a game for a popular platform then go ahead with the real thing.

Edited June 28, 2012 by theloon

[GroovyBee]

How about just prototyping your games directly on a PC/Mac/Linux box? If it sells well enough as a game for a popular platform then go ahead with the real thing.

 

Nice idea but the game might be unworkable on your platform of choice due to sprite sizes and their colour depth, no of sprites on screen at once, algorithms used for logic and AI, RAM consumption etc.

[+wood_jl]

The XM games are still taking all of my spare time at the moment. I had hoped to start Inty programming after Easter but that didn't happen. As soon as I have completed a few more titles the Inty will be getting some love again.

 

Good grief! What consoles can you NOT program? I'm impressed! You did some ST and A8 stuff too?

[GroovyBee]

Good grief! What consoles can you NOT program? I'm impressed! You did some ST and A8 stuff too?

 

I have several Inty and 7800 games on the go at the moment (the publicly announced stuff is on my AA profile page). I programmed the Atari ST a great deal back in the day but didn't touch it again up until a few years ago (maybe a week of coding if that, nothing major). I haven't done any A8 stuff yet although I have promised to do a game as part of Replay (UK retro event). I recently won a Philips G7000 (it was a prize) and I'll probably do something for that at some point too. I have quite a few machines on my "would like to do something for ...." list including Dragon 32, NES, BBC micro, jag, Mega Drive. Its all fun stuff to play with.

[+Gemintronic]

How about just prototyping your games directly on a PC/Mac/Linux box? If it sells well enough as a game for a popular platform then go ahead with the real thing.

 

Nice idea but the game might be unworkable on your platform of choice due to sprite sizes and their colour depth, no of sprites on screen at once, algorithms used for logic and AI, RAM consumption etc.

 

This is all I have to say about that:

noc.zip

[GroovyBee]

This is all I have to say about that:

 

Whatever is in that binary is in unicode .

[+Gemintronic]

Really? I just ran noc.rom in Bliss before posting

 

c:\sdk1600\bin\as1600 -o noc.rom -l noc.lst noc.asm

Edited June 28, 2012 by theloon

[GroovyBee]

Bliss means Inty means ASCII bytes on word boundaries . Looks like unicode but isn't.

[catsfolly]

The Z80 and 6502 processors were used in millions of home computers, so there was a great interest in developing software for them. So, C compilers were developed.

 

The CP1610 processor was used only in the Intellivision (and one other game machine?), so there are no C or Basic compilers, just one assembler.

 

Mathematically speaking, it looks like the set of people who

 

1. Have compiler writing skills, and

2. Have the time and inclination to write compilers in their spare time for fun, and

3. Are interested in Intellivision development

 

appears to be zero. :-)

 

I think a high level language for the Intellivision would lead to more development, and more people getting involved in Intellivision programming.

 

 

Catsfolly

[+DZ-Jay]

The Z80 and 6502 processors were used in millions of home computers, so there was a great interest in developing software for them. So, C compilers were developed.

 

The CP1610 processor was used only in the Intellivision (and one other game machine?), so there are no C or Basic compilers, just one assembler.

 

Mathematically speaking, it looks like the set of people who

 

1. Have compiler writing skills, and

2. Have the time and inclination to write compilers in their spare time for fun, and

3. Are interested in Intellivision development

 

appears to be zero. :-)

 

I think a high level language for the Intellivision would lead to more development, and more people getting involved in Intellivision programming.

 

 

Catsfolly

 

Actually, that number rounds up to 2, not zero.

 

I started some time ago working on a higher-level language for the Intellivision called SPLINT (Simple Programming Language for INTellivision), that was C-like in syntax. It would depend on a run-time engine, like the EXEC but on steroids, that would provide facilities for sound and sprite. Combined with a flexible development framework, it would simplify game programming for the Intellivision. (The run-time engine would be called SPLINTer, for SPLINT execution run-time).

 

Joe and I started working on it almost two years ago, and he went some way into building pieces of the compiler, based on an old project of his. The project was frozen when Christmas Carol came along and took over my life, but I intend to continue on it.

 

Eventually, most of the ideas for SPLINT filtered down to P-Machinery 2.0, which is still in development--slowly but surely.

 

That's one. Then there's Tim in the INTV-Prog list that started working on a C compiler for the Intellivision. Joe and I were hoping to work that compiler into SPLINT.

 

It is at a slow pace, but these things will happen. It is my goal to provide some sort of platform to make the Intellivision more attractive and accessible to the casual programmer. I may not succeed, but I'm sure others will come that will do.

 

-dZ.

Edited June 29, 2012 by DZ-Jay

[GroovyBee]

Then there's Tim in the INTV-Prog list that started working on a C compiler for the Intellivision.

 

GCC was recently targeted at the TI99 so I see no reason why it couldn't be targeted at the Inty.

[+DZ-Jay]

Then there's Tim in the INTV-Prog list that started working on a C compiler for the Intellivision.

 

GCC was recently targeted at the TI99 so I see no reason why it couldn't be targeted at the Inty.

 

It's not a matter of making a compiler--that's really not a big deal nowadays. It's a matter of making it practical. The Intellivision hardware is so limited and specialized, that effectively managing data structures and system resources is not easy to do with a general compiler.

 

We're not talking a compiler for a general purpose micro-computer, that allows you to make "Hello World" and simple text-based, interactive programs. We're talking about making video games, which require processing optimized for speed and clever use of hardware resources.

 

If you need to fight with your language and compiler in order to get it to do something practical, say like manipulating memory structures directly using pointer arithmetic, or coercing the compiler to use a specific register for an operation in order to optimize the execution path; then what is the use of a high-level language gaining you?

 

You can solve this by creating an entire framework consisting of small functions that have been specialized for each individual task, wrap them up as language statements, and have the compiler generate just a bunch of calls to this library. Sort of like what the old extended BASIC interpreters did back in the micro-computer days. This was also the approach I wanted to take with SPLINT.

 

You can then use C or any language you like to call this library, but then that would be the easy part. The underlying framework of specialized routines to support and manage the hardware resources effectively, is still a rather large task.

 

-dZ.

[GroovyBee]

It's not a matter of making a compiler--that's really not a big deal nowadays. It's a matter of making it practical. The Intellivision hardware is so limited and specialized, that effectively managing data structures and system resources is not easy to do with a general compiler.

 

Plenty of people write code on the retro 8 bitters in "C", myself included on the 7800. Although my "C" code links to a games development library written in assembler for handling sprites, joystick, sound, palette etc.

 

GCC on the TI99 is interesting due to the fact that unless you use VDP memory it only has 256 bytes of scratch pad RAM with a 16 bit CPU. If you can get GCC to produce assembly for that architecture then the Inty should be possible too.

 

We're not talking a compiler for a general purpose micro-computer, that allows you to make "Hello World" and simple text-based, interactive programs. We're talking about making video games, which require processing optimized for speed and clever use of hardware resources.

 

Writing video games is just like writing embedded code for any modern microcontroller. You make the best use of the languages and hardware available to you. If "C" is good enough to solve your problems thats all you need. If you need more speed then assembler will do it or maybe a mix of both. Not all game styles can be coded in "C" but many can.

 

If you need to fight with your language and compiler in order to get it to do something practical, say like manipulating memory structures directly using pointer arithmetic, or coercing the compiler to use a specific register for an operation in order to optimize the execution path; then what is the use of a high-level language gaining you?

 

Fighting with the compiler/assembler has always happened in the games programming and embedded worlds. Its par for the course in coaxing the hardware to do what you want it to do. Many non standard features exist in compilers for microcontrollers. I don't see a problem going down that route to support the Inty.

[+DZ-Jay]

It's not a matter of making a compiler--that's really not a big deal nowadays. It's a matter of making it practical. The Intellivision hardware is so limited and specialized, that effectively managing data structures and system resources is not easy to do with a general compiler.

 

Plenty of people write code on the retro 8 bitters in "C", myself included on the 7800. Although my "C" code links to a games development library written in assembler for handling sprites, joystick, sound, palette etc.

 

But that's the essence of my point: no such libraries exist for the Intellivision. I think that's the most important (and hard) part of the process. Why don't we concentrate on having that abstraction first? The compiler then would just be icing on that cake.

 

Writing video games is just like writing embedded code for any modern microcontroller. You make the best use of the languages and hardware available to you. If "C" is good enough to solve your problems thats all you need. If you need more speed then assembler will do it or maybe a mix of both. Not all game styles can be coded in "C" but many can.

 

You are right, but as I mentioned above (and as you suggested) the compiler only brings you half-way. It would be a very trivial game that does not come across the intricacies of the STIC, or have to deal with the limited, timed access to it or to the GRAM bus.

 

Fighting with the compiler/assembler has always happened in the games programming and embedded worlds. Its par for the course in coaxing the hardware to do what you want it to do. Many non standard features exist in compilers for microcontrollers. I don't see a problem going down that route to support the Inty.

 

I don't see a problem either, and I would welcome such effort. I would gladly aid in what I can. I just think that starting with the compiler is not the most effective way to get there, because it would be of very limited profit for Intellivision games, at least. This is especially true when considering that any such effort would come from hobbyists, which by definition have a limited attention span and time.

 

Now, granted, I'm very inexperience, so my model may be atypical, but most of my effort while making a game goes in wrangling with the hardware, not the "game logic." If I still need to twist the language and write low-level code for that, my job is not made much easier by using the compiler.

 

So I'm faced with a question: do I invest the time in constructing a C compiler that will ease the already easier parts of my development process, or do I invest it in abstracting and modeling that real hard parts? I've personally chosen the latter, but your mileage may vary.

 

-dZ.

[+DZ-Jay]

GroovyBee,

 

I see that we are mostly saying the same thing from two different angles. You seem to be suggesting a compiler with a library, or special provisions for the Intellivision hardware. I am suggesting the library first and then the compiler. Since time and effort available is limited, the whole enchilada may be too ambitious a goal for many.

 

My idea is that if a comprehensive library is produced, it can be used from low-level assembly and it can be wrapped with macros that get you closer to a higher level. I am of the mind that the most important part is encapsulating the complexity, not necessarily the syntax, and providing a simple mental model that allows the programmer to be more productive.

 

Then, if a compiler is produced, it can also take advantage of that library and ease the process even more. The library, however, has the potential to aid any current game developer, since they already work in Assembly. The compiler would lower the barriers to entry, and attract more people. Both are goals I am pursuing, but I put emphasis in easing my own development first.

 

-dZ.

Edited June 29, 2012 by DZ-Jay

[GroovyBee]

But that's the essence of my point: no such libraries exist for the Intellivision. I think that's the most important (and hard) part of the process. Why don't we concentrate on having that abstraction first? The compiler then would just be icing on that cake.

 

Personally I think you need to do both at once. You need a good scheme for parameter passing to/from functions. If you don't get that right upfront you'll end up doing quite a bit of recoding down the line.

 

You are right, but as I mentioned above (and as you suggested) the compiler only brings you half-way. It would be a very trivial game that does not come across the intricacies of the STIC, or have to deal with the limited, timed access to it or to the GRAM bus.

 

People code in "C" on the NES which has similar access to hardware constraints. To code interrupt handlers in "C" you normally have a workaround in the compiler or you put your own assembly language code wrapper around the function called to save and restore any registers used.

 

I don't see a problem either, and I would welcome such effort. I would gladly aid in what I can. I just think that starting with the compiler is not the most effective way to get there, because it would be of very limited profit for Intellivision games, at least. This is especially true when considering that any such effort would come from hobbyists, which by definition have a limited attention span and time.

 

Starting with the compiler gets you a long way down the road. You can then write many library style functions in it and use them as a "get you going" approach. Over time, those exact same functions can be replaced with speedier and tighter assembly language versions.

 

Now, granted, I'm very inexperience, so my model may be atypical, but most of my effort while making a game goes in wrangling with the hardware, not the "game logic." If I still need to twist the language and write low-level code for that, my job is not made much easier by using the compiler.

 

It boils down to the game at hand. If you need speed use assembler, if not use "C".

[GroovyBee]

I see that we are mostly saying the same thing from two different angles. You seem to be suggesting a compiler with a library, or special provisions for the Intellivision hardware. I am suggesting the library first and then the compiler. Since time and effort available is limited, the whole enchilada may be too ambitious a goal for many.

 

Compiler and library at the same time .

 

My idea is that if a comprehensive library is produced, it can be used from low-level assembly and it can be wrapped with macros that get you closer to a higher level. I am of the mind that the most important part is encapsulating the complexity, not necessarily the syntax, and providing a simple mental model that allows the programmer to be more productive.

 

Encapsulating too much can cause you problems down the line. The first version of my 7800 games library enabled me to get a game out. When it came to the games after that I had to rethink the original approach I took to display lists and screen/sprite handling because I was running out of video cycles (the CPU on the 7800 is halted why the video chip handles the display list).

 

Some of the original helper functions in my games library were written in "C". When I needed to gain ROM space back those same functions were recoded in assembler. For normal game development in "C" the functions I use from the standard "C" library are malloc, memset and memcpy everything else is in the hardware specific games library. There are also some "internal" routines used by CC65 which you need to use for parameter passing but the high level code is prevented from accessing them.

 

Then, if a compiler is produced, it can also take advantage of that library and ease the process even more. The library, however, has the potential to aid any current game developer, since they already work in Assembly. The compiler would lower the barriers to entry, and attract more people. Both are goals I am pursuing, but I put emphasis in easing my own development first.

 

If you want to make the entry point to Inty development very low you need a version of BASIC. However, there is no real reason why the Inty version of BASIC couldn't be a modern implementation.

 

Ideally you need a compiler, assembler and linker package so you you don't end up with one massive file with everything in.

[+DZ-Jay]

Encapsulating too much can cause you problems down the line. The first version of my 7800 games library enabled me to get a game out. When it came to the games after that I had to rethink the original approach I took to display lists and screen/sprite handling because I was running out of video cycles (the CPU on the 7800 is halted why the video chip handles the display list).

 

Some of the original helper functions in my games library were written in "C". When I needed to gain ROM space back those same functions were recoded in assembler. For normal game development in "C" the functions I use from the standard "C" library are malloc, memset and memcpy everything else is in the hardware specific games library. There are also some "internal" routines used by CC65 which you need to use for parameter passing but the high level code is prevented from accessing them.

 

Acknowledged. This is why I am planning my framework library with the experience of one-and-a-half games already under my belt. P-Machinery was rather limited because of lack of scope, and the Carol engine had to be re-written several times as I came across similar limitations that you mentioned, based on some short-sighted decisions made without much experience.

 

I agree: compiler and library simultaneously is best. That's what SPLINT and SPLINTer are supposed to be--if I ever get there.

 

P-Machinery will remain as a simpler framework in Assembly, for some games.

 

If you want to make the entry point to Inty development very low you need a version of BASIC. However, there is no real reason why the Inty version of BASIC couldn't be a modern implementation.

 

I don't aim to lower the barrier much too low. I'd be happy to enable at least some of those programmers that find INTV-Prog by chance, and come with so much energy and enthusiasm for making a game, to actually complete one without the frustration of having to:

• learn Assembly and
  
• learn the terse and intricate hardware and
  
• learn the basic concepts of making a game and
  
• fight and wrestle with the resources to get the most basic things done and
  
• find the time and motivation to do all of it.
  

Any three of those is hard enough, all five is the cause of many arrested developments. After a few struggles, most of them quit.

 

I don't think the language necessarily has to be BASIC, but something equally accessible. I'd prefer a sub-set of C because of its expressiveness. In any case, it would be a modern implementation; no line numbers, or crude variables.

 

Ideally you need a compiler, assembler and linker package so you you don't end up with one massive file with everything in.

 

Agreed. Although I must say that Joe's assembler has a rather powerful pre-processor and it goes a long way into providing conditional assemblage without the need of a linker. All that can be abstracted behind macros, which can be made to match (to some degree) the custom language's syntax conventions.

 

(By the way, Carol is comprised of over 100 individual files, plus the SDK-1600 libraries it uses. There's never a real need to have everything on a single file. The final executable must be, simply because of the target platform.)

 

-dZ.

[+DZ-Jay]

Lest anybody gets the impression that I am this wonderfully talented game and platform designer, offering great tools for programmers, I will repeat that these are merely ideas in my head, and that I am new to most of this. Carol is my very first game, and it is not such a complex masterpiece as it may sound, and many things were compromised due to inexperience. It is a rather crude and simple game (with some rather nice animations, though! .

 

That said, I do plan to follow through, and I believe I can make a dent in the inherent complexity of Intellivision programming, in order to lower the barriers to entry and ease the development of some types of games at least.

 

-dZ.

[GroovyBee]

I don't think the language necessarily has to be BASIC, but something equally accessible. I'd prefer a sub-set of C because of its expressiveness. In any case, it would be a modern implementation; no line numbers, or crude variables.

 

True! If you have support for 8 and 16 bit wide variables (and simple arrays), +-/* operators, logical operators, for/next and do/while loops (and nested loops), if/then/else, the equivalent of switch/case or on goto, subroutines and data statements you can go quite a long way.

[+Gemintronic]

I think a programming language should get out of the way. No forced brackets { } No line numbers. Prototyping functions is lame as well. That being said I have no problem with declaring variables or using include statements to add libraries.

 

On the other hand leaving the language raw and stupidly rigid but giving it a flexible rapid application development environment is another way to go.

[GroovyBee]

No forced brackets { }

 

How do you propose to handle conditional multi-line statements? Appending something like ':' on each line is possible but in my mind its just easier to open a pair of curly brackets, put in what you need and then close them.