I've been pondering over the past few days how I would attempt to write a game creator for the cpc, and was wondering how other people would attempt to do similar. In fact I was trying to recall any serious game creator for the cpc and only really came up with things like GAC, Freescape and possibly Zack (never released)
In my head the best way to attempt such a beast would be to involve no programming for the user (unless they wanted), almost certainly a PC based application that creates snapshots which can run immediately via emulation. Mainly this is for speed, and potential to work across a team, and share resources. The central point of the creator would be an assembler so that plugins could be reassembled to make the style as compact and flexible as possible.
So how would you attempt this?
Quote from: Trebmint on 09:05, 12 July 10
I've been pondering over the past few days how I would attempt to write a game creator for the cpc, and was wondering how other people would attempt to do similar. In fact I was trying to recall any serious game creator for the cpc and only really came up with things like GAC, Freescape and possibly Zack (never released)
In my head the best way to attempt such a beast would be to involve no programming for the user (unless they wanted), almost certainly a PC based application that creates snapshots which can run immediately via emulation. Mainly this is for speed, and potential to work across a team, and share resources. The central point of the creator would be an assembler so that plugins could be reassembled to make the style as compact and flexible as possible.
So how would you attempt this?
Are the plugins intended for different types of games?
In terms of a game creator, a flexible way would be to allow the user to create a set of "timelines" and to package all the elements they need together in a project.
In the timeline you can put down events in time (check for key press, trigger animation, goto etc).
The editor would compile these into a form that the game code would run.
Here you would have lots of flexibility for the user to create what they want, but the downside is the "engine" executing these may not run fast on the cpc.
Depending on how you implement it, you either have to create almost all the tools (gfx conversion to cpc, map editors, game code to run it), or you could join together other tools with your own build system.
EDIT: There are probably enough tools out there, that you could choose to create a build system and join them together.
map editors, gfx converters etc...
Quote from: arnoldemu on 10:04, 12 July 10
Are the plugins intended for different types of games?
In terms of a game creator, a flexible way would be to allow the user to create a set of "timelines" and to package all the elements they need together in a project.
In the timeline you can put down events in time (check for key press, trigger animation, goto etc).
The editor would compile these into a form that the game code would run.
Here you would have lots of flexibility for the user to create what they want, but the downside is the "engine" executing these may not run fast on the cpc.
Depending on how you implement it, you either have to create almost all the tools (gfx conversion to cpc, map editors, game code to run it), or you could join together other tools with your own build system.
EDIT: There are probably enough tools out there, that you could choose to create a build system and join them together.
map editors, gfx converters etc...
Yes the plugins would be for different game types in that you might have a variety of map display/collision engines and you choose which is appropriate, further down you might have different player or enemy plugins. For example a player plugin might be for plaform game where you can adjust speed and jump height, or you might have a thrust type plugin where its all rotation and gravity control.
The idea would be to mix dozens of self contained z80 routines with GUI controls tied to variables / anims and or events.
As for the tools I think a map/graphics/animation editor needs to be built in, in fact it needs to be all in one. Plus I like the idea of an online central resource for the projects so if you create a anim it can be uploaded and used by others. A central resource for plugins, graphics, tiles anims and entire projects to promote easy creation.
Do you want to make a "universal" editor, which you can make *any* kind of game, or specific ones ? GAC is for adventure game, so is PJA (to be added to your list).
I wanted to spread my own kit to make "Orion Prime"-ish kind of game, as the scripting is quite evolves, but gave up, as I think no one would really use it...
Anyway, my opinion on your project is that it is completely & overwhelmingly difficult if you want to be able to create any kind of game, and at the end it will be too slow to have a nice arcade game, because fast games requires specific codes. Look at these spanish gamed, made with the same development kit. They are nice, but they can't do anything else than three sprites, no scrolling and background made of little tiles. Now look at a fast&furious game like Dead On Time : it has specifically made code. As "simple" as this game can be, I don't think it was an easy task to do... Nor do I think an editor, however good it can be, can achieve such result.
Quote from: Targhan on 18:38, 12 July 10
Do you want to make a "universal" editor, which you can make *any* kind of game, or specific ones ? GAC is for adventure game, so is PJA (to be added to your list).
I wanted to spread my own kit to make "Orion Prime"-ish kind of game, as the scripting is quite evolves, but gave up, as I think no one would really use it...
Anyway, my opinion on your project is that it is completely & overwhelmingly difficult if you want to be able to create any kind of game, and at the end it will be too slow to have a nice arcade game, because fast games requires specific codes. Look at these spanish gamed, made with the same development kit. They are nice, but they can't do anything else than three sprites, no scrolling and background made of little tiles. Now look at a fast&furious game like Dead On Time : it has specifically made code. As "simple" as this game can be, I don't think it was an easy task to do... Nor do I think an editor, however good it can be, can achieve such result.
Initially it would be I assume limited to a small range of game types, but as plugins were added this would extend, and because they can be fairly specific I see no reason why speed should be a major concern.
Anyway i was just asking how people would attempt such a project from their own viewpoint? This is very much a idea
Well, IMHO, you should focus on one type of game. Really! It will be hard enough anyway.
ZACK was actually almost completed, but there was no sound fx/music editor and very little room left in the 128K to implement it. Perhaps if I had known all the OO stuff I know now 20 years ago, I might have managed to get it all to fit. It does require some programming knowledge, but it's pretty basic stuff like CLEAR SCREEN, PRINT, MOVE OBJECT etc.
Quote from: Executioner on 13:54, 13 July 10
ZACK was actually almost completed, but there was no sound fx/music editor and very little room left in the 128K to implement it. Perhaps if I had known all the OO stuff I know now 20 years ago, I might have managed to get it all to fit. It does require some programming knowledge, but it's pretty basic stuff like CLEAR SCREEN, PRINT, MOVE OBJECT etc.
Yes Zack was an excellent piece of kit I remember well, and actually did some coding with it back in the day via my contacts with STS (Blimey what happened to that lot), shame it was never finished. Remember the Heli game looking rather snazzy. How did that language actually work, was it Pcode or actually compiled into z80.
Other "game makers" i can think of is:
- 3D construction kit: 3D only?
- Genesis: but adventure only.
- The Quill (+the illustrator upgrade): adventure.
- Artist and Sprite Designer (Crl): basic sprite moving pack for use in basic.
- Laser Basic: also for use in your own basic programs. This one seems the most professional one (132 page manual).
Perhaps making a something a bit more simple like "shoot em up constuction kit" (like exist on Amiga) is less complex.
Sprites Alive add a lot of interesting features to BASIC game programming oriented (animation, collision detect...).
EDITO : Ah !! And TommyGun at http://www.users.on.net/~tonyt73/TommyGun/ joins various multisystem programing tools.
Quote from: Trebmint on 17:15, 13 July 10
How did that language actually work, was it Pcode or actually compiled into z80.
It had a built-in compiler to create Z80. The language itself was tokenised so it compiled very quickly.
Quote from: Executioner on 13:54, 13 July 10
... Perhaps if I had known all the OO stuff I know now 20 years ago, I might have managed to get it all to fit.
Really? I always had the impression that OO makes is slow and blows it up. Maybe the solution would be to use a CPC with more than 128 KB (or another OS).
Quote from: MiguelSky on 21:57, 13 July 10
EDITO : Ah !! And TommyGun at http://www.users.on.net/~tonyt73/TommyGun/ joins various multisystem programing tools.
I had a quick look - exactly, TommuGun seems to be more of a programming tool than a game creator...
Quote from: Gryzor on 07:58, 14 July 10
I had a quick look - exactly, TommuGun seems to be more of a programming tool than a game creator...
Well yes Tommygun is an exceptional editor, but I think when developing such tools today you have to look at who you are writing for, and the truth is the numbers of people with the time and skills to write a z80 masterpiece from scratch (even if you have upto dat tools) is very small. The game creator I envisage is yes limited, but also visual and instant results, and simple to change from the samples. That way I hope to get a number of users, and with users will come additional plugins extending the range of games
Quote from: Trebmint on 08:35, 14 July 10
Well yes Tommygun is an exceptional editor, but I think when developing such tools today you have to look at who you are writing for, and the truth is the numbers of people with the time and skills to write a z80 masterpiece from scratch (even if you have upto dat tools) is very small. The game creator I envisage is yes limited, but also visual and instant results, and simple to change from the samples. That way I hope to get a number of users, and with users will come additional plugins extending the range of games
Have you looked at platform game designer or arcade game designer? both of these are on the spectrum by Jonathan Cauldwell.
http://members.fortunecity.com/jonathan6/egghead/
Maybe this will give you ideas.
Looking at the worldofspectrum forums a few people are using them, but still the number of finished and released games is few.
I have been using z88dk, cpcrslib (+ my own patches and tools) to make blue angel 69.
It has made writing games a little more easier in some respects (e.g. coding in c is nice), but because blue angel is very gfx heavy, I am finding it hard to fit it all in the ram, but I am almost done).
For me, it's not necessarily a editor package that does the whole job, but more a good set of tools and build environment.
Maybe a poll would be a good idea, or just ask what people really need to make games then you can concentrate your efforts to fullfill those needs.
I absolutely don't know what they look like, or how powerful they are, but two threads in Spectrum forum talk about :
Platform Game Designer 2 :
http://www.worldofspectrum.org/forums/showthread.php?t=28711
and Arcade Game Designer 2 :
http://www.worldofspectrum.org/forums/showthread.php?t=26175
Maybe it can help and give some leads... or maybe not :).
Quote from: TFM/FS on 02:16, 14 July 10
Really? I always had the impression that OO makes is slow and blows it up.
Yeah, right. That must be why the whole industry has embraced it then! Seriously, if you implement OO correctly it shouldn't slow anything down much, and is usually a cleaner way of implementing complex functionality without loads of conditional code. Admittedly, the Z80 isn't ideal for OO, but it can do it.
QuoteMaybe the solution would be to use a CPC with more than 128 KB (or another OS).
Haven't we already determined that most people have 128K, not more.... In another thread. And ZACK doesn't use any firmware apart from maybe some AMSDOS calls.
Quote from: Executioner on 03:48, 16 July 10
Yeah, right. That must be why the whole industry has embraced it then! Seriously, if you implement OO correctly it shouldn't slow anything down much, and is usually a cleaner way of implementing complex functionality without loads of conditional code. Admittedly, the Z80 isn't ideal for OO, but it can do it.
I've learned that OO coding isn't the most optimal way of coding on limited platforms. Objects take more memory than primitives, and accessing objects rather than arrays with primitives are slower. At least that's how it is on the J2ME platform, which is why a lot of J2ME coders say that J2ME != JAVA
I don't think it means
that much today with all the new high end phones, but a lot of J2ME coders still avoid OO coding to gain more speed and memory, because they still want their game to be compatible with older devices.
To be honnest the main interest for software industry to use OO languages is productivity (and not always) , not speed or memory usage.
Quote from: mr_lou on 06:01, 16 July 10
I've learned that OO coding isn't the most optimal way of coding on limited platforms. Objects take more memory than primitives, and accessing objects rather than arrays with primitives are slower. At least that's how it is on the J2ME platform, which is why a lot of J2ME coders say that J2ME != JAVA
I don't think it means that much today with all the new high end phones, but a lot of J2ME coders still avoid OO coding to gain more speed and memory, because they still want their game to be compatible with older devices.
I agree totally!!! I had communications with a lot of programmers during my life. And the real good coders all say no to OO on samller systems. I fact OO make it slow and blows it up. Better use C then OOP.
Again and again people want to see advantages in OOP, but these "advantages" only exist on very quick and very huge systems, where you don't have to care about memory and speed.
People often don't believe this - year later they come crawling back :P
In my opinion (almost 11 years as professional game developer), OOP is suited for big or very big projects. I really cannot imagine the people at Epic making Unreal Engine 3 in pure C or assembly... mostly because of the immense size of the project.
OOP is also nice when it comes to isolate and reuse blocks of code, and modern C++ compilers do achieve very nice performance.
For machines like our beloved CPC, OOP is completely overkill, but hey! I also enjoy playing Bioshock 2 on my Xbox 360. They are on completely different leagues, and OOP is therefore more suitable to the bigger one.
Quote from: robcfg on 00:20, 17 July 10
For machines like our beloved CPC, OOP is completely overkill, but hey! I also enjoy playing Bioshock 2 on my Xbox 360. They are on completely different leagues, and OOP is therefore more suitable to the bigger one.
Yes, right! And in case you really want to use OOP on a CPC you should (like mentioned and misunderstood before) use a CPC with at least 0.5 MB RAM and maybe a hard-disc to run the game creater. The final game is supposed to run on an 128 KB machine, which can achieved a bit more easy: The game-creator uses RAM for itself and the game (currently under developpment or even finished), while the game needs only RAM for itself.
However, personally I never would use OOP on the CPC because everything I saw on CPC using OOP is relatively slow.
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....
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.
Anyway... if you're making a game-creator, to be run on PC, then how about implementing options to compile for multiple platforms? 8)
Quote from: mr_lou on 05:14, 21 July 10
Anyway... if you're making a game-creator, to be run on PC, then how about implementing options to compile for multiple platforms? 8)
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.
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?
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
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...
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
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.
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 ;-)
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.
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).
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.
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.
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?
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. :)
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.
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).
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.
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 (http://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.
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.
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.
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.
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.
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 (http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html)
maybe you can do the same with your tool?
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.
Sorry to bump it, hope Trebmint continue to work on this project.
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! :)
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.
Thanks Trebmint!
You need very clear standarts for the plug ins ;)
Quote from: TFM/FS on 00:47, 28 September 10
You need very clear standarts for the plug ins ;)
This is very true. Mainly its about keeping code relocatable. Currently I have a very ordinary assembler, but I plan a number of syntax additions, like referencing global jump points or variables so limiting the plugins range of access. Plus commands to reference local vars to GUI objects like a slider or a dropdown.
In theory it should be very simple to use once you get the hang of it. We'll have to see if the actual coding lives up to the plans though :)
don't hesitate to use me as a totally newbie guinea pig
Quote from: Trebmint on 09:44, 28 September 10
This is very true. Mainly its about keeping code relocatable. Currently I have a very ordinary assembler, but I plan a number of syntax additions, like referencing global jump points or variables so limiting the plugins range of access. Plus commands to reference local vars to GUI objects like a slider or a dropdown.
In theory it should be very simple to use once you get the hang of it. We'll have to see if the actual coding lives up to the plans though :)
Hmm, you talk about "relocatable code" and of GUI elements... do you plan to make the Game Creator for SOS? There you would have already GUI elements and since you have done SymStudion, you already know how to use SOS. I'm just curious :)
Quote from: TFM/FS on 18:01, 29 September 10
Hmm, you talk about "relocatable code" and of GUI elements... do you plan to make the Game Creator for SOS? There you would have already GUI elements and since you have done SymStudion, you already know how to use SOS. I'm just curious :)
No as far as I know Symbos is dead until Jorn ressurrects it. The GUI is for the PC based application not the CPC side, and is designed to allow control for the user over the plugin. Effectively so you can add textbox, slider, dropdown, countbox etc which are all directly linked to z80 variable all via z80 assembler
I had Laser Basic but just couldn't get my head around the manual (I was 11 years old at the time though!)
I've starting wiith Laser manual too, it's defintely not for beginner, the manual from Sprites alive is better, haven't the time to workaround the demo yet... but I think the ability of printing the listing on the PC will make my life easier.
Quote from: jbaudrand on 10:21, 30 September 10
I've starting wiith Laser manual too, it's defintely not for beginner, the manual from Sprites alive is better, haven't the time to workaround the demo yet... but I think the ability of printing the listing on the PC will make my life easier.
Z80 assembler really isn't that hard and it's great fun to program.
Plus there's loads of online websites with source code and if you get stuck you can always ask on this forum as it's frequented by some extremely talented programmers (just look in the programming section).
Quote from: redbox on 10:39, 30 September 10
Z80 assembler really isn't that hard and it's great fun to program.
Plus there's loads of online websites with source code and if you get stuck you can always ask on this forum as it's frequented by some extremely talented programmers (just look in the programming section).
Yeah, and I frequent there too :)
Quote from: Trebmint on 19:49, 29 September 10
No as far as I know Symbos is dead until Jorn ressurrects it. The GUI is for the PC based application not the CPC side, and is designed to allow control for the user over the plugin. Effectively so you can add textbox, slider, dropdown, countbox etc which are all directly linked to z80 variable all via z80 assembler
Ok, very slowly (I'm 40!!! it takes it's time ;) I understand a bit of your big picture :-)
Now, I think your idea with the "plug ins" is really great. If I can contribute to the project I will do.
Do you plan to use a own small "OS", like some games do? Hmm, probably it's the best thing to start from Amsdos/Basic, throw out the Firmware (get some bytes) and to have a own minor DOS, just good to load needed files. ... just thinking...
Quote from: TFM/FS on 21:06, 30 September 10
Ok, very slowly (I'm 40!!! it takes it's time ;) I understand a bit of your big picture :-)
Now, I think your idea with the "plug ins" is really great. If I can contribute to the project I will do.
Do you plan to use a own small "OS", like some games do? Hmm, probably it's the best thing to start from Amsdos/Basic, throw out the Firmware (get some bytes) and to have a own minor DOS, just good to load needed files. ... just thinking...
Yes I hope this plugin idea is going to make things really easy once a few people start coding. The idea is that you never have to start a game from scratch, but just edit and modify as you go, and the game is always playable at every stage.
As for the firmware, yeah that will be dumped. I like the idea of cross platform, or atleast a version which will run on the cartridge so using firmware isn't an option. The creator version of the firmware will be based on plugins too, so that will cover the cross platform issue, though these are simple things like music players, key scanners, disk etc
There is one thing... that can't (at least not easy) be done with plug-ins. You need a kind of interrupt structure, to synchronise events with the Frame-Fly or f.e. with another interrupt. The more simple such a system is, the better it can be used. At least there should be options to call routines when INT0,1,2,3,4 and 5 are firing. So for example you can lock a scrolling plug in to INT0, a Color-switch plug-in to INT 1 and 3 and a music player to INT4 (there it doesn't disturb ;). ... just as an example...
Another thing... it would be great if ALL Z80 registers can be used. (I don't dare to ask for the Z80 interrupt mode 2, this really would lead to far.... maybe not on the Plus ;)
Quote from: TFM/FS on 05:03, 01 October 10
There is one thing... that can't (at least not easy) be done with plug-ins. You need a kind of interrupt structure, to synchronise events with the Frame-Fly or f.e. with another interrupt. The more simple such a system is, the better it can be used. At least there should be options to call routines when INT0,1,2,3,4 and 5 are firing. So for example you can lock a scrolling plug in to INT0, a Color-switch plug-in to INT 1 and 3 and a music player to INT4 (there it doesn't disturb ;) . ... just as an example...
Another thing... it would be great if ALL Z80 registers can be used. (I don't dare to ask for the Z80 interrupt mode 2, this really would lead to far.... maybe not on the Plus ;)
I've not really put much thought into interrupts yet, and probably the first release won't be that flexible other than allowing the core needed plugins to be included.
The idea is to run everything off an interrupt like a giant game loop that ticks every 50th and each of the core units will be programmable to set how often the are called. The core units will be
1. Screen updater - scrolling, sprites, background updates etc
2. Music / FX player
3. Key scanner
4. Animator
5. Gameplay core - controls all the active player/characters
Each of these units will have a time control and will automatically be activated, so you might set the Screen updater to happen 15 times a second, and the Animator 5 times a second. Obviously the music will be every 50th.
I guess there is no reason why other cores cant be tacked on at a later stage. Plus the z80 assembly will be freely available for you to tinker with. However the first releases will be more about just getting it working than allowing technically challenging development.
The good thing I think though is because it's assembled (and the source is clearly visible) when you build the project, inventive z80 coders such as yourself will be able to just alter the core routines and squeeze as much out of it as possible, and hopefully you'll let those routines go onto the server for others to use. The apps main point is to glue the all the pieces of code together
Sounds like you have a lot of work to do! My best wishes for the project! I'm really looking forward to see it growing ;D
is there any news on this project?