What type of Game maker would you like for your Atari ?

[popmilo]

I'm in starting phase of making an engine/game maker for 8-bit Ataris and would like to hear your thoughts.

There are couple of routes it could take and I don't won't to make something no one would use

 

Please answer the poll if topic interests you and you think you have a game in you that's just waiting to come out.

 

Notes:

- Plan is to make PC version first (Win,Linux, Mac) and later maybe native 8-bit version if there's interest in it. You write scripts, edit sprites, tiles, map, sfx, music on PC. Press a key and emulator starts your game.

- Scrolling is tougher to make so first version will be single screens. If people ask for scrolling we'll see what can be done.

- Most important question for me is if there are more coders or users interested in something like this. Game makers like Shoot'm'up construction set on C64 or AGD on Spectrum have almost no scripting capabilities and are limited to a certain types of games. AGD is better as it allows more freedom but still something better for coders exists. Good example is Pico 8 "Fantasy console". It's basically a simple 128x128x16 colors graphis engine with support for sprites, sound fx, music and player input. What makes it great is scripting based on Lua language. So you can make any kind of game you can stick inside memory limitations.

- Graphics engine will be simple and probably slow at first with more graphics modes, sprites and speed later.

 

ps. Here is a good article on Pico 8:

http://www.indieretronews.com/2015/10/pico-8-8-bit-fantasy-console-from.html

 

Thanks !

Vladimir.

[José Pereira]

Maybe at the first option people can choose what's the mode they want to use: CHARMODE or BITMAP.

 

Then they will choose Hi-res (320x), Mid-res (160x) or Low-Res (80x).

(or not have this option and after choosing Charmode or Bitmap you'll choose the GR. mode:

-> If Char mode: GRs. 0, 1, 2, 12 and 15;

-> If Bitmap mode: GRs. 7 and 15;

-> Maybe best to not include low-res 4x1 GTIA modes on a first release?)

 

Then set the width of the game playing area (32, 40 or 48Bytes) and how much tall, how many screens map [x,y], next define the chars gfxs, next tiles (choose tiles sizes) and build them to end with place them for each screen.

At the end the program will join them in memory and build a game map (first A8 file could have option to use cursor keys or joystick to move across and see all the level game screens)

 

Define main screen PFs colours and if wanted where's to place the DLIs and what colours and their values will change.

 

Next define PMGs and what modes:

-> priority mode;

-> single, double or quadruple widhts per each;

-> single or double scanline;

-> 5th Player or not mode ;

-> multicolour mode or not;

-> choose wich colour per each;

 

Next do the frames for eachone...

 

Possibility to build soft sprites, have shots (by chars moving/animation, software sprites, PMGs maybe Missiles support).

 

After this the animations.

It would be good to have possibility to have PMGs only, PMGs for our player (maybe also a 2players game support?) and soft sprites for the enemys, mixing the two,...

 

Hey, and at least in a future release I want it to have Interlerleaved Charsets option !...

 

 

P.s.- To simplify I will suggest that the panel/status are would be separate in a single different charset/font and GR. mode possible that you do its chars, choose its (x,y) size, if at top or bottom of the playing area, colours, increment/decrement lifes and scores or whatever else needed...

And again the same in a different charset/font and GR. mode, colours that you can build the title screens with the credits (you can have here a 'mandatory' message placed at the bottom saying: "DONE WITH POPMILO'S A8 GAME MAKER" or something similar...) and hi-scores screens.

 

Yeah, you're only starting the pain !...

Edited November 1, 2015 by José Pereira

[José Pereira]

EDIT: My previous post was with static game in mind but it can also have that options for a scrolling one.

If scrolling supported then STATIC or SCROLLING will then be the very first option and if scrolling then next choose if is a horizontal or a vertical one.

Edited November 1, 2015 by José Pereira

[potatohead]

The most successful game maker software I've seen over the years happens to be Batari Basic. No Joke. A ton of games were created with it. A bunch of those were fun too.

 

Why?

 

Because it was super easy, and it didn't offer every option in the world. Part of that has to do with the limitations of the VCS, and another part of that has to do with the simple language, which boiled everything down to a few basics people could work with. And it was fast, basically compiling to useful, clear 6502 assembly. That one could stuff things inline with the same relative ease sure didn't hurt.

 

The computers obviously offer a lot more capability.

 

But do they have to? Or can it be exposed in layers as we saw with both the Batari VCS and 7800 projects doing?

 

A very simple tool like Batari Basic might have a lot of legs, and when coupled with an IDE? Could be sweet.

 

It's worth some thought. Maybe center the minimum viable game maker in on a genre or two that you would like to see. Or maybe, expand on what Batari Basic does, given what a computer can do, and give people more of the super easy options to work with and see what they do.

 

One of the more fun computer games was "Pitfall II" and it's a straight up expansion of what the VCS could do, just bigger, more rooms, etc...

 

If it were me, I would add dead simple controller support. What would people do with the trac ball, paddles, etc... and some simple way to get that stuff on screen?

 

Another thought is there are really fun games and there are really technical games. Sometimes we see one that is both, and expectations always run toward both too.

 

But, fun games are fun. People play them. And people want to play new ones too.

 

One other thing. Mostly ordinary people made a lot of those games. Some end up on carts! And were fun. Totally worth the whole thing happening, IMHO. Frankly, there was very little to do with Batari Basic besides make games. The VCS doesn't offer up enough capability. Maybe center in on this aspect of the computers. Incorporate some tech goodies, but keep it lean and mean, game focused. So they write a program, it compiles right into a disk image, runs the emulator, and there they are. Maybe even start with a 16K cart, and all that nice RAM...

 

See the Batari Basic for the 7800? Look at what people do! It's cool, and that one offers up more than the VCS does, but still less than the computers do in some ways. It does more in other ways. But the core of it is ordinary people, likely those who can do some programming, or who want to understand and have some time, can get in there and monkey see, monkey do on the code. Once they get a moving thing, they are off to the races! Learning and doing.

 

A lot of projects get sucked into "beating the C64" or making use of lots of technically challenging things all at once. And that's fine, because when they make it through to the other side, we get a pretty awesome thing. The more the merrier.

 

But, ordinary people might just have some great ideas and they won't need much to make those ideas a reality.

 

.my .02

Edited November 1, 2015 by potatohead

[potatohead]

And this is not to take away from the excellent WUSDN project. I'm tinkering with it now on a couple of old platforms. It's pretty slick. But it's also for people who really can make a time commit and or who really know some stuff.

 

What I'm getting at is just enabling development. The more the merrier.

 

And this may be contrary to your vision. That's fine. Just tossing some observations and thoughts out there.

[popmilo]

Thanks for votes and comments!

 

Batari Basic is one of the reasons why I want to code this

Maybe I'm wrong and memory deceives me, but once I even asked coder of BB if it could be converted to 8bit Atari computers and response was that hardware is too different from 2600. Anyway, I'm doing this as a learning experience in writing compilers and cross-platform applications so want to do it 'my way'

 

All my A8 software is written using WUSDN so that one is also one of my inspirations. As you said it's for coders. Yes it has some graphics tools and handy tools but you can't use it if you're not 100% into asm coding.

 

Potatohead:

A lot of projects get sucked into "beating the C64" or making use of lots of technically challenging things all at once. And that's fine, because when they make it through to the other side, we get a pretty awesome thing. The more the merrier.

But, ordinary people might just have some great ideas and they won't need much to make those ideas a reality.

Agreed 100%. I've realized that most of my years long unfinished projects suffer from the same thing. I've fallen into trap of making something 'better than ever' and in the mean time thousands of great game ideas that would work in text mode never get made.

 

Jose:

-> Maybe best to not include low-res 4x1 GTIA modes on a first release?)

And just because of what I wrote about Potatohead comment -> I'm going to start with simple 4x2 pixels, 9 colors, 80x96 resolution

 

No PMs used (maybe for player sprite if Jose twists my arm ).

Any pixel any color, simple software sprites, tile graphics, probably slower than 50fps, RMT based sfx and music, 4 directions and one button joystick input and simple script language with only simplest math, if-then, for-do, function commands...

 

This is example of type of games I'm aiming for in the first run:

Stories at the dawn:

 

Celeste:

 

Simple graphics, games mostly going on inside mind of players

Imagine those shiny single pixels as spikes, those black surfaces as darks pools of deadly black goo, bunch of purple pixels as crazy good flower for making potions and you're getting where I want you to be

[José Pereira]

O.K. our player the only using PMGs but maybe if you also have possibility to have Missiles as shots the better.

Imagine Players vs certain PF(s) and Missiles vs PF(s) or Players hardware collision possibility and it would turn it to even simplier coding .

[potatohead]

Yes, the computers don't work the way Bb wants and needs them to. Bb depends on the frame locked type of thing necessary on the VCS.

 

But...

 

It's really hard to ignore how clean and simple Bb is in other respects. The computers do not need a display kernel and limited set of variables. All true.

 

Seems to me, that simple BASIC -> ASM layer is where the value is. I was frankly, stunned at how simple and fast Bb is. And the inline was the absolute cleanest too. I could type a few instructions and reference my variables, etc... no problem. It made getting right to the problem clean and clear. Like a multiply by 7, or shifting a sprite. A little tiny block of code nestled there among super, dead simple BASIC statements is a lot of fun, and ordinary people can do it, and can copy / paste too.

 

If it were me, I would take a really close look at that part of things. There is something for the Apple // to look at as well, and it's http://schmenk.is-a-geek.com/PLASMA.html, also able to get right to some fast, 6502 assembly in a clean way, though a level above Bb.

 

[Yautja]

Is it posible to have Double Dragon for A8?

 

- Y -

[José Pereira]

Is it posible to have Double Dragon for A8?

02

- Y -

Sure it is possible but not with this game maker if it only goes to, at first, more simplier way ...

Double Dragon and related have to be coded from scratch but P.C. utilities like Tiled that we used for X:8 and Ransack to place the tiles on the level map are the way to go.

In G2F we do the A8 data and colour information chars in the charsets/fonts and then join them in tiles that are also saved in .png to be used on Tiled.

Also in G2F we build the A8 PMGs data and their colour information and also save them in .png that again will be placed and define their positions and attributes on Tiled.

The rest is how's to get all that together, how we can build a Double Dragon on A8 and the programmers code, but better leave this to other topic...

[Heaven/TQA]

http://www.randomterrain.com/7800basic.html#controls

 

Now looking at this.... It looks interesting....

 

On A8 we have Quick language?

[a8isa1]

I completed your poll but features that would really interest me for a game maker include:

 

- linux friendly operation

- strategy/planning games. I can't hope for Civilization but that's the genre I mean.

- strategy/tactical games like Eastern Front with improved graphics and mouse/trakball interface

- graphical adventures with the best graphics modes available for A8. It's OK if the format requires HSIO and large ATRs as a minimum

- In another thread someone mentioned "Where in World is Carmen Sandiego?" was never ported to A8. Is a game builder for this genre possible?

- Gauntlet/Dark Chambers genre (scrolling and NTSC friendly play, please!)

- tools for humans (not coders) to convert pictures to usable graphics screens for game genres/formats previously mentioned.

 

[EDIT]

- support for memory models 48K/64K/Extended memory/cartridge banking]

Edited November 2, 2015 by a8isa1

[+Philsan]

As written other times, with Visual batariBasic, especially DPC+ version, you can write commercial quality games.

You have colorful backgrounds, sounds, titlescreens, 10 multicolor multiplexed sprites...

I would like something similar.

 

As already poointed out, RevEng is working on 7800basic for Atari 7800 console, based on batariBasic.

 

Meanwhile, we have Turban: you easily write and edit your Turbo-Basic program on the PC, you press Control+B, Turban makes an ATR image with all needed files and runs the program with your preferred emulator.

 

 

[snicklin]

My vote is that you create a very simple engine which can be gradually built up and up.

 

I reckon that you could do games like Gauntlet (without the scrolling) first along with platform games. Both are essentially the same thing except the platform game uses gravity.

 

You wouldn't necessarily have to code everything yourself. You could bundle a copy of Charpad 1.0 in with it and instruct the users to use that. Perhaps later you could add a tile editor of your own. Then you build it up as a toolchain which is easy to use. Later on, if you were to code different kinds of games, different tools could be bundled in.

[snicklin]

What I am trying to get at is that perhaps you don't need to write everything yourself. With other projects I've worked on, I've used Excel spreadsheets with scripts that I've written to process them.

 

What you will be providing is a framework which when rules are followed, standard output can be produced. Good luck!

[Mr SQL]

Awesome project popmilo!

 

Virtual World BASIC for the VCS may inspire you with ideas.

 

If you allow the user/coder to draw their scenes and sprites with ASCII art inline with the code you have the flexibility of writing the games on either the PC or the A8; the text file becomes a portable IDE.

 

You could build the compiler on the PC and still use the A8 to write the games if you use a text file as IDE approach, but it would be cooler to be able to also compile the games on the A8 and it's powerful enough.

 

[potatohead]

As written other times, with Visual batariBasic, especially DPC+ version, you can write commercial quality games.

You have colorful backgrounds, sounds, titlescreens, 10 multicolor multiplexed sprites...

I would like something similar.

 

As already poointed out, RevEng is working on 7800basic for Atari 7800 console, based on batariBasic.

 

Meanwhile, we have Turban: you easily write and edit your Turbo-Basic program on the PC, you press Control+B, Turban makes an ATR image with all needed files and runs the program with your preferred emulator.

 

 

 

Yes. Frankly, it may be really useful to take the Bb parser / assembler and get it running on a bigger memory space, and aware of the usual memory addresses.

 

Just that bit could be used to make some pretty great stuff!

 

That, to me, is where the magic is. Bb is a super smart, super lean way to make readable and useful assembly language programs. It is a clean mapping to 6502 with few extras.

 

To get people started, the display kernel idea could be setup with the simple screen and sprites you are envisioning popmilo.

 

I really do think a scripting language is a less effective path. Any kind of intrepeter will be slow, and also require library work. Why not let the users do that right in the native language?

 

Some work on variables and such would be needed, but not too much. It is easy to specify addresses, and a simple, larger memory layout would make a great starter environment.

 

Do the 16K ROM 48 K RAM setup, put two screens at the top of RAM, maybe locate the simple letter variables in the Zpage, and let them go from there.

 

Just that much can deliver a pretty great game, and that is what Fred observed when getting it all going on the VCS.

 

People just don't need much. In fact, the less you give them, the more focused on a game they will be.

 

Leave all the higher level stuff out. No print, etc... not needed at all.

 

Once that one is running, make an even leaner one that exposes the display list and interrupts.

 

If it were me, I would simply use the data statements and simple in line assembly for this stuff. Provide text and graphics sample modes for them, and that is it.

 

They see a simple pong game, or some other sample thing. It has a display list, labeled, interrupt routine labeled, screen RAM labeled, and the game loop just runs.

 

Here is where the magic starts...

 

Say they want to move a thing on the graphics screen. Ignore the sprites. Those get handled like they are in Bb now.

 

They can actually write a little routine that copies the data from the RAM or ROM area to the screen with simple math and a for, next loop.

 

Since that ends up being 6502 assembly, it will be fast enough to be useful. Since there is room, they get two screens as well.

 

So they get a screen to draw on, and one to display.

 

Game loop runs, they use a flipscreen command, and a clear screen one and go from there.

 

As they get it, they just inline assemble special bits and flesh the project out, but they are also sharing with others, playtesting, and most Bb users now can very easily understand and contribute too.

 

Anything else will take more code work and will require people to learn stuff. Bb more or less worked for people who only know a little, and that accomplishment is notable and it delivered too.

 

We got what? A few hundred games? Lots of people had fun programming and it is all a lot like back in the day when we would write games, then share, play, modify, etc...

 

My .02 again.

 

A lot of what you want and need is there in Bb. It just needs a little love for the computers to be useful.

Edited November 2, 2015 by potatohead

[TPA5]

An easy-to-use game creation software for the A8? Useable by those of us who aren't ultra-talented in the programming department?

 

[kiwilove]

Though I am no programmer, etc - here is my 2 cents worth.

 

You can't expect a generic gamemaker as such to be able to make full use of what the A8 hardware is capable of - of course.

You won't see a Dropzone or such like pinnacle game coming out of any gamemaker.

 

I'm not saying that an excellent gamemaker won't be useful - it could be useful for testing out whatever ideas people do have and perhaps test model different concepts etc.

 

However I hope that those programmers who are developing new projects and really are pushing the hardware to the limits - will make available whatever level designers, etc that would allow fans of their game, to perhaps create new levels for themselves. If they could release any helpful tools that were created - maybe some new level designs could turn up a year or more later on?

Imagine Crownland with new levels?

This is entirely up to the goodwill of the person(s) involved - and it is perfectly alright, if they don't open up their project for further tinkering with - for whatever reason(s).

 

Harvey

[Random Terrain]

Did somebody mention batari Basic (bB)?

 

I loved using Garry Kitchen's GameMaker on the Commodore 64:

 

mts.net/~kbagnall/commodore/gamemaker/info.html

 

garrykitchen.com/product_history/garry_kitchens_gamemaker.html

 

youtube.com/watch?v=dhQIjMsQUtA

https://www.youtube.com/watch?v=dhQIjMsQUtA

[popmilo]

Wow, thanks for voting and thoughts, looks like a poll was a good idea!

 

Here are my thoughts:

 

Poll shows overwhelming support for scrolling Platform or Shooter game in a user friendly version.

Native Atari version also looks like a popular choice.

 

Imho all mentioned tools (Visual batariBasic,7800basic,Garry Kitchen's GameMaker on the Commodore 64,Turban,Quick language etc.) don't fulfill 'user friendly' requirement.

Yes - inline assembly works great and 'looks easy' to coders but it sure isn't easy to regular Joe. AGD hits the right spot with this - stuff like events is in separate menu and all user has to do is to connect couple parts of system based on some rules. Event is triggered, one of predefined possible actions is executed. User doesn't code in text editor. It's all in making combination of existing elements.

 

Don't get me wrong, I want full control that programming language provides. But it will probably only be a bridge to user-friendly first version.

 

@Linux: As I'm almost exclusively using Linux these days so it will be supported 100%. I'm coding this in Python so it should run on Win and Mac also.

 

@Double Dragon,Strategies,Graphical Adventures,"Where in World is Carmen Sandiego?": All these look like a special cases that don't fit very well under simpler tile-based map + sprites approach. Perfectly doable in coder-friendly version where coder has full full access to all parts of engine.

 

@Gauntlet/Dark Chambers genre: It's sub genre of 'scrolling top-view shooter genre'. Think it could fit into general design.

 

@tools for humans: Already have bunch of those but 'for coders'. Need to make nice ui for them.

 

@support for memory models 48K/64K/Extended memory/cartridge banking:

First target will be 64K 800XL as that's what I have

 

I also agree with Snicklin on couple issues.

 

It does look like top-view games can be combined with platform genre (only difference is gravity). That's what Spectrum AGD is doing.

I don't want to code everything myself. This will be open source once it goes out of initial phase (when code is good enough so I don't feel embarrassed ). That means custom graphics modes, music routines, converters etc.

 

For first version I've chosen GTIA 80x96(or 80x112) mode. I'll write editor for that resolution so we won't need separate tools.

As Potatohead said "People just don't need much. In fact, the less you give them, the more focused on a game they will be."

 

Rough outlined engine is already written. Next step is to make python gui tool for editing data and producing asm files needed in compilation step. Forgot to mention that - I'm compiling scripts to asm so speed should be very close to asm.

 

@Harvey "...I hope that those programmers who are developing new projects and really are pushing the hardware to the limits - will make available whatever level designers...":

It's a noble thing to do but from personal experience - time to polish and publish level designers is once the game is done and most of the bugs are eradicated. Problem is then that coder has no more energy or motivation to continue working on it...

 

Now onto the real thing. Got to start somewhere so here it is:

- gtia 80x112x9 colors mode.

- Draw random color at random point in an infinite loop.

- Under the hood are Joystick control, IRQ routines, multiple game phases and event loops etc...

 

Imho game can be made that will use this speed to produce something fun. Will try to code some large colorful sprites next.

Thanks all for input once more!

agd.xex

[popmilo]

Here is small progress in graphics department.

 

Changed bitmap organization to one line per page (so you can skip to next line on screen with simple inc HI byte of address). This will also simplify sprite drawing and double buffering. Two widths of screen (plus some bytes for sprites that partially go outside screen) will cover less than 100bytes per page, rest can be used for sprites and tiles. Drawing tiles is then simple lda,sta operation with similar memory layout for source and destination addresses.

 

I've setup a combo of nine colors, black, dark grey, white and two of each main colors (red, green, blue).

Colors ramp nicely with dark grey and white so I think it will be good for start.

Made a simple plot routine and filled screen with color ramps plus offset that is changed in time.

 

 

You could say it looks slow, but bear in mind routine is doing two outer x,y loops, calculating color index with offset to get from ramp table, and then calling universal plot subroutine that puts pixel of any color at any x,y coordinate (0-79,0-111).

It's doing ~18200 plots per second which should be enough for simple pixel plotting based effects in a game.

 

Next step double buffering and sprites

 

[Edit] Forgot to attach xex file, here it is:

agd.xex

Edited November 5, 2015 by popmilo

[popmilo]

Double buffering done using two display lists and simple sprite drawing (no masking or shifting, just simple byte boundary lda-sta).

Again, speed is not fantastic, bear in mind it's still doing 1024 individual pixel plots.

It was just a good way to test double buffering, as one screen redraw takes more than one frame.

 

Current memory layout is two buffers next to each other. First 40 bytes of page is buffer1, bytes 40-79 belong to buffer2.

Will have to reconfigure this when scrolling is implemented (expand buffer area till byte 120 of each page to make room for NES like 'scrolling window'). Vertical scrolling should be doable with changes to LMS in dlists.

 

 

Here is a xex file:

agd.xex

 

Next:

- Shifted sprites (1 pixel horizontal movement)

- Sprite drawing anywhere on screen including partially outside screen.

 

Next-next

- Masked sprites

- Clearing old position of sprites (instead of rough clearing of larger screen area).

- Restoring background on old position of sprite.

 

Cheers!

[snicklin]

One question I have is about how this is going to be coded.

 

For example, if there is a tile routine to display tiles, this could be for 2x2 tiles, 3x3, 4x4 (etc.) tiles. Will you write the code so that it will work for these different sizes? Or will you code it so that only 4x4 (for example) can be used? Or will your program identify that you are using (for example) 3x3 tiles and therefore select the tile display routine correct for 3x3 tiles?

 

The same thing will happen for different graphics modes.

 

If you could list all of your requirements beforehand, you could ask for people for different functions/procedures.

 

i.e.

 

I want (in MADS format for example):

a) A routine to clear memory with 0 values for any individual page number. Parameters: (byte) Page number

b) A PMG draw routine: Parameters: (byte) PMGBASE, (word) location of graphic to display, (byte) pm number, (byte) pmg colour, (byte) x location, (byte) height

etc...

 

People could then submit their routines and the best ones get selected.

[popmilo]

Good questions Snicklin.

 

My first priority is to keep things simple as they can be. That's why I'm using bitmap "any pixel-any color" mode. Yeah it's blocky, PMs could be used to enhance resolution of player sprite and some enemies etc.

 

But I don't want to do that

No PMs, no DLIs, no Char mode... Reason is that I want to iron out that 'user friendly' aspect first. When "regular Joe" is able to edit couple sprites, draw some background tiles, lay them out on screen, choose type of control for player, draw some enemies, set their position and movement on screen and hit that Play button without writing a line of code - then I'll start thinking how it can be improved

 

So, for this first version my plan is to use 2x8 bytes for background tiles (4x8 pixels same as regular multicolor characters so existing ones can be used).

Sprites will probably be 4x16 bytes (8x16 pixels). Less than that would be enough for simpler objects, but wouldn't be optimal to draw larger objects by combining smaller sprites.

 

Once base engine is done, and I don't mean sprite engine but the whole make-a-game solution then we can start work on making it modular and community based fun can begin

 

ps. Maybe it's far out in the future, but I'm thinking about ways to get custom made games, graphics, music out there in the 'cloud' so anyone can pull them down and use in their own projects.