Any adventure game tips???

Up to this point, I have been making only arcade games. Ones that you play the same level over and over with more enemies or harder enemies. Now, I want to make a full length (or pretty long, but not as long as like Zelda or something) Zelda type game. My question is, what is a good way to code this? For all my past games I have done: 1.Initialization (stating the variables) 2.The main game loop 3.Creating the functions that are called by the main game loop.

This works fine for my past games, but what if I want to make different worlds, different people to talk to, different quests, and all that stuff you would find on a Zelda type game? Any tips on how to do any of this?

Oh, sorry, I forgot one thing too. So far, I've been worried about keeping my ships and things off the ground and destroying them if they hit it. Now I want to do the opposite and keep my character strapped to the ground (except maybe jumping). If I have a bumpy terrain, how do I get my character to follow the landscape

Set up sliding collisions between the player and the terrain, translate the player by a modest amount downwards each frame (ie model gravity) and Blitz will do the rest. For simple jumping, apply a counter translation upwards that decays to zero over time.

Sledges suggestion works for 3D games.

I assume you are referring to a 2D game. In order to make the sprite react to different surfaces, you just have to code your game to (typically) perform something like a ImagesCollide between the player sprite and the background environment.

This is often achieved easier, if you have a 2D map editor to create the game in. One such good one is Universal Map Editor.

In case you were thinking of 3D, the basics:

;CURSOR KEYS TO MOVE & SPACE TO JUMP

Graphics3D 800,600,0,2

terrain=CreateTerrain(8)
For x=0 To 31
For y=0 To 31
ModifyTerrain terrain,x,y,Rnd(0.0,1.0),False 
Next
Next
ScaleEntity terrain,10,4,10
terrainTex=CreateTexture(32,32,8)
SetBuffer TextureBuffer(terrainTex)
Color 50,100,50
Rect 0,0,32,32,True
Color 10,50,10
For x=0 To 20
For y=0 To 20
Plot Rnd(0,31),Rnd(0,31)
Next
Next
gridTex=CreateTexture(32,32)
SetBuffer TextureBuffer(gridTex)
Color 128,128,128
Rect 0,0,32,32,True
Color 255,128,128
Rect 0,0,32,1,True
Rect 0,0,1,32,True
EntityTexture terrain,terrainTex,0,0
EntityTexture terrain,gridTex,0,1
TextureBlend gridTex,5
EntityFX terrain,1

SetBuffer BackBuffer()

player=CreateCube()
cam=CreateCamera()
light=CreateLight(2)
LightRange light,100

PositionEntity cam,0,20,-5
PositionEntity player,16,10,16
PositionEntity light,32,20,32

EntityType player,1
EntityType terrain,2
Collisions 1,2,2,3

boing#=0


While Not KeyDown(1)

canJump=False
For x=1 To CountCollisions(player)
	If CollisionEntity(player,x)=terrain Then canJump=True
Next

If boing>0
	boing=boing-.01
Else
	boing=0
EndIf		
If KeyDown(57)
	If canJump=True Then boing=.4
EndIf

If KeyDown(203) Then TurnEntity player,0,1,0
If KeyDown(205) Then TurnEntity player,0,-1,0
If KeyDown(200) Then MoveEntity player,.1,0,0
If KeyDown(208) Then MoveEntity player,-.1,0,0
TranslateEntity player,0,-.2+boing,0
If EntityY(player)<-20 Then PositionEntity player,16,10,16

UpdateWorld
PointEntity cam,player
RenderWorld
Flip
Wend

Yes, I was thinking of 3D. Sorry I didn't make that clear :)

Alright, I think I've got the terrain thing down. So, what else is there? How do I make the game so it can be a large world with many different people and places? Do I still have just one game loop?

Break the world up into sections and decide upon a data format that describes how they relate to one another; ditto for how NPC characters behave in relation to the player's progress; and so on for each element, like the savegame format and so on. Then you write a very small, two-location proof of concept quest in which each kind of object gets to exhibit the behaviour you want.

Then you turn your computer off, buy the biggest, fattest notepad you can find and design a fuller game around the technology that you now know you're capable of delivering.

For your proof of concept I would test out everything you want separately first - ie write a program that allows the player to travel from one map to another when he touches a portal, freeing the old map and loading the new one as required; have another in which to test out enemy AI and how well combat works; another to test out how to make NPC's forward the plot when the player achieves certain things, making the triggers easy so you can concentrate on the data management. You need to become comfy with every aspect separately before attempting to craft them together... otherwise you'll get a spaghetti mess.

It's quite a lot to chew on, what you're proposing. One thing you must consider is the effect of art - if you don't have access to any then working on a project like this can get very demoralising. Make sure you're prepared in terms of technical know-how and assets before diving in.

You're probably not exactly interested in a First Person Shooter type game, but you can use this sample code and modify it to whatever you need.

I am currently working on the same type of project. We have the story all worked out, main characters, etc..

3 page story outline, world details etc.

We will be using a scripting engine as the base of operations. The engine it self will have all the world functionality (map loading, lod, physics, particles, etc) and the scripting engien will govern what that does.

Each object in the world (IE bartenter, badguy, henchmen) will all have a script tied to him which will run and decide what he does/says based on what the world 'state' is and the player 'state'.

I am not sure if this is the correct way to go about this, however it is the best/most efficient way I can come up with.

So, I am going to make the storyline, maps and stuff in my notebook. That I can take care of. So, will the code still be in that order? Initialization, Game Loop, and Functions? And Sledge, sorry to be demanding, but I'm not exactly sure what you meant by break the world up into parts. Besides that, let me try to summarize what you said: I should make a tiny world to test out all the functions I want the game to do, like moving from area to area and all that stuff, right? And in this world, you want me to create at least one of each type of object and npc, and test them in this world to see if they work right? Then you want me to write down all my ideas for the bigger game, and if everything works as planned in the mini quest, start working on the bigger game, right?

Alright, so if that's right, then I have a few more questions. So, this is how I was thinking you would make an NPC. You'd make a Type called NPC. Give it values such as it's mesh, positions, and what it has to say right, and all that type of stuff. Is this the correct way, or is there a better way?

Also, you talked about freeing the old map and loading a new one. I have some ideas, but what is the way you do that?

One more thing (although there is sure to be more later) If I want to make an inventory, is that just like an array of types? (if that's even possible to use arrays and types together. I've avoided using arrays up to this point and know nothing about them)

Sorry about all the questions. Hopefully you took the time to read all that.

The models and data that describes how they are populated - rather than create and maintain the entire world at once, break it down into more manageable chunks.


You need to get a feel for what you can do and how you can do it. This kind of project brings you a real chicken and egg situation... should the content be design-led (ie you know what gameplay elements you want and will code and code and code until you either get them implemented or die trying) or should it be technology-led (ie you curtail your artistic vision to fit within the constraints you absolutely know you can achieve). For me it's a no-brainer... if you can't code "it" within a reasonable time frame then you can't do "it", can't have "it" and should forget about "it". So I'm sugesting that you spend a little time exploring how you might implement the most fundamental systems of this kind of game, because then you'll at least have a basis for a design.

You should be prepared, also, for the possibility that your first four or five attempts at this aren't going to go particularly well. It's a learning experience and this is another reason to keep things modest until those unexpected hiccups (and you will experience unexpected hiccups) have been encountered and dealt with.


Well, remember that your actual game will have more than one enemy/npc etc so the system you implement at the very start should at least be extensible. Most folk I imagine would instinctively go for types; myself and a few others prefer to handle objects via arrays.


Heh, I'm not setting you homework - you can approach this how you please, but I think a lot of people will agree with me when I say that, for a project like the one you are considering, planning is everything.


Off the top of my head - in the main game loop check to see if the player has entered (ie is within a certain distance of) a portal and, if so, whizz off to a function that checks which map the portal leads to and loads it in place of the current one. Before returning, the function would also check to see where the portal places the player on the new map and which portal(s)/enemies/npc's/objects/etc belong to this map so it can place all of them, too.


I don't use types. Were I writing a Zelda-type adventure, however, I might decide to finally learn how they work, because they might be highly advantageous in such a context and I wouldn't want to disadvantage myself. You're probably best advised to check out the blitzcoder.com showcases, look for a game with a similar remit and quiz the author directly (hoping they're not too grumpy). And I dont mean ask them to teach you types, just try and gain the benefit of their experience by getting some info on workable methodologies.

Okay, thanks. That's all for now. I'll have more once I get started though.

SOunds like you need to code the base 'engine' first. Set up a main loop etc whereby your character can walk around the scenery and jump etc etc. Then, add objects to interact with. I would use custom Types for these objects and their locations and statuses. EntityName$ is good here as well.

In your code, depending on the parameters defined by the Type and/or the EntityName$ of a particular object will determine the reaction of the player 'activating' that object.

(Does that make sense?)

Yes, that is exactly what I was thinking about today.

So, it's basically The main loop, just like my previous games, but the variables will change depending on the area the player is in. Such as the variables that hold the landscape and objects and NPC's within that landscape along with some numbers and things too, depending on what I'm doing, Right? (That's what I was thinking about, it sort of sounded like what you said)

So, depending on the area, I was thinking something like, for the objects, a new object type with a different name depending on what object it is would be made until all the objects that should be in that area are loaded. The Object type would have all the qualities that any object would need, then I just change them depending on what the object is, such as the mesh, the x,y,z coordinates, inventory(if it's a container) and things like that, right? And then something similiar would go for the NPC's (but with differnet qualities, such as speech)

So, I guess what I'm trying to say is it's just the same main game loop for each area, but with different variables and objects per area, right?


Did that make any sense? I confused myself.

Made perfect sense.

Best way to make a game is to make it modular.

Check out some of the code that has been written for the community projects (BAIT, Project Plasma, Space Invaders, etc.) and you will see the ideas behind them.

Grantyt3 - you got it perfectly :)

Alright, I guess that's all I need to know for now! Thanks everyone!

Okay, I found another thing. Let's say the player has a sword and I want to make it so that the sword kills the enemy, but if you hit the enemy with anything but the sword, you get hurt. Is there a way to make different entity types for seperate parts of a mesh?

No, but you can parent several entities (each with a different entity type) together.

You probably would have a seperate entity for the sword anyways (as opposed to having it being a part of the players mesh)...

That was my second idea :)

Okay, this will help for a lot of things, but lets say that I want to make a forest with a bunch of trees. I want all the trees to be in precise locations. Is there a way to do this without creating each tree individually?

You could creat a bitmap image. Each green pixel would be a tree. read the pixels from the bitmap and create a new tree where a green pixel is found. position the tree using the co-ords from the bitmap pixel location.

Is that like a heightmap? How do I tell
Blitz to load it and find each green pixel?

slow but easy way:

treemap=loadimage("my tree placement bitmap.bmp")

setbuffer imagebuffer(treemap)
for x=0 to imagewidth(treemap)-1
    for y=0 to imageheight(treemap)-1
       getcolor(x,y)
       if colorgreen()>0 then 
        ;we have a tree here so put your code for placing the tree in this section.
       endif 

    next
next
setbuffer backbuffer(treemap)

Thanks. Simple is good.