I Like BlitzMAX (notes on the win32 beta)

BlitzMax Forums/BlitzMax Beginners Area/I Like BlitzMAX (notes on the win32 beta)

BlitzMAX is a very nice language to work with so far.

The Major improvements over Blitz are currently also generating the most complaints.

With Modular Design, Object-Oriented Programming and Cross-Platform support, I look forward to a Language that will Scale to the latest Hardware and Evolve over time. The Traditional Blitz Model of POINT updates is now supereded by Module Synchronization. A change in one module should have little or no effect on the overall stability of the language. After just a week or so of playing with the OOP functionality, I have learned quite a bit and really look forward to more modular and manageable code.

Blitzbasic, Blitz3D and Blitzplus have a tremendous record of support and stability.

and, yes, While I don't consider them finished, the documentation is rather good. The BBDOCS system generates documentation when the Modules are synchronized. It is up to the Module builder to make the docs clear and informative. Many of them are excellent. Mark's inro to OOP in the tutorial forum is top notch.

as more tutorials and documentation updates occur, we should have plenty of reference material to accomplish our goals.

Many of us are waiting for the 3D module. I am already amazed by the 3D demos that have already been released in MAX. The 3D modules should serve to simplify and streamline some of the complexities of 3D OpenGL.

I understand that some folks are dissatisfied with the complexity, lack of docs and other factors. Some of them are attempting to port over an existing Blitz3D of BB project. If you fall into this category, please try to consider MAX a seperate and distinguished language, not a 2.0 version of BB or B3D. The syntax and overall scope of MAX is quite different than that of its predecessors.

Overall, I thoroughly enjoy learning this fantastic new language.

I admit I was hoping for a lot more with BlitzMax but what I have seen so far of new stuff is great still.
I'm not complaining about BlitzMax for a long time yet, but if there's still poor docs and no 3D/GUI in a year I will :)

The language is pretty nice. Quite a few obvious things missing, but nothing so far that can't be worked around.

The documentation is barely adequate for a beta, and if I had a Mac, I'd consider the documentation completely INadequate.

I'm very disappointed with the 2d module. I was expecting it to be a lot more impressive than the extremely basic one we got. I mean alpha blending and realtime rotation and scaling are an improvement over BlitzPlus ( though not over B3d ) and that's pretty much as basic as the improvements could be, considering that OpenGL is all 3d accelerated anyway. But hey, it's early days, so the good stuff may be added later.


I'm very disappointed with the 2d module. I was expecting it to be a lot more impressive than the extremely basic one we got.


I think the 'problem' is his constant struggle to make things powerful and easy at the same time. It has kind of knocked him over the head and took control of his senses.

So on one hand you have a set of powerful language features, but on the other hand there are areas(Only a few mind you, 3d aside) over-simplified or simply not supported, like .dll creation, function overloading, macros. He had macros in Blitz2.1, so it's clearly not a lack of knowledge on his part..he could do things like this over ten years ago.

(edit- err my point being that's probably why the 2d is so cut back...never mind :) )

Sybixsus, what were you expecting out of the 2D module?

The ability to draw a piece of an image? :) I mean, I was able to cobble together my own function based on work Noel Cower had done in the code archives, but it seems kind of silly for that not to be part of the base functionality.

It means that packing images onto larger textures is just not a realistic option in the baseline Max code.

Overall, I thoroughly enjoy learning this fantastic new language.
yes.

I didn't really notice anyone complaining too much about the new features, just the docs, sample code and tutorials.

I have a grasp of the basics of old blitz and how it relates to Bmax, but mostly through doing old blitz tutorials in Bmax.

the sample code seems to be full of coders trying to show off new features like Methods, extensd or something and doing all kinds of crazy things thats really confusing to someone thats trying to learn the basics of types, arrays and functions.

Too much stuff thrown in my face at once and no point of reference or basic instruction to build up from makes the whole learning process very difficult indeed.

The doc's in the IDE help mean very little to me as they stand, since they don't seem to show examples about how you go about using them, and the samples have no progression from beginner through to advanced.

If I want to learn the basics and shoot bullets from a ship all I find is methods, extends, all intertwined in a fashion that probably makes sence to a programmer with some experience.

So far I have gotten by by cutting out and isolating areas that I am having trouble with, but don't know how to proceed from that point on.

If you ever gave your grandad a computer and tried to teach him how to use windows with a mouse (he having never used a computer before) When it comes to Bmax, it's kind of like being your grandad, only I havent got a manual thats in plain english, but something that assumes you've used a computer before and just need a quick refresher course as to whats changes. Which essentially what the Bmax docs and samples are.

At least the other languages have a couple of years of user docs, articles and techniques to learn from, so with a lot of time and effort and experimentation you can get through it.

I think Bmax itself is excellent, and just through comparing B+ and B3D code in tutorials to what canbe done in Bmax, I can see how much better it is than previous languages.

Like Sybixsussays

The documentation is barely adequate for a beta



Seems to sum it up pretty well. I think it was definately $80 well spent though :).

Lighting would have been nice for 2D. Pretty essential IMHO... ie... ulimited max2d module fake lights with proper attenuation that ends where it should.

Don't get me started on the pathetic joke that is Blitz3D's unlimited falloff, preventing light re-use.

We won't. You can spare us any more moaning skunk, we get the point.

Anyway, think thats enough moaning on my part too :) Writing tutorials and stuff takes a lot of time, but I hope it all gets sorted out for people like me that turn up weeks from now.

Looking forward to seeing Bmax getting fixed and signs of the 3D module taking shape, rather than have people like Mark and Skid spending an age writing docs. In the meantime I'll soldier along and see what I can learn from the code people are starting to post out there on the forums.

Ant: That does appear to be the cause of the problem, I agree.

Sybixsus, what were you expecting out of the 2D module?


Err yeah.. didn't really want to get into this, since it inevitably ends up with a whole bunch of people telling another bunch of people that all the things they want/need are completely worthless. It would be rude to complain and not at least offer a few points to illustrate, however.

Yes, as Skunk says, I expected some form of lights.

I expected UV control ( which I guess is a broader but similar feature to drawing parts of an image, as Warren mentioned. )

I didn't expect full pixel and vertex shader support, but I did think there might have been some built in image effects, such as those present in HGE.

Those are simple enough examples, already present in rival products, some of which are also pretty early in development.

It's not that there's anything wrong with what's there, it's just that what's there is very underwhelming.

Looking forward to seeing Bmax getting fixed and signs of the 3D module taking shape, rather than have people like Mark and Skid spending an age writing docs.


Offhand I can name some five dedicated individuals with experience who would like to be part of the team and do it for free.

It's their loss...

the sample code seems to be full of coders trying to show off new features like Methods, extensd or something and doing all kinds of crazy things thats really confusing to someone thats trying to learn the basics of types, arrays and functions.

Too much stuff thrown in my face at once and no point of reference or basic instruction to build up from makes the whole learning process very difficult indeed.

The doc's in the IDE help mean very little to me as they stand, since they don't seem to show examples about how you go about using them, and the samples have no progression from beginner through to advanced.

If I want to learn the basics and shoot bullets from a ship all I find is methods, extends, all intertwined in a fashion that probably makes sence to a programmer with some experience.


Sums up my feelings exactly. Can we have a game or 2 with the basics covered and shock horror without OOP until we get the hang of the language?

please take a look at my ship movement tutorial in the 'tutorials' forum. It uses OOP but I've attempted to document it.

I think the unfortunate thing about OOP is the choice of terminology the Wise old masters decided upon. POLYMORPHISM, come on, what the hell!?
INHERITENCE
OPERATOR OVERLOADING!?!?

These words scare more people away than anything.

OOP is actually very simple and there are some very good tutorials on the web Google for them

here is one I like:
http://sepwww.stanford.edu/sep/josman/oop/oop1.htm

Operator Overloading does not exist anyway

Ok here is something with absolutely no OOP

'        1/5/2005 Bill Radford
'	Spaceship Movement tutorial--  "sans OOP"

Strict					' 'strict' = must declare variables
' VARIABLES
Global GW = 640 			' Graphics Height
Global GH = 480			' Graphics Width
Global GD = 0				' Graphics Depth "0" means Windowed Mode
Global MID_GH = GH/2		' Middle of the screen Height (Y)
Global MID_GW = GW/2		' Middle of the screen width  (X)
Global MX,MY				' Used for Mousex() and Mousey()

Graphics(GW,GH,GD)		' set graphics mode

' VARIABLES
	Global x# = GW/2		' SCREEN X and Y POSITION (initially the middle)
	Global y# = GH/2
	Global xint:Int			' x,y integers fot neater screen printing
	Global yint:Int
	Global name:String			' string contains the text name of player
	Global life = 100			' life force (defaults to 100)
	Global entity				' a placeholder for the image of the actor
	Global angle#				' angle# = 0 to 360 degrees
	Global velocity#			' speed of the actor (forward momentum?) 		
	Global angular_velocity#	' rotational speed, i.e. how fast it spins
	Global angular#,thrust#
	Global friction# = 0.99		' Friction slows down the actor slightly each frame
	Global rotfriction# = 0.97	' slows down the rate of spin slightly each frame
		
' Create the ship image
entity = CreateImage(64,64,DYNAMICIMAGE)
	SetColor 255,255,0
	SetLineWidth 3
	DrawLine 0,64,32,0
	DrawLine 32,0,64,64
	DrawOval 24,16,16,16
	GrabImage entity,0,0
	SetImageHandle(entity,32,48)
	
' MAIN LOOP
Repeat
	Cls				' Clear the screen
		' check controls
		angular# = 0 ; thrust# = 0 ' RESET to 0 for this frame
		
		' CHECK KEY INPUTS and 
		If KeyDown(KEY_LEFT) Then angular# = -0.1
		If KeyDown(KEY_RIGHT) Then angular# = 0.1
		If KeyDown(KEY_UP) Then thrust# = .05
		
		' ADD the key input values to the existing velocities
		angular_velocity# = angular_velocity# + angular#
		velocity# = velocity# + thrust#
		' SUBTRACT the effect of FRICTION from the velocities
		angular_velocity# = angular_velocity# * rotfriction#
		velocity# = velocity# * friction
		
		' Calculate the direction of travel (angle is 0-360 degrees, the SIN and COS will return a value
		' between -1.0 and +1.0
		x=x+(velocity*Cos(angle-90))
		y=y+(velocity*Sin(angle-90))
		
		   ' Turn the ship
		
		angle#:+angular_velocity
			If angle#<0.0 Then angle#=360.0
			If angle#>360.0 Then angle#= 0.00
						
			' If the actor goes off screen, WRAP to other side
			If x>GW Then x = 0 
			If x<0 Then x = GW
			If y<0 Then y = GH 
			If y>GH Then y=0

		' show
		xint = x ; yint = y
		
		SetRotation(angle)			' turn spaceship to current angle
		DrawImage(entity,x,y)
		' show text attributes
		SetTransform(0,1.1,1.1) 
		SetColor 0,0,255
		DrawRect x-44,y+30,96,15
		SetColor 255,255,0
			DrawText "x="+xint+" y="+yint,x-40,y+32
			DrawText "Velocity = "+velocity,x-40,y+48

	Flip				' display the backbuffer (flip to front buffer)
Until KeyHit(KEY_ESCAPE)


I wonder why people who are familiar with types are having such a hard time extrapolating that understanding to classes. There's not THAT much difference (in BlitzMax) aside from the addition of methods/functions.

What is the mental block here?

If you understand how to declare a type and instantiate instances of it ... you're 75% of the way there. You don't need to know any OO terminology, you just need to add a few more things to your mental bag of tricks (methods/functions and an understanding of how a TList works). With those few elements added, you can be productive in BlitzMax within an hour of buying it.

Can we stop the silly moaning about the 2D module?

Given that some pretty amazing commercial games have been written in BlitzBasic and BlitzPlus which have far fewer features than the Max2D module, I don't think that it is exactly limiting.

hehe it is just working a little different than the old one did.
I think after all get used to it the results will become as superb as Tea Virus small lightblend sample

Offhand I can name some five dedicated individuals with experience who would like to be part of the team and do it for free.

It's their loss...


Why don't they write an alternative module and release it into the public domain? That's why the standard modules are all open sourced, anyway. Max is designed to be extended by the public.

Actually, I'm guessing that those individuals you mention are already in the process of writing their own modules, and are too busy to moan.

I wonder why people who are familiar with types are having such a hard time extrapolating that understanding to classes. There's not THAT much difference (in BlitzMax) aside from the addition of methods/functions.

What is the mental block here?

Conceptually, it's easy. In practice, it's not so easy. It requires a very different code organization. And some things that are super easy in a straightforward, non-OOP solution, tend to get messy and awkward when you OOPify them. This is why there are entire books about design patterns and wacky-seeming concepts like class factories and so on. The trick is in getting people to use OOP where it makes sense and not going overboard. New programmers tend to make a mess with OOP.

Can we stop the silly moaning about the 2D module?

Given that some pretty amazing commercial games have been written in BlitzBasic and BlitzPlus which have far fewer features than the Max2D module, I don't think that it is exactly limiting.


No we can't. If I'd wanted to use BlitzBasic or BlitzPlus, I'd have stuck with them ( since I already own both. ) Compared to rival products in the same price range, the 2d module is extremely basic. If you're sufficiently impressed with it, that's great. I won't tell you not to share that you're impressed, so try to show me the same respect.

some highlights for me are:

* stability - blitzmax seems solid so far.
* small executables thanks to modules
* flexible and low-level access
* very expandable thanks to modules
* fast!

If I'd wanted to use BlitzBasic or BlitzPlus, I'd have stuck with them

It depends on what you view BlitzMax as. I think the BRL viewpoint is that Blitzmax is, at least initially, an upgrade over previous versions of Blitz in the following two areas:
1) Cross-platform-ness
2) Improved Language constructs / OOP
And it is these two things that they have decided to focus on. Having reached a point where the core language and 2d engine are roughly equivalent to Blitz Basic, they have decided to release it *on the Mac*.

BlitzMax is not an upgraded 2d language compared to other versions because it isn't intended to be. It isn't even officially released on PC yet (it's beta!), so it's not entirely fair to compare them.

I'm not discounting your requests as invalid - I'm sure they'd be useful additions. I'm just saying that they were never BRL's focal points during development, so it's not entirely surprising that they're not vastly different from what us as PC users already know.

Thanks bradford - but you didn't use types! I'm sure they're not that difficult to understand. But there seems to be various ways of accessing them judging by some of the code posted here and what exactly is a tlist?

What is the best way of setting up and accessing types in the standard Blitz Plus/3d way?

Ok. Sorry to be confusing. What we have are 2 different ways to achieve (almost) the same effect.

These are not necessarily the "right" way, Just "My" way.

1. Spaceship moving with NO OOP, NO Types whatsoever
2. Spaceship Movement with OOP

NO OOP
'        1/5/2005 Bill Radford
'	Spaceship Movement tutorial--  "sans OOP"

Strict					' 'strict' = must declare variables
' VARIABLES
Global GW = 640 			' Graphics Height
Global GH = 480			' Graphics Width
Global GD = 0				' Graphics Depth "0" means Windowed Mode
Global MID_GH = GH/2		' Middle of the screen Height (Y)
Global MID_GW = GW/2		' Middle of the screen width  (X)
Global MX,MY				' Used for Mousex() and Mousey()

Graphics(GW,GH,GD)		' set graphics mode

' VARIABLES
	Global x# = GW/2		' SCREEN X and Y POSITION (initially the middle)
	Global y# = GH/2
	Global xint:Int			' x,y integers fot neater screen printing
	Global yint:Int
	Global name:String			' string contains the text name of player
	Global life = 100			' life force (defaults to 100)
	Global entity				' a placeholder for the image of the actor
	Global angle#				' angle# = 0 to 360 degrees
	Global velocity#			' speed of the actor (forward momentum?) 		
	Global angular_velocity#	' rotational speed, i.e. how fast it spins
	Global angular#,thrust#
	Global friction# = 0.99		' Friction slows down the actor slightly each frame
	Global rotfriction# = 0.97	' slows down the rate of spin slightly each frame
		
' Create the ship image
entity = CreateImage(64,64,DYNAMICIMAGE)
	SetColor 255,255,0
	SetLineWidth 3
	DrawLine 0,64,32,0
	DrawLine 32,0,64,64
	DrawOval 24,16,16,16
	GrabImage entity,0,0
	SetImageHandle(entity,32,48)
	
' MAIN LOOP
Repeat
	Cls				' Clear the screen
		' check controls
		angular# = 0 ; thrust# = 0 ' RESET to 0 for this frame
		
		' CHECK KEY INPUTS and 
		If KeyDown(KEY_LEFT) Then angular# = -0.1
		If KeyDown(KEY_RIGHT) Then angular# = 0.1
		If KeyDown(KEY_UP) Then thrust# = .05
		
		' ADD the key input values to the existing velocities
		angular_velocity# = angular_velocity# + angular#
		velocity# = velocity# + thrust#
		' SUBTRACT the effect of FRICTION from the velocities
		angular_velocity# = angular_velocity# * rotfriction#
		velocity# = velocity# * friction
		
		' Calculate the direction of travel (angle is 0-360 degrees, the SIN and COS will return a value
		' between -1.0 and +1.0
		x=x+(velocity*Cos(angle-90))
		y=y+(velocity*Sin(angle-90))
		
		   ' Turn the ship
		
		angle#:+angular_velocity
			If angle#<0.0 Then angle#=360.0
			If angle#>360.0 Then angle#= 0.00
						
			' If the actor goes off screen, WRAP to other side
			If x>GW Then x = 0 
			If x<0 Then x = GW
			If y<0 Then y = GH 
			If y>GH Then y=0

		' show
		xint = x ; yint = y
		
		SetRotation(angle)			' turn spaceship to current angle
		DrawImage(entity,x,y)
		' show text attributes
		SetTransform(0,1.1,1.1) 
		SetColor 0,0,255
		DrawRect x-44,y+30,96,15
		SetColor 255,255,0
			DrawText "x="+xint+" y="+yint,x-40,y+32
			DrawText "Velocity = "+velocity,x-40,y+48

	Flip				' display the backbuffer (flip to front buffer)
Until KeyHit(KEY_ESCAPE)



OOP inside
[codebox]
Rem
        1/3/2005 Bill Radford
	Spaceship Movement tutorial--  Version 2 "A Little More OOP"
	In this episode I am incorporating some ideas and insights
	from fellow BlitzMAXers to make the code a little more OOPy.
	
	Significantly, We added a function called create that will act
	as sort of a "Spaceship Object Factory".  We also are using a
	LINKED LIST to hold our objects.
	
	Thanks to PERTURBIO for the key-binding and check controls methods as
	well as other OOP enhancements

End Rem


Strict					' 'strict' = must declare variables
' VARIABLES
Global GW = 800 			' Graphics Height
Global GH = 600			' Graphics Width
Global GD = 0				' Graphics Depth "0" means Windowed Mode
Global MID_GH = GH/2		' Middle of the screen Height (Y)
Global MID_GW = GW/2		' Middle of the screen width  (X)
Global MX,MY				' Used for Mousex() and Mousey()

Global ship_list:Tlist = CreateList()		' create a list to hold our ship objects
Local ship:player							

Graphics(GW,GH,GD)		' set graphics mode

Rem 
	create an actor type that possess attributes that can be used by may different
	game characters. Player, enemy, Wizard, etc... 

	The Type "ACTOR" is the beginning of our Object Oriented Programming (OOP)
	Actor is a Class or Type.  It simply is a definition of what an "actor" is.
	the Fields can also called Attributes.  for example, an actor has the x#,y# 
	Fields that will hold the screen x,y coordinates that tell BMAX where to draw
	it.  the actor class also has "Methods". Methods are functions that are unique
	to that class.  the "update" method, for instance, will only work for the actor
	class.
	
	  	
End Rem 



Type actor
					' 
	Field x# = GW/2			' SCREEN X and Y POSITION (initially the middle)
	Field y# = GH/2
	Field xint:Int			' x,y integers fot neater screen printing
	Field yint:Int
	Field name:String			' string contains the text name of actor
	Field life = 100			' life force (defaults to 100)
	Field entity				' a placeholder for the image of the actor
	'
	Field angle#				' angle# = 0 to 360 degrees
	Field velocity#			' speed of the actor (forward momentum?) 		
	Field angular_velocity#	' rotational speed, i.e. how fast it spins
	Field friction# = 0.99		' Friction slows down the actor slightly each frame
	Field rotfriction# = 0.97	' slows down the rate of spin slightly each frame
		
	Method applyImpulse#(angular#,thrust#=0.0)
		' add the rotational and/or thrust to the velocities
		' these are taken from key inputs. see below
		
		angular_velocity# = angular_velocity# + angular#
		velocity# = velocity# + thrust#
	End Method
	
	Method update()
			Rem
			 This method calculates the velocity of the ship as well as the 
			 angle. It uses the SINE and COSINE of the current ANGLE to 
			 determine the direction the ship should travel. The ANGLE is between
			 0 and 360. 
			 both velocities (rotation and forward) are multiplied by a friction
			amount that will slow the ship down each frame
						
			End Rem
			
			angular_velocity# = angular_velocity# * rotfriction#
			velocity# = velocity# * friction
			
			' move the ship forward
			x=x+(velocity*Cos(angle-90))
			y=y+(velocity*Sin(angle-90))
		
		   ' Turn the ship
		
			angle#:+angular_velocity
				If angle#<0.0 Then angle#=360.0
				If angle#>360.0 Then angle#= 0.00
						
			' If the actor goes off screen, WRAP to other side
			If x>GW Then x = 0 
			If x<0 Then x = GW
			If y<0 Then y = GH 
			If y>GH Then y=0
				
	End Method
	
	Method show()
		' This Method is used to draw the current frame of the ship
		' as well as the print the x,y and velocity values to the screen
		xint = x
		yint = y
		
		SetRotation(angle)			' turn spaceship to current angle
		
			DrawImage(entity,x,y)
		
		SetTransform(0,1.1,1.1) 
		SetColor 0,0,255
			DrawRect x-44,y+30,96,15

		SetScale 1,1
		SetColor 255,255,0
			DrawText "x="+xint+" y="+yint,x-40,y+32
			DrawText "Velocity = "+velocity,x-40,y+48
		
	End Method
	
	
	
End Type 

Rem  

	Now we create an extended Type called Player.  Type Player will INHERIT all of the
	attributes and methods of actor, as well as add a new field of its own, inventory.
	the [] at the end indicate an array.  inventory is an array of strings.


End Rem


Type player Extends actor
	
	
	Field inventory:String[]
	Field _KEYLEFT = KEY_LEFT 
	Field _KEYRIGHT = KEY_RIGHT
	Field _KEYUP = KEY_UP
	Field _KEYDOWN = KEY_DOWN
	
	Method SetKey(KeyName:String, KeyVal:Byte)
		Select Lower(KeyName)
			Case "left"
				_KEYLEFT = KeyVal
			Case "right"
				_KEYRIGHT = KeyVal
			Case "up"
				_KEYUP = KeyVal
			Case "down"
				_KEYDOWN = KeyVal
		End Select
	End Method
	
	Method GetKey(KeyName:String)
		Select Lower(KeyName)
			Case "left"
				Return _KEYLEFT
			Case "right"
				Return _KEYRIGHT
			Case "up"
				Return _KEYUP
			Case "down"
				Return _KEYDOWN
		End Select
	End Method
	
	Method CheckControls()
		If KeyDown(_KEYLEFT) Then applyImpulse(-0.1)
		If KeyDown(_KEYRIGHT) Then applyImpulse(0.1)
		If KeyDown(_KEYUP) Then applyImpulse(0,0.04)
	End Method
	
	Function Destroy(pname$)
		Local temp:Player
		For temp:player = EachIn ship_list
			If temp.name = pname$
				Release temp
				FlushMem
				Return True
			endif
		next
		Return False
	
	
	End Function
	
	' This is a unique type of function.  when called, this function will create a new instance
	' of PLAYER. Since functions can be called when there are no existing instances, they can
	' be used for this.  This adds a nice, tidy way to add new instances of our types, along with
	' several attributes (in this case the x,y starting position, name and RGB color)
	
	Function create:player(pname$,pox,poy,red,green,blue)
		Local t:player = New player
		t.entity = CreateImage(64,64,DYNAMICIMAGE)
		t.name = pname
		t.x = pox
		t.y = poy
		SetColor red,green,blue
		SetLineWidth 3
		DrawLine 0,64,32,0
		DrawLine 32,0,64,64
		DrawOval 24,16,16,16
		SetColor 255,255,0
		DrawText pname,32-(Len(pname)*8)/2,20
		GrabImage t.entity,0,0
		Cls ; Flip
		SetImageHandle(t.entity,32,48)
		SetScale 1,1
		
		' NEW - we add this INSTANCE of player to the LINKED LIST called ship_list
		' so we can iterate through them easily later on
		ListAddLast ship_list,t
		
		Return t
	End Function
End Type

Type enemy Extends actor
	Field anger
	
End Type

Rem
	call the player TYPE's function "create" to create a few instances of type "player"
	the we will add them to a LIST

End Rem


' Create INSTANCES of the type player

' This creates the default player
player.create("Bobby",GW-100,GH/2,0,200,0)
' This creates a 2nd player.  Since it will have unique keycodes, we will use a temp variable to reference
' it during the KEY binding setup
Global temp:player = player.create("Kate",100,GH/2,200,0,0)
	temp.SetKey("left", KEY_A)
	temp.SetKey("right", KEY_D)
	temp.SetKey("up", KEY_W)
' now we can release the temp variable
Release temp

FlushMem			' Momma says "Always Flush your Memory" 

#Main_Loop		' This is an identifier

Repeat
	Cls				' Clear the screen
	
	' we now have the player types (the ships) in the Linked List (ship_list)
	' we can iterate through them and get control inputs, update their position and 
	' display them to the screen within a FOR EACHIN loop
		
	For ship:player = EachIn ship_list	' get key inputs to move ship
		ship.CheckControls()
		ship.update()
		ship.show()
	Next
	
	If KeyHit(KEY_SPACE)
		player.destroy("Kate")
	Endif
	
	Flip				' display the backbuffer (flip to front buffer)
Until KeyHit(KEY_ESCAPE) 

[/codebox]

Thanks Bill, I guess using OOP isn't so bad after all and your code is well commented which helps.

If you're bored, bradford, maybe you could do a third example using Classic Blitz style OOP (ie just Types and nothing else)... =]