An idea for continued games development... using Amiga

[Galahad/FLT]

I agree also, the copy protection isn't going to be some super wonder mega protection, merely enough to dissuade the casual copier of the game.

As we all know, if someones determined enough, the protection will be defeated... *ahem*

[Jason_]

Any ETA on beginning this project?

[Galahad/FLT]

Need to discuss with Vairn the base spec of the emulator core, and once we have that then we can start.

We also need to agree on the onscreen 'joystick' layout, that is going to be the defining feature of the whole thing, get that right and its all good, get it wrong and it doesn't matter how great the games are if they can't be controlled with some degree of ease.

[kamelito]

Originally Posted by Galahad/FLT

Need to discuss with Vairn the base spec of the emulator core, and once we have that then we can start.

We also need to agree on the onscreen 'joystick' layout, that is going to be the defining feature of the whole thing, get that right and its all good, get it wrong and it doesn't matter how great the games are if they can't be controlled with some degree of ease.

I don't know if the Iphone touch screen is sensitive enough but to me the joystick should be handled only by rotating your thumb in all 8 directions without moving it (it stays centered to your finger). If the screen permit that, it'll be easier to move a main sprite. If you've to go back and forth its over.

Kamel

[Galahad/FLT]

Originally Posted by kamelito

I don't know if the Iphone touch screen is sensitive enough but to me the joystick should be handled only by rotating your thumb in all 8 directions without moving it (it stays centered to your finger). If the screen permit that, it'll be easier to move a main sprite. If you've to go back and forth its over.

Kamel

Exactly what I was thinking. Once the user gets used to the controls, it should be intuitive.

[Jason_]

http://www.rtype-iphone.com/

have a look here for some ideas on on-screen controls.

[Galahad/FLT]

Right, today isn't the time to be making any kind of game decisions, but its time to start getting things off the ground, so that any interested parties can join and be a part of producing a game.

I propose a simple style game at first, simple to code, simple to realise and quick to get to the market. Whilst I have no issues doing a Dungeon Master/Captive style game for Android, and I actually think they are a very good idea and would suit the platform well, I think its important to first get something quick off the ground, which then gives people the hope that a much bigger project won't likely stall and their efforts wasted.

So, ideas very much sought for our first project, and some names of people wanting to contribute.

So far we have: Me, Zetro, Vairn and Akira showing interest.

I have no issues with anyone wanting to be involved, I think anyone under the illusions our first game will be some kind of mega hit producing millions in revenue.... best leave your aspirations at the door as far as that goes for the moment

I was thinking along the lines of a very polished simple puzzle game, maybe along the lines of Deflektor by Gremlin (this is just a suggestion to get the ball rolling).

For the first game, I would suggest sticking with ECS requirements to help speed development, and then we can talk with Vairn about implementing some nice Virtual Amiga extras like being able to play proper 16bit sound within the Android environment.

So, if you have any ideas, NOW is the time to start getting them in. If you want to be involved, NOW is the time to get involved.

This isn't vapourware, this is going to happen one way or the other.

Maybe not quite Digital Illusions for a new generation, but theres no reason why it can't get to those lofty heights

If we could also have someone who can dig up what sort of average size games are on Android, what sort of setup they have, what memory requirements they have, basically as much information as possible, because if there are any parts of the emulator core that not quite upto speed (say for instance boot up times, depack times), then we need to tailor the game so it acts like other games or better.

Also are games single files on Android or are they multi file? This is all information we need chaps, so anything you can tell us is useful.

[Leffmann]

I'd just like to suggest an emulation environment with a single large block of chipmem starting at address 0, in which you load the game data before emulation starts.

This way you would have 10 megs before you hit the I/O space at $A00000, or just below 12 megs before you hit the CIAB at $BFD000, and all the game data would be ready for use without having to f.ex shove bitmap images around in memory before showing them, and could even be modified during runtime if needed.

Now you could deploy your game like something akin to a console ROM image and have your game assert the entire environment and avoid any sort of disk I/O, hardware checks or code dispatch.

[kamelito]

Originally Posted by Jason_

http://www.rtype-iphone.com/

have a look here for some ideas on on-screen controls.

to me the virtual joystick should not hide the playing area, so if your in portrait or landscape mode, the controls should have their place outside the playing area. its very frustrating to hide what is on screen.
Don't know if thumb size matter, but a setting be it manual or auto to configure height and width of the thumb could maybe improve game controls.

Kamel

[BippyM]

Puzznic or pipemania.. I have been waiting for those but intuitive, fast and smooth

[Npl]

Just curious, what language are you planning to write those games?
if its asm then I understand your way of running it on an Emulator, though Im not too sure it will fly (at least on the Phone-side) with the hefty restriction of an Amiga compatibility. The Phone games are cheap, but pretty much any game has some features that would put it above Amiga-level, be it higher resolution, scaling/rotating or stuff onscreen. And once you need to add and maintain hacks into the emulator for accessing native feature this could get a time-intense labor quickly

if its C then a better approach would be just to convert your stuff to java once you`re done. big parts could be made reusable on both sides (anything except game-logic) for further games, the rest shouldn't be too big and easy to port. (The C-code would allow you to glue into the C-libraries from Appstore and PSN aswell)

Originally Posted by Galahad/FLT

I agree also, the copy protection isn't going to be some super wonder mega protection, merely enough to dissuade the casual copier of the game.

As we all know, if someones determined enough, the protection will be defeated... *ahem*

...and this someone is desperately waiting for new Amiga games to crack?

[Galahad/FLT]

Originally Posted by Npl

Just curious, what language are you planning to write those games?
if its asm then I understand your way of running it on an Emulator, though Im not too sure it will fly (at least on the Phone-side) with the hefty restriction of an Amiga compatibility. The Phone games are cheap, but pretty much any game has some features that would put it above Amiga-level, be it higher resolution, scaling/rotating or stuff onscreen. And once you need to add and maintain hacks into the emulator for accessing native feature this could get a time-intense labor quickly

if its C then a better approach would be just to convert your stuff to java once you`re done. big parts could be made reusable on both sides (anything except game-logic) for further games, the rest shouldn't be too big and easy to port. (The C-code would allow you to glue into the C-libraries from Appstore and PSN aswell)

...and this someone is desperately waiting for new Amiga games to crack?

As stated its going to be 68000 ASM using a Virtual Machine Emulator Core to run the Amiga code transparently.

Adding lots of flashy extras to compete with some of the bigger titles really isn't a problem.

For instance, transparent MP3 playback can be done with modifications to the emu core when certain "extra" custom registers are set on the Amiga side to tell the core to play an MP3, and other graphics modes with more colours are also easily done.

[Npl]

Originally Posted by Galahad/FLT

As stated its going to be 68000 ASM using a Virtual Machine Emulator Core to run the Amiga code transparently.

Adding lots of flashy extras to compete with some of the bigger titles really isn't a problem.

For instance, transparent MP3 playback can be done with modifications to the emu core when certain "extra" custom registers are set on the Amiga side to tell the core to play an MP3, and other graphics modes with more colours are also easily done.

Mustve missed the bit where you stated you`d write in asm directly.

My point is that when adding to the emu and maintaining those additional features, then you could begin starting to think of it as a whole framework that could be turned into a (native) multiplatform one. Still a moot point as this aint helping much if your code is asm.

regarding graphics and colours, if you hit the chipset directly then you can run into troubles (setting colours in AGA is ugly enough already). if you dont (and use RTG or something similar) then you probably gonna write two versions/cores, one for running fast on Amiga-Hardware and one for the Emu?
Well, heres my thinking of a cross-plattform framework again - since you aleady have the overhead of doing "hardware-parts" twice.
Somewhere inbetween could be a compromise of only emulating the 68k since all the Chipset magic wont help you there and you get enough performance using libraries.

I dont want to sound overly negative, I wish you best of luck and would like a few new Miggy games. Just that starting something like this, using effectively multiple targets using assembler seems like asking for trouble.

[wXR]

Galahad what games did you work on in the past? Anything we'd know?

[TCD]

Originally Posted by wXR

Galahad what games did you work on in the past? Anything we'd know?

http://hol.abime.net/hol_search.php?N_ref_artist=337

[Galahad/FLT]

Originally Posted by Npl

Mustve missed the bit where you stated you`d write in asm directly.

My point is that when adding to the emu and maintaining those additional features, then you could begin starting to think of it as a whole framework that could be turned into a (native) multiplatform one. Still a moot point as this aint helping much if your code is asm.

regarding graphics and colours, if you hit the chipset directly then you can run into troubles (setting colours in AGA is ugly enough already). if you dont (and use RTG or something similar) then you probably gonna write two versions/cores, one for running fast on Amiga-Hardware and one for the Emu?
Well, heres my thinking of a cross-plattform framework again - since you aleady have the overhead of doing "hardware-parts" twice.
Somewhere inbetween could be a compromise of only emulating the 68k since all the Chipset magic wont help you there and you get enough performance using libraries.

I dont want to sound overly negative, I wish you best of luck and would like a few new Miggy games. Just that starting something like this, using effectively multiple targets using assembler seems like asking for trouble.

Writing in ASM is irrelevant as the emulator core handles the conversion, its transparent.

The priority is Android first, Amiga second. There has to be some kind of success first on Android to warrant bothering with the Amiga version.

At the moment, Android is the only concern as far as mobile devices go, because they are the least stringent on what you can or cannot do because they obviously want to hit the Apple Appstore by having more apps for Android.

I also think you underestimate the ability of the Amiga to deliver quick and nice looking graphics on mobile devices. Whether its ECS, AGA or RTG is utterly irrelevant, no one of those modes is more difficult to do than the other, at the moment its get something working so that other people can get interested and be a part of it, and then worry about the fluffy stuff later IF it proves to be a success.

[Jason_]

Galahad: Glad to see you're determined in this project. I agree that it is a very good idea, and has the potential to grow to other platforms besides the Android. Be sure to put up a web page/blog at some point to show progress!

[Codetapper]

Much as the sound of getting some new Amiga games sounds, I have to agree with Npl and think this idea seems rather mad.

I admit to not knowing the first thing about Android etc, but surely to draw an object on the screen at a specific spot is a pretty easy thing to do with a single call in a high level language, vs all the fluffing about with setting up the blitter in ASM. Then the emulated environment has to undo all the blitter work to draw the object. Most likely it'd be more than 10 times slower!

As an example, in DelphiX you can draw an object from a huge picture onto the screen with full clipping, alpha channels, transparency etc with one line of code.

It would surely be 10 to 100 times quicker to develop any new title in a native language with a library for each device more like what Npl has suggested.

Super Sprint was supposed to have been a simple game to write and nothing has been heard of that project, and all the graphics and game design were already done. I just don't see how new games could be written when ASM takes so long and you're considering a new game where you have to design it too!

I'll probably get flamed for this post but knowing that teams of guys took 6-9 months to create games back in the late 80's/90's in ASM, it seems an unusual way to approach things nowadays.

[kamelito]

Originally Posted by Codetapper

Much as the sound of getting some new Amiga games sounds, I have to agree with Npl and think this idea seems rather mad.

I admit to not knowing the first thing about Android etc, but surely to draw an object on the screen at a specific spot is a pretty easy thing to do with a single call in a high level language, vs all the fluffing about with setting up the blitter in ASM. Then the emulated environment has to undo all the blitter work to draw the object. Most likely it'd be more than 10 times slower!

As an example, in DelphiX you can draw an object from a huge picture onto the screen with full clipping, alpha channels, transparency etc with one line of code.

It would surely be 10 to 100 times quicker to develop any new title in a native language with a library for each device more like what Npl has suggested.

Super Sprint was supposed to have been a simple game to write and nothing has been heard of that project, and all the graphics and game design were already done. I just don't see how new games could be written when ASM takes so long and you're considering a new game where you have to design it too!

I'll probably get flamed for this post but knowing that teams of guys took 6-9 months to create games back in the late 80's/90's in ASM, it seems an unusual way to approach things nowadays.

He said he didn't want to learn a new language, same is true with new API.
He also said that he's more productive in ASM/Amiga coding.
Well if unusual mean being creative again, then I'm for it, the advantage is that it could be "ported" back to the Amiga.
As for Super Sprint I also wanted to port it but never found real motivation, so now Galahad found it, let's him and others involved do it their way.

Kamel

[prowler]

I'm with kamelito on this!

Go, Galahad, go!