Game Maker .. Anyone Interested?


Is that supposed to be an example of how to program a sprite in your game maker? Because if it is it looks difficult, Damn why cant we have the old days of "if then" statements back?

10 print "cry"
20 goto 10

run
:(
:(
:(
:(
 
Alpha2 posted on Mar 12 2004 at 11:21 PM said:
Is that supposed to be an example of how to program a sprite in your game maker? Because if it is it looks difficult, Damn why cant we have the old days of "if then" statements back?

10 print "cry"
20 goto 10

run
:(
:(
:(
:(
i too was becoming excited until skeezix's 'more precise' post... :/

Edit : my only wish is that it be just as useful at making 'side on' games as 'top down' ones... and hopefully it'll be easier than c++... :-||
 
Last edited by a moderator:
Certainly its a lot easier than C++ .. ie: You don't need to know how to code.

ie: You specify things in terms of "triggers" and "actions" -- a trigger is a group of conditions, and when they're all satisfied, the "action" (or group of actions) is performed.

So you define a map, you define sprites, you tell it to put sprites on the map, and then you define triggers and actions. The engine just runs it all.

Obviously you have ot have some skills.. ie: someone has to draw artwork .. the engine doens't just make it up. Also, making games is never easy or else they'll just suck and be all the same.. so you have to tell the engine what to do.. when this happens, do that.

Its primarily oriented towards top down games like Gauntlet (or simple forms of Zelda).. a vertical shooter is loosely possible,k but it wouldn't be the coolest ;) (ie: You can define it so player is always moving up, and then throw asprites at him :p)

This is what a simple action and trigger setup like..

action-group 10
post-message "Welcome to 6,5" 3
post-message "Second action.. after Welcome" 3
goto-text 1
variable-set foobar 0
variable-set _player_speed 5
action-group end

trigger 1
on-player-entry 5,6
on-floor mainfloor
on-variable-equals foobar 5
action action-group 10
trigger end

I've made it very simple format (and its documented) .. ie: You don't write if-statemnets, since level designers aren't coders. You write triggers whih define the conditions, and you define actions that are things to do.

By the sounds of it I've lost most of you though, so it may not be worth releasing.. (ie: The work to make it usable, and to support it prematurely may exceed the interest level of someone to make games :/)

(I work 70 hours a week, so wasting time is not something I cna afford to do :(

jeff
 
Well just because I'm a moron dosent mean everyone else is. :p The thing is the documentation has to be written REALLY well to allow average people to understand how everything functions.

Also keep in mind that it'd be worth while for people who ARE coders that just want to get a game up and running quickly.
 
publish the expected tile size and srite size and format, and see what people send in. I want to do a top-down quake 3 clone for the fun of it.
 
skeezix posted on Mar 12 2004 at 09:13 PM said:
OKay, to be a little more serious..

Which of you would jump on the option to do things like this:

sprite baba # name of sprite for later use
name baba # display name of sprite if we ever display it
order 1 # spr. order is 1..3 (start at 1, 3 is drawn last)
speed 3
# AI details
ai mob_wander # the AI to use
ainear mob_robotron # the AI to use when player is "near"
near 3 # 7 tiles away is "near"
# dimensions; artwork dimensions and sprite body dimensions!
image_width 16
image_height 16
width 16
height 16
#
# while standing still
anim_statedef still # if engine needs a missing state, first state used
anim_steps 5 # 7 artworks in pcx file
anim_offset_x 25 # artwork is 25px offset from last step
anim_image pointyplus # use this image for animating this state
#
sprite end

(Thats a simple sprite definition)

A game needs someone to make artwork, and someone (could be same person) to make the configs that are very much like the above.. where you write config details for every object in the game, every square on the maps, etc.. lots of work.

If you have a game idea, and you are motivated enough to actually go through with something.. post here and let me know :)

If theres a few people interested, I'll get the GP32 veroisn working enough to zip up and set up a mailing list and all that goodness :)

jeff
I could help with some of the tile art for you if you wanted me to.

But that other programming stuff above may as well be written in Greek as I don't understand any of it. :D
 
Last edited by a moderator:
NiN^_^NiN posted on Mar 13 2004 at 09:25 AM said:
Its not that hard just read the docs when they come out and you will be fine :)

if this is 2 hard then try making a small adventure game using VNS from virtualeech

:ph34r:
Well, I have the programming skill of a piece of stale bread.
 
Last edited by a moderator:
Actually I just started seriously diving into the VNS scripting language and it seems a lot more simple than this(once you compare the file to it output), but I do think now that this method is a bit easier than it seemed to me at first.
 
skeezix posted on Mar 13 2004 at 01:23 AM said:
Certainly its a lot easier than C++ .. ie: You don't need to know how to code.

ie: You specify things in terms of "triggers" and "actions" -- a trigger is a group of conditions, and when they're all satisfied, the "action" (or group of actions) is performed.

So you define a map, you define sprites, you tell it to put sprites on the map, and then you define triggers and actions. The engine just runs it all.

Obviously you have ot have some skills.. ie: someone has to draw artwork .. the engine doens't just make it up. Also, making games is never easy or else they'll just suck and be all the same.. so you have to tell the engine what to do.. when this happens, do that.

Its primarily oriented towards top down games like Gauntlet (or simple forms of Zelda).. a vertical shooter is loosely possible,k but it wouldn't be the coolest ;) (ie: You can define it so player is always moving up, and then throw asprites at him :p)

I've made it very simple format (and its documented) .. ie: You don't write if-statemnets, since level designers aren't coders. You write triggers whih define the conditions, and you define actions that are things to do.

By the sounds of it I've lost most of you though, so it may not be worth releasing.. (ie: The work to make it usable, and to support it prematurely may exceed the interest level of someone to make games :/)

(I work 70 hours a week, so wasting time is not something I cna afford to do :(

jeff
This sounds great! But I feel the examples you gave have no anchor to the system as a whole. Just giving code snippets expects some knowledge of what is going on to understand them.
Maybe if you gave some docs, instead of examples, cuz looking straight at new code can confuse statements, names and variables

Some thing like this may be more helpful
(Apologies if I misunderstood anything)
Code:
sprite <name> # name of sprite for later use
name "name" # display name of sprite for later reference
order [number] # Hmm. Not too sure about this. Something about anims?
speed [number] # delay between anim images 
# AI details
ai <script> # the AI script to use
ainear <script> # the AI script to use when player is "near"
near [number] # when to use ainear script
# dimensions; artwork dimensions and sprite body dimensions!
image_width [number] # sizes!
image_height [number] # sizes!
width [number] # sizes!
height [number] # sizes!
#
# defining a state
anim_statedef "state" # What the anim is going to do ...
anim_steps [number] # how many frames of anim
anim_offset_x [number] # how to get frames from artwork
anim_image "anim" # use this image for animating this state
#
sprite end


action-group	<group> 
post-message	"text" # define some text
post-message	"more text" # define some more text
goto-text	[number] # print a message
variable-set	<variable> [number] # set a variable
action-group	end

trigger  <trigger>
on-player-entry	[mapx],[mapy]
on-floor	<floor-description>
on-variable-equals	<variable> [number]
action  <action-group>
trigger  end
In writing this I've come to understand more about the system you've used, but I'd like to see more of the docs before suggesting things you may have already done.

I'd also like to know more about the anim-states definitions and action-group and trigger scripts...
  • How many anim-statedefs can you have within a sprite? And why is there no end-anim-statedef.
  • goto-text appears to print a message referenced by it's order of appearance in the script. This seems a bad idea for scripts under development. Can this be changed to a direct reference?
  • How many on-variable-equals can there be within a trigger definition and what happens when the varible isn't equal?
  • Are expressions supported in variable-set commands or are there variable-add, variable-sub, etc
I realise that this is just a teaser of the whole set of commands that you've added and I would be very interested in seeing how you have implemented the rest of the system, eg. map definitions, sprite control variables.
And how deeply things can be controlled, eg. sprite palettes, changes in anim speeds and direction, tile changes within the map.

It sounds like a great system and I hope you don't give up after all the time you've obviously put into it.
 
Last edited by a moderator:
Why not simple use SDL instead? It is much more documented, so even if it may seem a bit more complicated the documentation and the number of people you can ask for help makes up for it. Coding 2D games in SDL is not exactly rocket science.
 
It doesn't seem to complex really, but I making a game with it would involve a lot of time and effort (not because the scripting is hard but cos it seems a little lengthy), and zelda does seem a very plausible game to make if I've understood the scripting stuff right.

presumably the engine features collision detection, how is this scripted?
 
I'll try and catch up to some of the comments ;)

Theres no worry of me giving up.. ie: I'm making this engine so I can make a couple of games in my head, and I've got one of those as a couple guys on the side already.. (ie: I have a artist and a level designer working on a game in the engine); that will always be going on until its done of course :) I'm also working on a game myself in the engine, once in a bit. But supporting a public release of a generalized engine is a lot of work.. answering questionsm building needed options etc.. so if theres enough interest, I'll do it.. but I can't do all that for just one person say.. it sjust too much work to do :) But if theres 3 or 4 peopel who are going to dive in and do some fun stuff (and actully do it, not screw around and do nothing ;) then I'm game :) (I hope that makes sense.. its tough when you work your ass off so many hours a week.. but I run my own company, so I do it gladly :)

Anyway, the stuff is reasonably documented.. I need to flesh the docs out a lot more, but you cna see most of the docs here:

http://www.codejedi.com/zot/zotconf.html

If you need details on any section of it, let me know. It sort of assumes you have seen the engine and config file so you can look up examples in the existing configs, but you should be able to get a good idea of how it operates.

So, show of hands.. look at the docs, and if theres 3 or 4 of you who would commit to trying to do something halfway useful (within a certain bounds, since I've not the time ot make a custom engine for everyone :) then I'm game :)

ie: Its a tile-sprite engine.. so things like arkanoid, bomberman, etc should be doable.. scrolling tiles, with sprites on top. Its focused towards things like Gauntlet.. enemies come at you directly as possible and big giant mazes. Shoudl work for simple top down zelda style games as well, since thats what I'm designing it for.. But its not going to do doom style games ever.. I just don't have time for it :)

jeff
 
c0ncept posted on Mar 13 2004 at 11:59 AM said:
It doesn't seem to complex really, but I making a game with it would involve a lot of time and effort (not because the scripting is hard but cos it seems a little lengthy), and zelda does seem a very plausible game to make if I've understood the scripting stuff right.

presumably the engine features collision detection, how is this scripted?
Making any sort of content is *always* time consuming. ie: Just drawing and twaking tiles can take a long time :)

But laying out levels, scripting up events etc.. its a lot of work to define in script, and a lot of work to get it working just so.. Such is life. Coding it yourself woudl be many months of suffering, this makes it a lot easier ;)

For those interested.. if I can get 3 or 4 people interested, then I'll give you the current alpha windows version with the demo level pictured; you can try futzing around, and w'ell go from there; the gp32 version needs some tweaking before it'll run in a public way, so I'll go through with that in one of two times..

1) If I've got a commited group of gp32'ers working on levels :)

2) If not, I'll finish it up when I've produced my own games and levels, and thus having something

I won't wrap up the gp32 version of the engine if theres nothign to show forit, since it'd just be a waste of time up front.. (I manage my time *very* carefully, since I work for so much of it :)

Suffice to say that even if theres no one interested, you'll see the gp32 game in time anyway of course, once we get one put together :)

jeff
 
Last edited by a moderator:
well...hmmm....I was doing a programming course but I jacked it in cos I hate maths. However, this engine looks like I could understand it and make a game, though I wouldn't even start till the summer holidays, around may/june. Still I reckon I'm game! incidently anyone any good at ripping graphics (rather than creating them) because I have not got the patience.
 
Ah yes, missed one Q ..

SDL isn't a scripting language, nor is it avaliable everywhere. ie: People can make games with SDL (that is of course what its for :), but then you need to know C, and ou also depend on the implementation of SDL. (In fact, my Windows version is based on SDL..) My goal was, however, to keep peopel out of that.. -- its my engine, but peopel making the games dont' need to concern themselves with code.. they just need to be level makers and artists and scripters etc.. so anyone can do it. Separate the hard parts form the game design and biuldsing parts, really.. so I don't worry so much about the games.. I worry about making a useflu engine for the game sI want to make/support. But you guys would just worry about the game parts.. not the engine.

SDL is not available for PalmOS or Zodiac or Symbian/Nokia or .. long list here. The engine is designed for cross platform simplicity.. so I'll add platforms as time and interest permit :)

It runs on my phone :)

jeff
 
This is looking very sweet Jeff. Looks very easy and logical to me anyway but I'm and IT manager (not a programmer mind you) with many years of system control language, DOS batch files and some Amiga blitz coding behind me. I'm sure that if you released the Alpha with just some command descriptions and maybe brief sample scripts for the more complex commands you could get many of the community up and running with little input and rely on a dedicated topic/forum here to help the noobs.

I really am starting to wish I had more free time :) Maybe I need to cut down on my GP32 posting and start GP32 doing instead. ;)


! Oh just noticed the documentation page. Doh! I still think a command list would be handy though.
 
Back
Top