I am creating a side scrolling game in Flash (as3) and trying to keep things organized and clean.
Ive created a "Level" class that gets all the level data, player data, and creates all the terrain objects and the player object. Its starting to get messy because im handlng all of the functions for player collision checks and player movement, terrain movement, sound starting and stopping, enemies, and more, all in this class. Is this normal? Or is there a better way to organize things to keep them separate, but still allow them to interact with each other.
I have a player class, and terrain class, and enemy class and etc. but there is not much going on inside them.
Thanks/
Sounds like it's time to take a look at how you can break up your level class and move some of that functionality to other classes. What you're describing happens all the time, so don't worry - it just means it's time to reorganize a little.
You might consider taking you player collision for example, and moving that out to a Physics class. You can set up a static function that allows you to pass in two DisplayObjects, and then tests for collisions between the two.
For sounds, you might consider a singleton class like a SoundManager, that holds onto all of your sounds in an array or dictionary, and then have your other classes play sounds through a function like playSound(soundName:String):void on SoundManager.
Hopefully that gives you a start. Feel free to ask if you need more details. It also might help if you post some of your code. Good luck with it!
Without getting too much into object-oriented design principles here, my advice would be to ask yourself "What belongs in a class named X".
So for example, it sounds like the Level class should keep track of the players, enemies, and terrain on that... well, level (perhaps map or stage might be a better name?). But it doesn't need to do all the work for those objects; many of the functions that do the work for movement, collisions, sound, etc. can be moved to those other classes. Then the Level becomes an orchestrator; kind of like a conductor leading the music (but not actually playing the violins, horns, etc.).
Also, it sounds like players, terrain, and enemies have quite a lot in common. For example, they all need movement and collision handling. You may be able to create a parent class (say GameObject) and have the Player, Terrain, and Enemy classes extend from that. This kind of polymorphism can be very helpful for taking care of common functionality.
Related
I have got one sily question. I write a game in libgdx. But my friend always use actors and sprites. But i dont use this class. In all parts or elements of game i extends Sprite. Then i use a array list for using to save elements.
I write game like that: reading input, update, check collision and render. Its ok or not ?
There is no fixed way to go from A to B in programming. I have made a couple of good functioning games without the use of the stage and sprite class. These classes just help you get things done quicker. So yes you can write good games without the use of actors/sprites. It is even possible to write good games without the use of OpenGL or DirectX and create your own graphics library, but why should we? If you know what Scene2D and the sprite class can do for you it is kinda ignorant to leave them aside if they can help you.
It often takes little time to learn a certain library/extension. Once we know how to use it there will be profit for life.
I started learning libgdx lately and, obviously, I've been looking into several sample games and tutorials.
I couldn't help but notice inconsistencies into how authors/developers choose to design their game classes - especially when it comes to the "renderer" classes.
In some examples, I see some authors relying solely on the "renderer" classes to draw using the SpriteBatch. While others tend to send a SpriteBatch reference to game objects to do the rendering themselves.
For example, considering a Bird class, some would associate it with a Texture type, load it and render the bird inside a Bird.render method. Others load the Texture in separate "Renderer" classes (Like WorldRenderer) and draw the bird texture from there by relying on position parameters such as bird.getX() and bird.getY().
I wrote some sample games using XNA in the past and I used to embed the rendering logic into my game classes. My renderer class used to simply loop over all "enabled" game objects and call "GameObject.render()". Is this a bad practice in libgdx?
It is not about bad practice in libgdx, it's a general opinion oriented problem.
Usually, it's always better if you can separate game logic and rendering logic (preferably in different classes). This way, if you want to change look and feel of the game (re-skin it) later, you won't have to touch the code containing game logic (less testing required, no new bugs).
But not everyone follows this (some might think it as overkill for small things). Having renderer class for each and every small thing might seem too much. So you'd see a lot of code having mixed both rendering and game logic.
If you want to build scalable games, I'd suggest you to follow MVC (game codes so large that developers might get lost). But at the same time, you should be pragmatic enough to know when not to use it (small games taking 2 weeks to make).
So it's for you to decide really, since it's about personal preferences.
Hope this helps.
A lot probably depends if the developer has used MVC (Model-View-Controller) before. In an MVC design the "game" objects like bird are part of the model and don't directly have anything to do with the display(view). Sometimes it depends on the technologies being used, for instance the LibGDX Scene2d API warns you that "Scene graphs have the drawback that they couple model and view".
In a worldRenderer you should render all your objects. All your objects belongs to a world so it makes sense. A benefit to add attention to is that you can always keep all gameObjects in separate arrays aswell as in a big array (containing all).
Array: GameObjects
Array: Birds (also in GameObjects)
Array: Cows (also in GameObjects)
Array: Cats (also in GameObjects)
This makes it possible for you to decide on what "z" axis all gameobjects should rely on (render) aswell as just loop through them all right away (update)
My questioin is pretty much in the title, Why do I keep reading in actionscript 3.0 that its a good idea to seperate the 'mind' from the 'object' when writing code?
Thanks for any help, this is confusing the hell out of me.
If you're asking why graphics are separated from the positioning, movement and physics; take this tree I've drawn:
In the tree you'll see that Entity has two properties:
Graphics - what the entity should look like.
Body - where the entity should be.
Moving down, you will see that there are several things that extend Entity - most notable are the Player and the Enemy classes.
Extending my Entity class above, I can easily change what should be used as the graphics and also provide slightly different bodies. For example, the player and enemies will have obviously different appearances, and the Tree class won't need to use a Body that deals with values like velocity because it doesn't move.
Here are some advantages of the above:
We can create entities that don't have graphics, saving performance and memory.
We can use different types of graphics rather than having to stick to MovieClip if you had extended MovieClip with your Entity class.
We can add additional logic into the Graphics class such as being able to easily covert a Sprite or MovieClip into a sprite sheet for better performance.
The graphics will be easier to manage and more lightweight (as opposed to if it were auto-bundled with each entity).
Physics will be easier to deal with without needing to know about graphics.
The Body can be updated without immediate effects on the graphics.
Your understanding of physics being completely unrelated to appearance will improve significantly.
I'm trying to create a multi-level dungeon adventure in Flash CS4. The layout is an instance created of a symbol called Level, within the symbol are multiple wall subsymbols (wall), instances of Wall. There is a collision routine to stop the player walking through the walls, called from Wall.As.
Level is drawn about the centre point (0,0).
When I create an instance on the stage of Level (level), the collision tester is using the xy coordinates for the walls drawn about 0,0, not the "real" xy where it's appearing on the stage.
So what I need to know, is how to "update" the xy for each wall subsymbol with the live stage information, overriding the XYs drawn in the parent. It has to be updated unfortunately (I can't keep it static), as the levels are big so have to scroll.
Thanks for your advice.
With all due respect forget your approach, you're reinventing the wheel for nothing and probably to end up getting worse performance. What you need is pixel-perfect collision detection and probably including basic physics so already we're talking a huge amount of work. If you want to build levels in a design way for a game, use this, it'll blow your mind how awesome/easy/cool this is:
http://www.gotoandlearn.com/play.php?id=135
Its always a guess when trying to answer questions like this, as there are a lot of unknowns. That being said, in programming, there are always more than a few ways to solve a problem. Examine your collision detection routine - if you worked with hitTestPoint, and the point that was being tested (mouseX,Y or your main actor) with localToGlobal, you likely wouldn't need to test for the x,y variables of your collision objects. Read up on those two subjects and this question might be rendered moot.
At any rate, you could update relative coordinates in your Wall.as instance by leveraging globlaToLocal:
public function get curLoc():Point
{
return globalToLocal(new Point(this.x, this.y));
}
and retrieve them from your parent class as a point you can then test against:
trace(_wall.curLoc);
Hope that helps
I suppose you could accomplish what you're trying to do by manipulating the transform property of the wall symbols, but honestly I would concur with Ascension Systems and just abandon your collision testing routine for something different.
You may not need to go all out with a physics engine for your game, in which case just use hitTestObject to do the collision detection.
Currently I'm writing an app. If I want to avoid Singletons, do I have to simply pass references of everything around?
For example,
I have a "main" class.
Class: Main
+---- Screen
+---- Camera
+---- Terrain
+---- Vehicle
+---- PhysicsWorld
It contains my Camera, Terrain, and Vehicle,etc classes. Now, I have issues when I'm creating say, the Terrain object. Terrain wants to access Main classes Screen object so it can add its Terrain Graphics to the screen. It also wants to know about the Camera object for when it is drawing so it knows what scale to draw it. It also wants to know about my PhysicsWorld object so it can add itself to the physics engine.
Do I have to always lug these objects back and forth between constructors? I mean, when I create a Terrain object, do I simply have to pass around my screen object, my physicsWorld, camera, etc?
Another random scenario I have, is now.. inside my Vehicle class I need to call a Restart() method on my Main class. Does this mean I have to pass an instance of main to Vehicle? Really??
It feels cumbersome to constantly have to pass 4-5 things to my classes, especially in my scenario now where almost every in-game object I have needs a screen, physics, camera info, etc.
Any suggestions?
It feels cumbersome to constantly have
to pass 4-5 things to my classes,
especially in my scenario now where
almost every in-game object I have
needs a screen, physics, camera info,
etc.
Then the correct question to ask is "why do I need all 5 objects in all my classes?"
Why on Earth does every in-gmae object need any of the mentioned things? An in-game object needs a position and whatever it needs to process its behavior. Then a separate renderer can, you know, render, the object. Which means that only the renderer needs the camera info and screen.
The physics could go either way. You could have a separate physics entity which updates the game object, or you could pass that physics object to every game object. But even if you do pass that around, we're down to one out of the three objects listed. :)
That's why globals and singletons are often best avoided. They disguise your dependencies so you end up with far more dependencies between your objects than you actually need. And then it becomes almost impossible to remove the globals.
However, if you do stick with globals, do yourself a favor, and at least avoid singletons. You don't need the additional constraints enforced by a singleton.
Terrain wants to access Main classes
Screen object so it can add its
Terrain Graphics to the screen. It
also wants to know about the Camera
object for when it is drawing so it
knows what scale to draw it. It also
wants to know about my PhysicsWorld
object so it can add itself to the
physics engine.
The terrain object needs to know one thing: What is the terrain like. Someone else can take responsibility for rendering it. That someone will need to know about the camera, screen and terrain graphics, sure, which suggests that the same object might plausibly be able to do other tasks involving these objects (such as other rendering tasks).
Why should the terrain care about what scale it's drawn in? It needs to know the scale ingame, but not the scale in camera-space. And why can't someone else add the terrain to the physics engine? The main function might be able to do that, even. Create terrain, create physics engine, register terrain with physics engine, start game.
I don't know ActionScript, but assuming variables are passed by reference, the least you could do is construct a 'Environment' class holding Camera, Screen, Terrain, PhysicsWorld which you pass to the instances.
I have the exact same problem (also in actionscript 3, coincidentally).
I have been working on an RTS for flash and had found myself needing to pass around large numbers of references to each new class (e.g., gameGrid, currentSelection, visibleUnits, etc.).
I eventually realised that what I really should be doing is to have every class maintain it's own properties, and instead pass around references to these classes, (well objects).
But anyway, now what I'm doing is having static variables containing references to commonly used objects such as the main stage, interface, engine and display area inside a class called RTSGlobals. I'm also putting constants such as the screen size in there.
I know this doesn't really answer your question, but I figure sometimes it is worth ignoring a bit of OOP good practice in favour of an efficient solution.
If someone has a does have a good practice solution though, please tell :)
I suggest you take a look at XNA's samples projects (google it). They're well designed and might give you some hints.
Also, since you're using AS3, you could use the event system to dispatch message to other entities. For example, instead of passing your Main to your Vehicle class, make your Main (or whatever else interested) a listener of your Vehicle class. Then, let's say the car crash and you want to restart the game, dispatch an event, for example CAR_CRASHED. The listeners of your car should do something based on this message. If you want to understand the event system, type EventDispatcher, highlight it and hit F1 in your Flash IDE.