News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

How would you attempt a CPC game creator?

Started by Trebmint, 09:05, 12 July 10

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

arnoldemu

#25
Quote from: Trebmint on 09:28, 21 July 10

Yes I have thought about this, but I don't want to make a CPC game creator that makes spectrum ports. Although code for game control and play wise could be virtually identical, the engine code would have to have similar specs and that would drag the CPC down I feel.

Due to the nature of how I'm going about this I expect that cross compilation is a probable outcome, but that the same project on a different machine will look very different.
will it support PCW too? ;)

EDIT: I support your idea to make it easier for people to develop new games for cpc, and to try and support those where the platform is new to them, or they are not so familiar with writing games.

I hope your idea comes to fruition, but could you not have written a new game in the time that you write this and then publish commented source that others can learn from, even giving away a library of functions for them to use?
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Trebmint

Quote from: arnoldemu on 09:48, 22 July 10
will it support PCW too? ;)

EDIT: I support your idea to make it easier for people to develop new games for cpc, and to try and support those where the platform is new to them, or they are not so familiar with writing games.

I hope your idea comes to fruition, but could you not have written a new game in the time that you write this and then publish commented source that others can learn from, even giving away a library of functions for them to use?

I guess this if finished will be a very Marmite project for many, and you'll either love it or hate it. Personally I think its worthwhile since nothing like this exists on the CPC, and opening up a way for non coders to design a game is surely beneficial. Sharing of resources and code is the key I hope to getting people to adopt and use the project, I'm even thinking of having purely a web based storage system so finalised graphics and code are available to everyone. Like an ultimate community resource.

I see no reason why a PCW version would not be achievable, along with MSX, Speccy, Enterprise, Sam etc. But this would depend on the communities to recode some of the core plugins

Ynot.zer0

once the user has 'finished' their game (I put that in quotes as they are never truly finished  8) ) it'd be good if they could then have a 'view source' feature.
So that they highlight something and then could learn what piece of background source code did what.


Personally, I would find that extremely useful, it'd also help make that transition between seeing the game from the gamer perspective and then from the developer side of the table (a bit like the wizard in the 'wizard of oz').


If you do cobble something together, I'm more than happy to be an alpha/beta tester for you...

Trebmint

Quote from: ynot.zer0 on 12:02, 22 July 10
once the user has 'finished' their game (I put that in quotes as they are never truly finished  8) ) it'd be good if they could then have a 'view source' feature.
So that they highlight something and then could learn what piece of background source code did what.


Personally, I would find that extremely useful, it'd also help make that transition between seeing the game from the gamer perspective and then from the developer side of the table (a bit like the wizard in the 'wizard of oz').


If you do cobble something together, I'm more than happy to be an alpha/beta tester for you...

Well the idea is to base everything on modules so coders build small tiny bits of code, and these are then available for all. So I might add a "manic miner type" player control which would then be useable and customisable by everyone else. Since the backbone of the whole creator is an assembler, the entire source code will be entirely viewable by anyone compiling the project. The creator simple organises all the used modules and data into a .z80 file and assembles it.

Well thats what I hope anyway

steve

Maybe all these code modules could be added to basic as |RSX's, I remember a small type-in that would compile a basic program, I don't know if this actually worked but if it did then it would make it easier to write fast programs.

TFM

Quote from: Executioner on 03:09, 19 July 10
I find it quite amusing that anyone would consider using a C compiler on the CPC, yet they wouldn't consider using any OO constructs in assembler.

That's making me laughing  :D  OO in assembler! Great idea! :D  Instead of creating OO constructs, you rather should just do it in the most efficient way. That seperates the wise guy from the book-smart guy: The book-smart guy loves constructs, rules, 100% of order in the code, huge comments, huge handbooks, every routine ... oh they call it function or whatever ;-) ... every function has it's own color and so on....    While the wise guy just make the perfect code without caring about anything of the previously mentioned bullshit! Can you hear me?




For a good game creator three things are needed:

1. The Creatror itself (if running on an PC) can be coded in any way, as long as it produces the desired result!!! (If the creator shall run on a real CPC, see 2.)

2. The finished "game", means the product of the game-creator, must be efficient in using the ressources of the CPC. The idea of using small modules, like Trebmint mentioned, is good. I would suggest to use a set of small routines, the more - the better (flexibility!)

3. Do it for ONE target platform. Any kind of mutilplatform approach is always shrinking the features available for a particular target system. Even if there is no intention for it, it happens.

And don't forget, that this project should be doable, so don't let it grow tooooo big, else it will be never finished. (Ok, if you own a CPC company go for it ;-)
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

Executioner

Quote from: TFM/FS on 16:18, 22 July 10
That seperates the wise guy from the book-smart guy: The book-smart guy loves constructs, rules, 100% of order in the code, huge comments, huge handbooks, every routine ... oh they call it function or whatever ;-) ... every function has it's own color and so on....    While the wise guy just make the perfect code without caring about anything of the previously mentioned bullshit! Can you hear me?

Almost all of my Z80 source code is available for download. If you think I write in-efficient code, please feel free to go through it and point out all the bad bits. I'd be happy to do the same for FutureOS, after all, it's got a lot of functionality for 64K, even a clock.

Sykobee (Briggsy)

I remember using GAC and Sprites Alive! The latter very usefully had a compiler to generate binaries of your BASIC programs that used the Sprites Alive! RSXs.


I also remember the ACU series of articles called Roland Takes A Running Jump (last article is all you need), which would serve as a basic Manic Miner type engine for a platform game designer.


I think having a PC based tile editor, sprite editor, and pre-defined game routines (the game designer would select the best routines from a library for your game settings, be it MODE 1 or 0, 8x8, 8x16, 4x8, etc sized blocks, screen size, and game type) would be best. Each game type would require its own game engine though. In the end Z80 isn't that hard with a good resource like the examples here, and a good library of "simple" routines for beginners (like printing a base 10 number from a binary number).

TFM

Quote from: Executioner on 01:40, 23 July 10
Almost all of my Z80 source code is available for download. If you think I write in-efficient code, please feel free to go through it and point out all the bad bits. I'd be happy to do the same for FutureOS, after all, it's got a lot of functionality for 64K, even a clock.

Nice! But neither I've time to improve your code, nor I will release the source code of FutureOS.

As soon as I've time I'll help you with the RTC of Winape, which still doesn't speak BCD


But we're both getting off topic here... sorry for this.

So let's come back to the game creator. What I wanted to point out before was, that two things must be seperated clearly. First the game-creator itself. Second, the created game code.
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

Trebmint

Quote from: Briggsy on 14:56, 23 July 10
I remember using GAC and Sprites Alive! The latter very usefully had a compiler to generate binaries of your BASIC programs that used the Sprites Alive! RSXs.


I also remember the ACU series of articles called Roland Takes A Running Jump (last article is all you need), which would serve as a basic Manic Miner type engine for a platform game designer.


I think having a PC based tile editor, sprite editor, and pre-defined game routines (the game designer would select the best routines from a library for your game settings, be it MODE 1 or 0, 8x8, 8x16, 4x8, etc sized blocks, screen size, and game type) would be best. Each game type would require its own game engine though. In the end Z80 isn't that hard with a good resource like the examples here, and a good library of "simple" routines for beginners (like printing a base 10 number from a binary number).

Personally I think a range of tools and utils including standardised formats, and the code to go with them should have been something the cpc community achieved years ago. Alas no. I doubt there are many budding Z80 game coders (newbies willing to learn) out there now, so perhaps this game creator concept is perhaps a good idea, in that it might not realise the cutting edge / pushing the tech type games but will be more about concentrating on gameplay and polish through simplicity of use.

Trebmint

Hi I wonder if anyone has any ideas for generating potentially large maps without eating memory. Think about 32k for map, collision & background tiles cos I'm using 128k, though am using Flip screen so thats 32k gone

The idea was to allow the user to have a large canvas so they could build a large scrolling map design or a number of single screens laid out on the canvas and shown via the x,y reference. However this means that compression of data is impossible once the level is loaded, as I would also not want to limit objects (actors) not on screen from being able to interact with scenery.

Have been contemplating combinations of Tile numbers, built into 4x4 tiles blocks etc and how best to do collisions with that.

Any ideas?

AMSDOS

If it were me who had to write a CPC Game Creator, I would make it RSX driven programs on a ROM. I think in the past Game Creators were a Suite of programs, something for the Graphics, something to make sound files (tunes or effects), the language itself which could put it all together. Be nice if you could have some sort of program which demonstrate how this game was to behave - perhaps that's the missing link in the chain for these Game Creators?  :o  A program which allows you to select what this game should be how the character should behave. Could a program in ROM allow quick access between selections and then you could tell how you want your enemies their primary function.

Just seems to me that if you wanted to take advantage of something like that, then it could possibly be better on ROM since you're telling your Amstrad you want to want to make the most of it's advantages.

Many game creator programs were mention, but no-one mentioned Pandora from Swift Software! Am I the only person who knows about it. I never owned it personally, to my knowledge it wasn't on ROM and was made available on Tape!! (or Disc for £30!). Was reviewed in AA47, I think Pat McDonald (who reviewed it) though it was okay, Sprites Alive was reviewed in AA51, I think the argument with those programs to help design Games was while they were perfectly capable of doing that, you still weren't going to be making Commercial quality software! To me it really depends on what kind of game your making, speed isn't always essential as shown in classic Sprite Alive game Space Froggy where Timing can mean the difference between life and death! Otherwise a fast game is always about code optimisation and taking advantage of what works best. :)
* Using the old Amstrad Languages :D   * with the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

Axelay

Quote from: Trebmint on 09:44, 30 July 10
Hi I wonder if anyone has any ideas for generating potentially large maps without eating memory. Think about 32k for map, collision & background tiles cos I'm using 128k, though am using Flip screen so thats 32k gone

The idea was to allow the user to have a large canvas so they could build a large scrolling map design or a number of single screens laid out on the canvas and shown via the x,y reference. However this means that compression of data is impossible once the level is loaded, as I would also not want to limit objects (actors) not on screen from being able to interact with scenery.

Have been contemplating combinations of Tile numbers, built into 4x4 tiles blocks etc and how best to do collisions with that.

Any ideas?

Do you mean 128k for a game or a creator?  If you have a game that's going to be 128k only, then it's presumably disk only too, so can't you just load off disk as often as you like, as often as Sorcery+ did if it comes to it?  That's assuming you can give your scrolling map "boundaries" within, where the player crosses an edge from time to time that gives you a chance to do the loading.

TFM

Quote from: Trebmint on 09:44, 30 July 10
Hi I wonder if anyone has any ideas for generating potentially large maps without eating memory. Think about 32k for map, collision & background tiles cos I'm using 128k, though am using Flip screen so thats 32k gone

Well, for my game engine I use 16 Bit variables. And one 16 KB block is enough - for actions games and for role play games. 7 Bit of each 16 bit variable define the background gfx for that tile and 9 bits are for attrubute (can player run over tile, is there a person, a thing, a door, etc. also other "things" can be "activated" by running over such a tile. Further it can tell if there is a moving/rotating gfx f.e. a blinking diamond or a tree moved by wind...). It turned out that this system works quite well. Oh, every tile has a size of 16 * 16 Pixel (in Mode 0).

TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

Trebmint

Quote from: TFM/FS on 02:50, 03 August 10

Well, for my game engine I use 16 Bit variables. And one 16 KB block is enough - for actions games and for role play games. 7 Bit of each 16 bit variable define the background gfx for that tile and 9 bits are for attrubute (can player run over tile, is there a person, a thing, a door, etc. also other "things" can be "activated" by running over such a tile. Further it can tell if there is a moving/rotating gfx f.e. a blinking diamond or a tree moved by wind...). It turned out that this system works quite well. Oh, every tile has a size of 16 * 16 Pixel (in Mode 0).

Do you mean that the tiles are 16x16? And that you're using 7 bits so that 128:16x16 mode 0 tiles.  So that's 16k for graphic tiles and 16k or (128x64 tile block map)

I'll build that variant into the map editor. One or two choices is probably a good idea though it will need a specific set of routines for collision and drawing. Would it be possible for me to get one of your Tile sets?

I'm still trying to finalise my system which is based on 256:8x8 mode 0 tiles (And yes I do know about Mode 1)
making meta tiles of 4x4, and perhaps having a maximum of 1024 meta tiles at 4 bytes each. Each of the 256 tiles would then have a collision map attached to it.

For other events I've gone for the route of allowing trigger zones to be defined anywhere over the map. Each trigger zone has a x,y, width, height, event number, active bit and an actor collision mask. To limit the processing I'll limit the detection either to a boundary around the player actor or visible screen. they would work in exactly the same way as a normal Actor that lacks visibility.

Each Actor can also have collision zone boxes for each sprite frame, so means you might be able to define a punch zone, a defense zone, a hit zone. Useful for fighting games.


TFM

Quote from: Trebmint on 12:51, 03 August 10
Do you mean that the tiles are 16x16? And that you're using 7 bits so that 128:16x16 mode 0 tiles.  So that's 16k for graphic tiles and 16k or (128x64 tile block map)

Yes, 128 tiles, each of 128 bytes. Makes 16 KB.

Quote from: Trebmint on 12:51, 03 August 10
I'll build that variant into the map editor. One or two choices is probably a good idea though it will need a specific set of routines for collision and drawing. Would it be possible for me to get one of your Tile sets?

Sure, just get it from our wip "Giana Sisters", the tile sets have the names "Giana x GEs", you can easiely take a look at them using GSEd. (download all that stuff from www.futureos.de)
If you like them in another format, just tell me what you need.

And yes! You're right it would be an advantage to have tiles in different size. Especially if you can use it at the same time. But this makes the "map" of a game much more complex.

Quote from: Trebmint on 12:51, 03 August 10
I'm still trying to finalise my system which is based on 256:8x8 mode 0 tiles (And yes I do know about Mode 1)
making meta tiles of 4x4, and perhaps having a maximum of 1024 meta tiles at 4 bytes each. Each of the 256 tiles would then have a collision map attached to it.

For other events I've gone for the route of allowing trigger zones to be defined anywhere over the map. Each trigger zone has a x,y, width, height, event number, active bit and an actor collision mask. To limit the processing I'll limit the detection either to a boundary around the player actor or visible screen. they would work in exactly the same way as a normal Actor that lacks visibility.

Each Actor can also have collision zone boxes for each sprite frame, so means you might be able to define a punch zone, a defense zone, a hit zone. Useful for fighting games.

About the collision zones: Great think. I do it in a similar way, but not as complex. However it's a good thing to check them only every 8. or 16. pixel and not for every move/pixel. This saves time and you can make your grid still as small as desired.

TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

jbaudrand1

Hi this is my first post here, I really hope you'll release your game creator project for cpc. As a totally newbie in programming, I started working with Batari Basic, it use a special version of visual basic, and the community try to add new plug in to  add tool for making titles, sprites editor, music editor. it still very basic, but anyone who start making a game can enjoy coding basic and easily see the result.

on CPC i'm starting with sprites alives, I've tried laser basic but even with the documentation, I'm still having problem with memory management.


arnoldemu

Quote from: jbaudrand1 on 06:13, 16 August 10
Hi this is my first post here, I really hope you'll release your game creator project for cpc. As a totally newbie in programming, I started working with Batari Basic, it use a special version of visual basic, and the community try to add new plug in to  add tool for making titles, sprites editor, music editor. it still very basic, but anyone who start making a game can enjoy coding basic and easily see the result.

on CPC i'm starting with sprites alives, I've tried laser basic but even with the documentation, I'm still having problem with memory management.
Maybe we can help you with the memory problem. There are various ways to reduce the footprint of data or to represent the data in another form that will save you ram.
I assume your using a mix of CPC basic and sprites alive? Well, I am sure we could find a way to squeeze it more for you.
Send me a private message and I will try and help where I can.

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

jbaudrand

#43
thanks for your offer,  :-[ but nothing to send yet: we try to finish our project under batari first.

and yes you're right,:I'm still using basic under cpc mixed with special functions from sprite alives, ASM is too hard to learn.

Axelay

Quote from: jbaudrand1 on 06:13, 16 August 10
on CPC i'm starting with sprites alives, I've tried laser basic but even with the documentation, I'm still having problem with memory management.

If I remember correctly, when using laser basic and the laser compiler together, there was less than 16k left for everything!  The game I made with it was so simple because of the restrictions, it's actually what spurred me on to learning assembly.  It's a shame laser basic didn't let you select from "modules" of routines so you didn't have a dirty great big overhead even if you only used one sprite printing technique and none of the scrolling routines.

jbaudrand

Axelay:  the documentation of laser said 24Ko... anyway sprite alive had missile routine and that's the kind of game I want to make for beginning.

Trebmint: just take a look at Random terrain's batari page, I think, as a totally newbie in programming, it's easy to understand http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html

maybe you can do the same with your tool?

Axelay

Quote from: jbaudrand on 19:55, 16 August 10
Axelay:  the documentation of laser said 24Ko... anyway sprite alive had missile routine and that's the kind of game I want to make for beginning.


I was also using the "Laser Compiler", for converting the basic program into machine code, which took up another 7k or so.

jbaudrand

Sorry to  bump it, hope Trebmint continue to work on this project.

AMSDOS

Executioner wrote:

I was hardly suggesting that I'd use J2ME to develop ZACK, or write a pure OO compiler, nor use C++ for that matter. I didn't even suggest using any form of memory management, simply that OO constructs would have been of great benefit to ZACK, rather than code that goes:


If it's a button then draw this else if it's a menu then draw that else if it's a scroll bar then draw something different else if it's a label then draw the text...

If it's the File menu then do this else if it's the View menu then do that....

Same old story, sorry, though I personally found OOP extremely challenging while undertaking a programming course. C was difficult enough, but C++ completely threw me out (people probably thought I was going bald!!  ??? ). But I do see the relevance where I could have been handy in Zack. My lecturer did have a reason why people were moving towards OOP, I thought it had something to do with expanding applications using fewer processes, which sort of ties in with what you said - have this and do this, this & this kind of thing.

I find it quite amusing that anyone would consider using a C compiler on the CPC, yet they wouldn't consider using any OO constructs in assembler.

As much as I don't like C, if people decide to use it then it's their choice. Strictly speaking though, nothing is going to be better than the language that the machine understands best - even with compilers you have to make compromises. Just in Locomotive BASIC alone there are heaps of tools and extension programs to generate the stuff that BASIC cannot handle. Take your favourite BASIC game for instance and soup-it-up, or better still take a BASIC game from a rival computer and make it better on the CPC!  ;D  Won't ever be as good as Assembly, but at least it could be a bit of fun!  ;D 

The language which generally gets overlooked though is Forth. It has been used very effectively for games using Z80, perhaps an efficent Game Creator could be written in Forth??  :-[  Forth (for those who don't know) was the Built-in language (as BASIC is to the CPC) for the Jupiter Ace. From memory I think(?) a Jupiter Ace only had 16k unexpanded and was expandable to 48k. True a Jupiter Ace was basically a Spectrum with Forth onboard, there's probably a few other key differences, and while the system is rare and didn't really survive the market, some Commercial Games were made utilising Forth. Of course emulators are available (Ace32) as well as the games. For a system which uses little RAM, uses a Z80A processor, it's interesting to see how well it copes. Unfortunately Forth isn't the easiest language to read or write, but if people are using C, then Forth I reckon is up there with it. The Jupiter Ace came out in 1983 and while Forth did update it's standards in '83, the Jupiter Ace uses an earlier (Forth-79 I think), though it's still an interersting language to check out.
Perhaps on ROM it would be a strong contender as an useful alternative language, or as a language on an 128k system which can give the user ample space to write something. All ideas of course!  :)
* Using the old Amstrad Languages :D   * with the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

Trebmint

Yes the Game Creator is gonna happen, but sometime next year is my guess. Changing job, house, christmas etc is all first.

One thing the creator doesnt have (or isn't planned to have) is code as such, its fully menu driven, which sounds limiting but I don't think it will be. All that stuff will be added by flexible plugins, the more of which get developed the more flexible the creator. And since plugins can be just a few hundred bytes coding them by an experienced z80 coder is quick and hopefully painless, and then everyone can get access to them.

Powered by SMFPacks Menu Editor Mod