OOP Project easily expandable

BlitzMax Forums/BlitzMax Programming/OOP Project easily expandable

SillyPutty

(Posted 2005) [#1]

Hi all, I have been getting really bogged down lately trying to tie proper OOP methods in such a way as to be a helper in my projects instead of a hinderance.

I really want to try make solutions that are easily expandable, and easily configurable so as to actually start finishing projects. I abhor procedural programming as it always starts getting clunky and not maintainable.

I would just like to know if my below code is on the right track, and advice and criticism is welcome, I really want to start taking a step in the right direction. Please could you help me.

I have a TEntity as you will see, which could hopefully be all objects in a game, and the main TApp, is this the right way of looking at things ?

It was just a simple test, not a fully fledged solution or final app.

'This application was written with BLIde <a href="http://www.blide.org" target="_blank">http://www.blide.org</a>
'Application: Simple	
'Author:  Erick Grove
'Description: Simple OOP Test
'
Strict                       
         
Type TEntity
	Field x:Int
	Field Y:Int
	
	Method Init(x:Int,Y:Int) abstract
	Method Update() abstract
	Method Draw() abstract
	
End Type

Type TPoint Extends TEntity
	                          
	Method Init(xpos:Int,ypos:Int)
		x = xpos
		Y = ypos
	End Method	                       
	                       
	Method Update()
		
	End Method
	
	Method Draw()
		DrawRect x,Y,2,2 
	End Method
	
End Type

Type TApplication    
    Global MyApp:TApplication
    Field EntityList:TList
	Field width:Int
	Field Height:Int
	Field depth:Int     
	Field AppName:String  
	
	Function Create(width:Int,Height:Int,depth:Int,AppName:String)
		 If MyApp = Null Then MyApp:TApplication = New TApplication
		 MyApp.width = width
		 MyApp.Height = Height
		 MyApp.depth = depth
		 MyApp.AppName = AppName
		 SetGraphicsDriver GLMax2DDriver()         
		 AppTitle = AppName
		 Graphics MyApp.width,MyApp.Height,MyApp.depth
	End Function	
    
	Method AddEntity(ent:TEntity)
		If EntityList = Null Then EntityList = New TList
		EntityList.AddFirst(ent)
	End Method

	Method GetWidth:Int()
		Return width
	End Method
	                
	Method GetHeight:Int()
		Return Height
	End Method       
	
	Method GetDepth:Int()
		Return depth
	End Method
	       
	Method UpdateAll()
		For Local Entity:TEntity=EachIn EntityList
			Entity.Update()
			Entity.Draw()
		Next
	End Method
	
	Function Update()
		
		While not KeyDown(KEY_ESCAPE)
			
			DrawText "Application: " + MyApp.AppName + "Running",10,10
			If MyApp.EntityList <> Null Then MyApp.UpdateAll()			
			
			FlushMem
			
			Flip
			Cls
		Wend
		
	End Function
	
	Function CleanUp()
		              
		For Local ent:TEntity=EachIn MyApp.EntityList
			MyApp.EntityList.Remove(ent)
			ent=Null
			FlushMem
		Next        
		
	End Function
	
End Type                         
                                                                

TApplication.Create(640,480,0,"Erick Test")   

For Local i:Byte=0 To 300
    Local point:TPoint = New TPoint
	point.Init(Rnd(640),Rnd(480))
	TApplication.MyApp.AddEntity(point)
Next


TApplication.Update()
TApplication.CleanUp()

SillyPutty

(Posted 2005) [#2]

Can any of you OOP experts please take a look at this for me and maybe impart some knowledge ?

I just really wanna know if I am on the right track here.

Indiepath, Fredborg, Wave, anyone ? :)

FlameDuck

(Posted 2005) [#3]

Looks pretty good. One thing I would do differently is move the main loop outside the Update() Method.

SillyPutty

(Posted 2005) [#4]

thanks for the reply FlameDuck, I forgot to mention you above as well as others, cause you guys know your @#!* :)

What is the reason why you would prefer the main loop outside ? Would it be easier to maintain outside ?

LarsG

(Posted 2005) [#5]

".. and One Type to rule them ALL!!!"

SillyPutty

(Posted 2005) [#6]

lol @ LarsG

SSS	(Posted 2005) [#7]

[edit] double post... noooooooooooooo

SSS	(Posted 2005) [#8]

that looks good,
the one change that I might make, simply because I'm a very lazy individual, is to add something like this to the New() method of TEntity:

Type TEntity
	Field x:Int
	Field Y:Int

        Method New()
           if TApplication.MyApp then TApplication.MyApp.AddEntity(Self)
        End Method


	Method Init(x:Int,Y:Int) abstract
	Method Update() abstract
	Method Draw() abstract
	
End Type

you would of course need to have an application created but I can't see why you'd be making entities before then anyway. other than that it looks nice.

SillyPutty

(Posted 2005) [#9]

SSS excellant idea there ! I will definately implement that, thanks so much !

SSS	(Posted 2005) [#10]

In retrospect, one last thing that I might do is add a Dereference() method to your TEntity object. This would just remove that entity from the application's list. Once again, this wont change anything except for how you delete your objects, I just find the method slightly cleaner

SillyPutty

(Posted 2005) [#11]

ok, will look at that :) *EDIT - added and works like a charm :)

So in general, you think this is a good system of managing a game app ?

Robert Cummings

(Posted 2005) [#12]

Nope.

The only thing that will finish your game is hard work. No amount of OO is going to help you.

Most projects don't get finished no matter what language or techniques they use.

EVERYTHING gets bogged down in the end including OO and abstracted-to-hell stuff.

Just do it, and get on with it, and always comment the hell out of things, then you won't get lost and give up.

SillyPutty

(Posted 2005) [#13]

I do agree with the hard work story, but well designed code can get you a long way.

I am merely asking from a managing point of view, managing entities in the game, I am looking for a robust solution, that can "help" me.

Ofcourse I can just jump in and code like a mad-hatter, but often it starts getting messy, you cant maintain it well, and very difficult to add new features.

A well designed structure of an app, will make life a whole lot easier.

I would rather code in OO than make a complete messy app precoderual or wrongly implemented OO

Tibit

(Posted 2005) [#14]

I think your style is really nice. What you want to accomplish is the possibility to reuse code and to Never need to duplicate code. So if you have two different types with duplicate methods try to derivate them from the same type, and let them inherit that method. In that way you can change the method for both these types if you ever want to change it. Also consider implementing vectors and deltatime. A tip if you want to change something, like an update method in point, is that you could copy and rem the current method. In which you have the backup if the new way don't work as planned. And even if you can make things very Abstract with OOP try not to. Most times you can make the code more intuitive; more self explanatory. Even if the code is trival add a comment on what the method or type is supposed to do. It's worth it!

I would have a Create or Spawn function in the point entity, which would allow you to create points for example on one line: Point.Create( X, Y ).

You can have the initiation stuff in a Initiate() or Start() method in Application. Including the stuff required to exit the application. TApplication.Update()
TApplication.CleanUp(). I see no wrong in having the application stuff separated, perhaps even in a separate file. You are not very likely to change that code that often anyway. And if you would like to change that part, copy the whole file.

__________________________________________________________________________________________________
Extra Note: Actually I'm right now working with a new OOP approach. It's crazy as hell but I can also reuse or change ANY part of my code independently. I'm yet to see if the system will work in bigger projects. I got the idea from this article: Object-Oriented Game Design - A modular and logical method of designing games . I'm not saying that it is the perfect way to do it! I'm myself trying it out in a smaller implantation to see how it scope. I'm only following the article to 20%. The overall idea is that methods and fields in your types could be types. Any action requires a set of states. If an entity have these states they can use the action. In this way you can design actions ( ex:AI ) totally independent from the game. Because every game do have similarities a lot of code can be reused all the time, even inside the same game! It's still an experimental approach, interesting read but NOT a complete OOP technique that works.

SillyPutty

(Posted 2005) [#15]

@Wave
awsome, thanks for the advice, and will take it to heart :)

your beginners guide inspired me to try my OOP test :)

Your OOP style is really cool btw, and I read it often to make sure I am soaking it all up.

FlameDuck

(Posted 2005) [#16]

What is the reason why you would prefer the main loop outside ?

So that Update() isn't a 'blocking' call. Also it will allow you to expand the application easilly my adding other objects and their respective update() methods.

Would it be easier to maintain outside ?

Maybe. It depends on what kind of maintenance cycle you're planning. Generally, I'd say it's a win/win situation.

SillyPutty

(Posted 2005) [#17]

ok - noted :)

Thanks FlameDuck.

Tibit

(Posted 2005) [#18]

Thanks, I'm glad it helps :)

Still if anything is an entity they will automatically have their update method called I.E. you can simply inherit entity if you want to have an object that you want to update. Also remember that even a button in your GUI can and should also be of the entity type. You could also consider having types/objects that deal with resources, so that you can use images/sounds even if they are not yet done, in which way a Temp_image of the same size is loaded or used instead. It is very practical when you start to add "real" content to the game. Another way is to have a draw method in Entity (or higher up), so in case the Image in Car is null; Super.Draw() - which draws using the built-in graphics.