i too was becoming excited until skeezix's 'more precise' post... :/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
(ie: You can define it so player is always moving up, and then throw asprites at him )
The thing is the documentation has to be written REALLY well to allow average people to understand how everything functions.I could help with some of the tile art for you if you wanted me to.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
h34r:Well, I have the programming skill of a piece of stale bread.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
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.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
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
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 endMaking any sort of content is *always* time consuming. ie: Just drawing and twaking tiles can take a long timec0ncept posted on Mar 13 2004 at 11:59 AM said:
, 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.
Maybe I need to cut down on my GP32 posting and start GP32 doing instead. 
