I finally found a use for Linked Lists! The following snippet is the entire (current) "do" block for my particle handler.
I'm not sure I'm going to keep the architecture or not, but right now it's lightweight enough that it shouldn't be much effort to change later. And either way, since the particle handler is going to be dealing with (possibly) massive amounts of quick insertions and deletions, Linked Lists are (for once) an ideal choice, I think. Constant time for, literally, every operation I will need to use them for, except for iterating through every particle, which will be linear time regardless of which data structure I choose to use.
LinkedListNode<Particle> node = activeParticles.First;
LinkedListNode<Particle> tmp;
while (node.Next != null) //Go do all the particles for this frame
node.Value.doThis(pack);
node = activeParticles.First;
while (node != null) //Loop through all the active particles again, to test relevance.
{
if (!node.Value.testRelevance(pack)) //If a particle is no longer relevant, remove it from the active particle list
{
switch (node.Value.Type)
{
case ParticleType.Activator: //Only one of these ever.
tmp = node.Next;
activeParticles.Remove(node);
node = tmp;
break;
case ParticleType.Decoration:
tmp = node.Next;
activeParticles.Remove(node);
inactiveDecorations.AddFirst(node);
node = tmp;
break;
case ParticleType.Projectile:
tmp = node.Next;
activeParticles.Remove(node);
inactiveProjectiles.AddFirst(node);
node = tmp;
break;
}
}
}
When it comes to particles and their potentially massive creation/deletion rate, let me suggest a further enhancement - use a pool. When a particle expires, instead of deleting it and adding a new one, just call a "reset" method that initializes its values. That way you only ever allocate memory the first time a particle is created, and never more than the max you'll ever see on screen.
When it comes to particles and their potentially massive creation/deletion rate, let me suggest a further enhancement - use a pool. When a particle expires, instead of deleting it and adding a new one, just call a "reset" method that initializes its values. That way you only ever allocate memory the first time a particle is created, and never more than the max you'll ever see on screen.
I am indeed pooling them. Or rather, my method so far is to start with an empty pool, and when a particle becomes irrelevant, it gets put into an inactive pool, from which any new particle creation will first draw, if available.
Are the active and inactive pools separate lists? That seems unnecessary, but I guess under the hood it's just shuffling pointers around so it's probably not a big performance knock or anything. My typical approach was store the "time until death" of each particle, iterate over all of them, and only update/draw the ones that hadn't died.
But I guess then I had to iterate over the whole list when I was finding a particle to reset, so now that I think about your way is probably better!
Something that bloggers, media, and the internet at large have chastised Microsoft for is the fact that it is not possible to write XNA games anymore. This is 100% correct. However what many people forget is that XNA is still fully possible on Windows 8 as a desktop application. Yes, that won’t console many people, but regardless, support hasn’t magically vanished.
Secondly, and this is the most important point of this article: It is still possible to make an XNA game or port your existing XNA game to a Windows Metro app. That game will run on both x86 and ARM devices. Microsoft has left us in the lurch – and somewhere deep deep down, I am sure they have a good reason – but all hope is not lost.
Enter: MonoGame.
XBL - ArchSilversmith
"We have years of struggle ahead, mostly within ourselves." - Made in USA
Yeah, I don't quite understand why they're dropping XNA completely, but then again, they appear to be anticipating quite a bit of pushback on Win8's Metro BS, so, who knows?
Has anyone had an experience doing 2D stuff in Unity? My friends say it's quite possible, but I've never been able to even get started.
I haven't done anything 2d in unity, but you could just set up an orthographic camera and then lock everything to 1 plane.
That's what someone suggested, basically just lock the camera straight down and set everything on one plane, maybe use alpha plus a bit of Z axis movement to handle layers and parallax scrolling et all. It still seemed extremely obtuse.
I know this comment was from last month, but my first game was 2D and written in Unity, and it didn't seem obtuse to me. Probably the biggest stumbling block early on was in creating mesh planes...they would start out horizontal by default, so I had to flip them round the x axis to see them. I've obtained some code and plugins that have helped with that process since then.
CreatePlane - A nice wizard interface for creating very efficient mesh planes. I set the width and length, then set the plane to "Vertical" (which spins it on the x axis automatically)
Kinda tough to set everything on one plane (unless you meant "axis"), depending on the type of game you're writing. I have many planes with sprites attached to them, set at various z levels for layering. Camera is set to orthographic, and the camera size should be set to half your target screen height (mine is frequently "480", since iPhone 4 was 640x960).
Sprite Manager 2 - I know it costs a good chunk of change, and there are other sprite animation packages out there for Unity, but it's worked fairly well for me. It really keeps the draw calls down, which is crucial for mobile devices.
iTween - I use iTween to do almost all of my object movement in-game. Very simple to use, and fairly powerful. Most times, I only have to write 1 line of code to get the effect I'm looking for. When I need to write more, I just have to send iTween a hashtable of settings.
I was wary about writing a 2D game in Unity, but just like anything else, once you're used to it it's fairly straightforward. And the advantage of multiplatform builds is hard to ignore, in my opinion. 8)
And I decided to start learning Unity instead. (This learning began a few days ago while on a Disney cruise vacation with my parents. Lounging around on a huge boat is a surprisingly programming-friendly environment, and really great for inspiration.)
Anyway, I just had one of those "I'm the worst programmer" moments while trying to make 2D-appearing physics work in Unity.
When using an orthographical camera such that you can't perceive the Z axis (i.e., it looks like a simple 2D world with a vertical X axis and horizontal Y axis), and you don't want objects to rotate in a way that wouldn't make sense in a 2D world, you want to (1) freeze movement along the Z axis and, (2) unintuitively, freeze rotation along the X and Y axises as well! I kept trying to freeze rotation along the Z axis and was getting super confused. Derp.
I've been toying around with writing up a design doc for an RPG. I haven't coded since high school (so, 9 years ago?), and that was Java. That, or writing a bot to allow you to play Yu-Gi-Oh in mIRC, and scripting for MUDs. >.>
Anyway.
At this point, since I'm so far gone from all of that. Would it likely be the smarter option, if I go through with fleshing this thing out, to just find someone who thinks the idea has merit and wants to code it? Or is it feasible for me to go from just over no coding background, to actually being able to make something in Unity or the like in a decent timeframe?
Origin for Dragon Age: Inquisition Shenanigans: Inksplat776
Your odds of finding anyone who is more enthusiastic about coding your game than their own game are 0%. I'd say refresh your coding skills at least to the point where you can create a decent proof-of-concept; if your idea is so radically engaging that someone out there feels like they want to contribute to it, then you'll have your coder. But until then, assume you're on your own.
My favorite musical instrument is the air-raid siren.
I've been toying around with writing up a design doc for an RPG. I haven't coded since high school (so, 9 years ago?), and that was Java. That, or writing a bot to allow you to play Yu-Gi-Oh in mIRC, and scripting for MUDs. >.>
Anyway.
At this point, since I'm so far gone from all of that. Would it likely be the smarter option, if I go through with fleshing this thing out, to just find someone who thinks the idea has merit and wants to code it? Or is it feasible for me to go from just over no coding background, to actually being able to make something in Unity or the like in a decent timeframe?
Kupi's right in that you're not likely going to find someone to code your game for you based on the design doc. I mean unless you want to hire someone for an exorbitant amount of money.
I assume your RPG idea is a good one; which means if you haven't coded in a long time, or you're not very experienced as a coder, you probably shouldn't tackle a complex RPG as your first game project.
I'd recommend starting with some basic, easy games/projects and see those to completion, then build on that knowledge and experience before tackling an ambitious RPG project.
I've been toying around with writing up a design doc for an RPG. I haven't coded since high school (so, 9 years ago?), and that was Java. That, or writing a bot to allow you to play Yu-Gi-Oh in mIRC, and scripting for MUDs. >.>
Anyway.
At this point, since I'm so far gone from all of that. Would it likely be the smarter option, if I go through with fleshing this thing out, to just find someone who thinks the idea has merit and wants to code it? Or is it feasible for me to go from just over no coding background, to actually being able to make something in Unity or the like in a decent timeframe?
After a year and a half where I've spent probably more than 1,500 hours on gamemaking, strictly as a hobby, I've realized something very important:
Design documents are bad. At least, they're bad for when you're making games for fun.
The problem with designing a game before you make it is (1) things that you think are easy almost certainly never are and (2) all the fun is up front. It's no fun sitting down with ActionScript and after a hundred hours of programming and doing art realizing that it'll take you years to finish thing you've designed.
I advocate a different route for game making. My goal is to make the time difference between design and delivering on that design as small as possible -- i.e., within hours. My goal is to sit down at my computer every night having only a general idea of what new feature I want to deliver on (with a 2-3 hour time frame in mind), and then deliver on that before the night is over.
That cycle of work is way better than the design document approach, at least for me.
Yeah absolutely, I hate/never use design documents. Yours are good reasons for that, but also: things you think will be fun/good often aren't, or are for reasons you didn't expect. The document is out of date as soon as you start working, unless A) you adhere to it strictly, which is dumb because you're resistant to iteration or you keep it up to date, in which case you're wasting time maintaining some stupid document that could be spent working on the game. And you'll probably never end up referring back to it anyway.
I think it was Valve who said they found that if they used a design document they'd need to have at least one person whose full-time job was updating and maintaining the document, and there's actually no upside to it at all
So I’ve made the beginnings of something maybe awesome -- A game where you create a space ship and then can deploy it into a world:
Ship creation -- Notice how you can make bulkheads and thrusters!
You can also rotate the thrusters around, and associate keypresses with a thruster. (So pressing the key "a" would fire the thrusters that would rotate the ship one way, and "w" would fire thrusters to make you go forward, etc.)
Ship deployment -- Here's a screenshot of me flying the ship around with some floating asteroids.
The thrusters actually trigger a physics Force at the location of the thruster, forward from the thruster. And the ship itself has a single rigidbody.
Is there a site where I can upload a webplayer version of my unity project?
If not, I was thinking about maybe spinning up a server to serve up my project, but that might take up some time that I could put towards working on the game.
Me personally, I have exactly the opposite experience re: design documents. My first game was a labor of love that I built from the ground up based on a vague impression of what I wanted the game to be. In the end, it was a hackish piece of shit I had to force myself to finish and was played by a grand total of somewhere between five to ten people, none of whom could possibly have hated it more than I did for demonstrating just what a starry-eyed piece of shit I was for not abandoning it sooner.
By contrast, the game project I'm working on now is shaping up to be exactly what I thought it could be, which I credit entirely to having planned out as much of it in advance as I possibly could, from mission statement to human-language gameplay description to algorithms and class layouts. It has not taken a whit of the fun out of the coding, in large part because each subsystem is its own little challenge, and watching the project slowly form together out of those pieces keeps me in a perpetual state of astonishment at how cool the thing I'm making is turning out to be. That doesn't mean I haven't run into spots where I've had to change direction slightly, or things that the design didn't cover, but I absolutely cannot stress enough the significance of Knowing What The Fuck I'm Doing Before I Do It to my peace of mind and the quality of the game. I absolutely cannot conceive of trying to build a game without designing it out beforehand.
That doesn't mean you can't make a good game improvisationally, of course; if you can, more power to you. But people's preferences vary, and I don't want anyone getting it in their head that "design documents are bad always".
My favorite musical instrument is the air-raid siren.
I think design docs in general just work a lot better when you have a more realistic understanding of what's required in order to achieve your goals. Without a decent level of technical understanding it's next to impossible to accurately estimate scope. Design docs should (in theory) become more and more useful as your knowledge increases, since you'll be able to draw up something realistic and achievable.
So I've been wanting to mess with game development as a hobby for a long time now, and I started messing with Unity a week or so ago.
I'm trying to take it slow and make it a learning experience. So far I've just been trying to extend the editor by setting up custom panels to help me create/edit/setup things in the environment. Really basic level-editor type of stuff.
I've got the point where I want to start messing with character/attacking/enemy type stuff.
So I did some reading, and from what I've been looking into people are saying don't try to do the typical OO approach. From what I've been reading instead of typical inheritance like you do in "normal" OO, you do a more modular approach (from what I can tell, similar to something like dependency injection in OO).
I like this a lot actually and just wanted to tap the brains of some people who have done this a lot. So I would just create a blank game object... and then create components that contain behaviors that I need done? Like a hp tracking component, a damage output component, a damage input component, a movement component, etc... and then just attach the required ones.
So a player object would have things like health, damage, experience, movement components attached to that object?
That make sense?
Bigsushi.fm
Listen to our podcast, read our articles, tell us how much you hate it and how to make it better
I don't feel like it's worthwhile to get quite that modular. I mean if you're making an RPG every unit is going to have HP, damage output, etc so it's more useful to have a "unit" script. But generally yeah, that's the right track.
My favorite example of components so far was combining a script that wavers the transform position and another that fluctuates the intensity of an attached light to create a fire that actually flickers and sways.
So I've been wanting to mess with game development as a hobby for a long time now, and I started messing with Unity a week or so ago.
I'm trying to take it slow and make it a learning experience. So far I've just been trying to extend the editor by setting up custom panels to help me create/edit/setup things in the environment. Really basic level-editor type of stuff.
I've got the point where I want to start messing with character/attacking/enemy type stuff.
So I did some reading, and from what I've been looking into people are saying don't try to do the typical OO approach. From what I've been reading instead of typical inheritance like you do in "normal" OO, you do a more modular approach (from what I can tell, similar to something like dependency injection in OO).
I like this a lot actually and just wanted to tap the brains of some people who have done this a lot. So I would just create a blank game object... and then create components that contain behaviors that I need done? Like a hp tracking component, a damage output component, a damage input component, a movement component, etc... and then just attach the required ones.
So a player object would have things like health, damage, experience, movement components attached to that object?
That make sense?
I'd love to read what you've been reading.
I've only been messing around with unity for a couple weeks myself. So far, I've sort of drifted in almost entirely traditional OO approach. My project has quite a few prefabs, each with a single script (some of these scripts may inherit from eachother).
If you look at the game before the 'play' button is pressed, the scene contains only a single game object with a script that manages instantiating the entire game, and holds references to all objects in the game.
I guess I'm trying to mimic what I've done with ActionScript. The Game Manager object is the 'stage', and holds (1) references to prefabs and (2) lists of instantiated prefabs. The Game Manager also manages the GUI.
Though I'm not entirely sure if this is the best way to go.
I don't feel like it's worthwhile to get quite that modular. I mean if you're making an RPG every unit is going to have HP, damage output, etc so it's more useful to have a "unit" script. But generally yeah, that's the right track.
My favorite example of components so far was combining a script that wavers the transform position and another that fluctuates the intensity of an attached light to create a fire that actually flickers and sways.
I think he has the right idea to break things up a lot. You have to be really certain that your "unit" script really needs all those things and that they wouldn't better be served with different components. You can very easily drift back towards things where you lose the reason for going to a component system (which Unity is entirely based on) in the first place. The simplest example I can think of is one which even Unity itself breaks, it puts a position embedded into all objects, generally that's a fine idea, "Everything in my game needs a position!". But it's easy to see if you have some kind of simple type of management scripts which don't actually have a physical position in your game they will have a position in Unity because that's how it works. So go ahead and add things to your "unit" script but make sure they really should be there.
Another example is hitpoints. Maybe you decide later your hero character is going to have some other health system (energy or something) that works in a different way to regular old hitpoints that all the enemies have. In OOP (and your unit script) you've possibly got a bunch of changes and refactoring to do to make sure your enemies with regular health still work the same way as before. If you had the hitpoints component broken out on it's own you just leave it plugged into the enemy, remove it from the hero character and plug in your new energy component to the hero. There will be some rework even in the component based system but it feels much more "clean" when working in a fully component based system.
...
Another example is hitpoints. Maybe you decide later your hero character is going to have some other health system (energy or something) that works in a different way to regular old hitpoints that all the enemies have. In OOP (and your unit script) you've possibly got a bunch of changes and refactoring to do to make sure your enemies with regular health still work the same way as before. If you had the hitpoints component broken out on it's own you just leave it plugged into the enemy, remove it from the hero character and plug in your new energy component to the hero. There will be some rework even in the component based system but it feels much more "clean" when working in a fully component based system.
Yeah that's the direction I'm heading. I'm assuming it's easy to interact between components or even setup requirements similar to interfaces or something similar?
Bigsushi.fm
Listen to our podcast, read our articles, tell us how much you hate it and how to make it better
I don't feel like it's worthwhile to get quite that modular. I mean if you're making an RPG every unit is going to have HP, damage output, etc so it's more useful to have a "unit" script. But generally yeah, that's the right track.
My favorite example of components so far was combining a script that wavers the transform position and another that fluctuates the intensity of an attached light to create a fire that actually flickers and sways.
I think he has the right idea to break things up a lot. You have to be really certain that your "unit" script really needs all those things and that they wouldn't better be served with different components. You can very easily drift back towards things where you lose the reason for going to a component system (which Unity is entirely based on) in the first place. The simplest example I can think of is one which even Unity itself breaks, it puts a position embedded into all objects, generally that's a fine idea, "Everything in my game needs a position!". But it's easy to see if you have some kind of simple type of management scripts which don't actually have a physical position in your game they will have a position in Unity because that's how it works. So go ahead and add things to your "unit" script but make sure they really should be there.
Another example is hitpoints. Maybe you decide later your hero character is going to have some other health system (energy or something) that works in a different way to regular old hitpoints that all the enemies have. In OOP (and your unit script) you've possibly got a bunch of changes and refactoring to do to make sure your enemies with regular health still work the same way as before. If you had the hitpoints component broken out on it's own you just leave it plugged into the enemy, remove it from the hero character and plug in your new energy component to the hero. There will be some rework even in the component based system but it feels much more "clean" when working in a fully component based system.
Oh, definitely. And it's highly dependent on what kind of game you're making. I was just making a case for against modularity for it's own sake.
I don't feel like it's worthwhile to get quite that modular. I mean if you're making an RPG every unit is going to have HP, damage output, etc so it's more useful to have a "unit" script. But generally yeah, that's the right track.
My favorite example of components so far was combining a script that wavers the transform position and another that fluctuates the intensity of an attached light to create a fire that actually flickers and sways.
I think he has the right idea to break things up a lot. You have to be really certain that your "unit" script really needs all those things and that they wouldn't better be served with different components. You can very easily drift back towards things where you lose the reason for going to a component system (which Unity is entirely based on) in the first place. The simplest example I can think of is one which even Unity itself breaks, it puts a position embedded into all objects, generally that's a fine idea, "Everything in my game needs a position!". But it's easy to see if you have some kind of simple type of management scripts which don't actually have a physical position in your game they will have a position in Unity because that's how it works. So go ahead and add things to your "unit" script but make sure they really should be there.
Another example is hitpoints. Maybe you decide later your hero character is going to have some other health system (energy or something) that works in a different way to regular old hitpoints that all the enemies have. In OOP (and your unit script) you've possibly got a bunch of changes and refactoring to do to make sure your enemies with regular health still work the same way as before. If you had the hitpoints component broken out on it's own you just leave it plugged into the enemy, remove it from the hero character and plug in your new energy component to the hero. There will be some rework even in the component based system but it feels much more "clean" when working in a fully component based system.
Oh, definitely. And it's highly dependent on what kind of game you're making. I was just making a case for against modularity for it's own sake.
I agree to an extent but modularity for modularity's sake is actually a good idea for game design in a lot of cases. Unless you're making a simple game, have a very concrete genre that doesn't have a lot of choice in dynamics of gameplay or are extremely planned out ahead of time modularity will generally make things easier to change as you go along. You're right about something like an RPG for the most part though. But in any kind of real time action game sometimes you make things that just aren't fun or need changing or tweaking that a component system lends itself to.
It's older, but it's the post that I read that made me step back for a minute instead of just jumping in and setting up object hierarchies like I would typically try to do.
Bigsushi.fm
Listen to our podcast, read our articles, tell us how much you hate it and how to make it better
Design docs, we use them, but we keep 'em short and simple, like an outline of our game idea. It helps us to set up the structure of the game and the gameplay, but it's not like we plot out every tiny nuance and detail in the thing. Usually end up being two pages long, or three. It helps us both get our sides of the production up and going simultaneous without issues and if we have to make changes (which we always do), we do and it's no big deal; but usually stuff like general story points and locales and usually characters don't change and basic gameplay ideas don't usually change, even if the way they work changes. So it's useful to refer back to sometimes when I'm cranking out levels or characters for example. It's also good to narrow the scope before we set out.
We could probably do a game without a design doc up front, but what we'd end up with are a series of little documents plotting things out along the way anyway. It definitely seems beneficial to hammer out major story points and characters before I start building a game world though.
In about four hours of reading the documentation and experimenting I've been able to make what appears to be super efficient pathfinding in a fully 3D space (with space ships moving over/around obstacles).
It is really, really good. The documentation is a little light, but still pretty good.
Edit: Oh and it's free. (Well there's a paid version too, but it only adds a couple extra features. I'll probably throw some money Granberg's way if my project ever looks like it'll move out of the 'just a hobby' phase.)
So still trying to get used to all the "proper" way to handle things.
So I want to make a basic SRPG style concept. I extended the editor to help me build a basic grid like board. I have really basic characters and trying to manage movement with them.
So... how should I handle something like a global map manager? I need something that can manage the references to the "tiles" on the board. I am already setting up a 2-dimensional array of the spots on the grid, that way I can reference them via coordinates ( [4,2] ) and get the reference to the "tile" which then has info about itself (type of ground, impassible?, trap?, etc.)
How do other components get access to this data? I'm trying to build a movement component and I need to be able to reference the MapManager to find out info about the tiles around me, where I can move, actually make the move etc...
Is there a preferred method for something like this. Singleton was my first thought, but figured I'd ask some more experienced people.
Bigsushi.fm
Listen to our podcast, read our articles, tell us how much you hate it and how to make it better
Ardor is an SRPG - I'm way to tired to type it all up, but I'll write something tomorrow. I've basically got a script for each tile, and a CombatLogic game object.
Obviously this won't work for every SRPG, it was the first thing I wrote in Unity, so it's possible to improve it, but here goes:
The top object for a given map has a script that does some basic management like finding out if a hex is valid, or what the "standing height" of a given coordinate is. It's able to do this by looking for components in children. I've also set my map editor to name the children as Map Tile [0,0], so I can always search children by name, which is faster.
The direct children of the map object are "map stacks", which contain position information. Every map stack has a "Terrain" object, which is really just a parent for the mesh for that hex (to deal with Unity's 90 degree rotation of Blender objects, so we can scale Z axis and it actually does what you'd expect). It also has a "walkable" child, which is a plane mesh with transparency. It contains information on what the ground type (soil, water, stone, etc) is and whether the hex can be walked on. I can also manually change the Z position of these objects, it's how the map object determines standing height (and where the cursor goes). So if I have a tile with a lamppost, I can set the Walkable to false, and move it to the top of the lamppost. The visibility of these is toggled based on the game engine state. They're normally invisible, but if they're targetable for whatever reason, they're visible.
I don't know if this helps at all. The white hexes are the "walkable" objects.
They're lit blue when they can be targeted for walking.
You can move your cursor to unwalkable tiles, but they're not lit.
Oh wow, thanks for posting that. Definately makes me feel I was headed in the right direction.
I wasn't sure how to organize/arrange things and I was going down the same path you did. I have a parent object that is just empty but holds all the children "tiles", and I actually had them named like "MapTile 2:4" :P
So that's pretty common then? To have like "god" objects that are just hanging out in the world, all invisible, but managing all of the children below it. And then all your other components can access it? Like asking "hey is this coordinate I want to go to valid? give me a list of valid tiles within range 6" or things like that?
Bigsushi.fm
Listen to our podcast, read our articles, tell us how much you hate it and how to make it better
I think so. I've got a "god" object for managing the combat logic, another for the persistent data (the user's save game, essentially), and another for managing the game's script.
Posts
I'm not sure I'm going to keep the architecture or not, but right now it's lightweight enough that it shouldn't be much effort to change later. And either way, since the particle handler is going to be dealing with (possibly) massive amounts of quick insertions and deletions, Linked Lists are (for once) an ideal choice, I think. Constant time for, literally, every operation I will need to use them for, except for iterating through every particle, which will be linear time regardless of which data structure I choose to use.
LinkedListNode<Particle> node = activeParticles.First; LinkedListNode<Particle> tmp; while (node.Next != null) //Go do all the particles for this frame node.Value.doThis(pack); node = activeParticles.First; while (node != null) //Loop through all the active particles again, to test relevance. { if (!node.Value.testRelevance(pack)) //If a particle is no longer relevant, remove it from the active particle list { switch (node.Value.Type) { case ParticleType.Activator: //Only one of these ever. tmp = node.Next; activeParticles.Remove(node); node = tmp; break; case ParticleType.Decoration: tmp = node.Next; activeParticles.Remove(node); inactiveDecorations.AddFirst(node); node = tmp; break; case ParticleType.Projectile: tmp = node.Next; activeParticles.Remove(node); inactiveProjectiles.AddFirst(node); node = tmp; break; } } }I am indeed pooling them. Or rather, my method so far is to start with an empty pool, and when a particle becomes irrelevant, it gets put into an inactive pool, from which any new particle creation will first draw, if available.
But I guess then I had to iterate over the whole list when I was finding a particle to reset, so now that I think about your way is probably better!
"We have years of struggle ahead, mostly within ourselves." - Made in USA
I should start posting my ActionScript lamentations here.*
*
I know this comment was from last month, but my first game was 2D and written in Unity, and it didn't seem obtuse to me. Probably the biggest stumbling block early on was in creating mesh planes...they would start out horizontal by default, so I had to flip them round the x axis to see them. I've obtained some code and plugins that have helped with that process since then.
CreatePlane - A nice wizard interface for creating very efficient mesh planes. I set the width and length, then set the plane to "Vertical" (which spins it on the x axis automatically)
Kinda tough to set everything on one plane (unless you meant "axis"), depending on the type of game you're writing. I have many planes with sprites attached to them, set at various z levels for layering. Camera is set to orthographic, and the camera size should be set to half your target screen height (mine is frequently "480", since iPhone 4 was 640x960).
Sprite Manager 2 - I know it costs a good chunk of change, and there are other sprite animation packages out there for Unity, but it's worked fairly well for me. It really keeps the draw calls down, which is crucial for mobile devices.
iTween - I use iTween to do almost all of my object movement in-game. Very simple to use, and fairly powerful. Most times, I only have to write 1 line of code to get the effect I'm looking for. When I need to write more, I just have to send iTween a hashtable of settings.
I was wary about writing a 2D game in Unity, but just like anything else, once you're used to it it's fairly straightforward. And the advantage of multiplatform builds is hard to ignore, in my opinion. 8)
@ShiftyPumpkin on the Twitterings. Book the Faces at [facebook.com/PerceptivePumpkinProductions]
And I decided to start learning Unity instead. (This learning began a few days ago while on a Disney cruise vacation with my parents. Lounging around on a huge boat is a surprisingly programming-friendly environment, and really great for inspiration.)
Anyway, I just had one of those "I'm the worst programmer" moments while trying to make 2D-appearing physics work in Unity.
When using an orthographical camera such that you can't perceive the Z axis (i.e., it looks like a simple 2D world with a vertical X axis and horizontal Y axis), and you don't want objects to rotate in a way that wouldn't make sense in a 2D world, you want to (1) freeze movement along the Z axis and, (2) unintuitively, freeze rotation along the X and Y axises as well! I kept trying to freeze rotation along the Z axis and was getting super confused. Derp.
one of us
one of us
I've been toying around with writing up a design doc for an RPG. I haven't coded since high school (so, 9 years ago?), and that was Java. That, or writing a bot to allow you to play Yu-Gi-Oh in mIRC, and scripting for MUDs. >.>
Anyway.
At this point, since I'm so far gone from all of that. Would it likely be the smarter option, if I go through with fleshing this thing out, to just find someone who thinks the idea has merit and wants to code it? Or is it feasible for me to go from just over no coding background, to actually being able to make something in Unity or the like in a decent timeframe?
Kupi's right in that you're not likely going to find someone to code your game for you based on the design doc. I mean unless you want to hire someone for an exorbitant amount of money.
I assume your RPG idea is a good one; which means if you haven't coded in a long time, or you're not very experienced as a coder, you probably shouldn't tackle a complex RPG as your first game project.
I'd recommend starting with some basic, easy games/projects and see those to completion, then build on that knowledge and experience before tackling an ambitious RPG project.
Steam ID: slashx000______Twitter: @bill_at_zeboyd______ Facebook: Zeboyd Games
After a year and a half where I've spent probably more than 1,500 hours on gamemaking, strictly as a hobby, I've realized something very important:
Design documents are bad. At least, they're bad for when you're making games for fun.
The problem with designing a game before you make it is (1) things that you think are easy almost certainly never are and (2) all the fun is up front. It's no fun sitting down with ActionScript and after a hundred hours of programming and doing art realizing that it'll take you years to finish thing you've designed.
I advocate a different route for game making. My goal is to make the time difference between design and delivering on that design as small as possible -- i.e., within hours. My goal is to sit down at my computer every night having only a general idea of what new feature I want to deliver on (with a 2-3 hour time frame in mind), and then deliver on that before the night is over.
That cycle of work is way better than the design document approach, at least for me.
I think it was Valve who said they found that if they used a design document they'd need to have at least one person whose full-time job was updating and maintaining the document, and there's actually no upside to it at all
Ship creation -- Notice how you can make bulkheads and thrusters!
You can also rotate the thrusters around, and associate keypresses with a thruster. (So pressing the key "a" would fire the thrusters that would rotate the ship one way, and "w" would fire thrusters to make you go forward, etc.)
Ship deployment -- Here's a screenshot of me flying the ship around with some floating asteroids.
The thrusters actually trigger a physics Force at the location of the thruster, forward from the thruster. And the ship itself has a single rigidbody.
Is there a site where I can upload a webplayer version of my unity project?
If not, I was thinking about maybe spinning up a server to serve up my project, but that might take up some time that I could put towards working on the game.
By contrast, the game project I'm working on now is shaping up to be exactly what I thought it could be, which I credit entirely to having planned out as much of it in advance as I possibly could, from mission statement to human-language gameplay description to algorithms and class layouts. It has not taken a whit of the fun out of the coding, in large part because each subsystem is its own little challenge, and watching the project slowly form together out of those pieces keeps me in a perpetual state of astonishment at how cool the thing I'm making is turning out to be. That doesn't mean I haven't run into spots where I've had to change direction slightly, or things that the design didn't cover, but I absolutely cannot stress enough the significance of Knowing What The Fuck I'm Doing Before I Do It to my peace of mind and the quality of the game. I absolutely cannot conceive of trying to build a game without designing it out beforehand.
That doesn't mean you can't make a good game improvisationally, of course; if you can, more power to you. But people's preferences vary, and I don't want anyone getting it in their head that "design documents are bad always".
I'm trying to take it slow and make it a learning experience. So far I've just been trying to extend the editor by setting up custom panels to help me create/edit/setup things in the environment. Really basic level-editor type of stuff.
I've got the point where I want to start messing with character/attacking/enemy type stuff.
So I did some reading, and from what I've been looking into people are saying don't try to do the typical OO approach. From what I've been reading instead of typical inheritance like you do in "normal" OO, you do a more modular approach (from what I can tell, similar to something like dependency injection in OO).
I like this a lot actually and just wanted to tap the brains of some people who have done this a lot. So I would just create a blank game object... and then create components that contain behaviors that I need done? Like a hp tracking component, a damage output component, a damage input component, a movement component, etc... and then just attach the required ones.
So a player object would have things like health, damage, experience, movement components attached to that object?
That make sense?
Listen to our podcast, read our articles, tell us how much you hate it and how to make it better
My favorite example of components so far was combining a script that wavers the transform position and another that fluctuates the intensity of an attached light to create a fire that actually flickers and sways.
I'd love to read what you've been reading.
I've only been messing around with unity for a couple weeks myself. So far, I've sort of drifted in almost entirely traditional OO approach. My project has quite a few prefabs, each with a single script (some of these scripts may inherit from eachother).
If you look at the game before the 'play' button is pressed, the scene contains only a single game object with a script that manages instantiating the entire game, and holds references to all objects in the game.
I guess I'm trying to mimic what I've done with ActionScript. The Game Manager object is the 'stage', and holds (1) references to prefabs and (2) lists of instantiated prefabs. The Game Manager also manages the GUI.
Though I'm not entirely sure if this is the best way to go.
I think he has the right idea to break things up a lot. You have to be really certain that your "unit" script really needs all those things and that they wouldn't better be served with different components. You can very easily drift back towards things where you lose the reason for going to a component system (which Unity is entirely based on) in the first place. The simplest example I can think of is one which even Unity itself breaks, it puts a position embedded into all objects, generally that's a fine idea, "Everything in my game needs a position!". But it's easy to see if you have some kind of simple type of management scripts which don't actually have a physical position in your game they will have a position in Unity because that's how it works. So go ahead and add things to your "unit" script but make sure they really should be there.
Another example is hitpoints. Maybe you decide later your hero character is going to have some other health system (energy or something) that works in a different way to regular old hitpoints that all the enemies have. In OOP (and your unit script) you've possibly got a bunch of changes and refactoring to do to make sure your enemies with regular health still work the same way as before. If you had the hitpoints component broken out on it's own you just leave it plugged into the enemy, remove it from the hero character and plug in your new energy component to the hero. There will be some rework even in the component based system but it feels much more "clean" when working in a fully component based system.
Yeah that's the direction I'm heading. I'm assuming it's easy to interact between components or even setup requirements similar to interfaces or something similar?
Listen to our podcast, read our articles, tell us how much you hate it and how to make it better
Oh, definitely. And it's highly dependent on what kind of game you're making. I was just making a case for against modularity for it's own sake.
I agree to an extent but modularity for modularity's sake is actually a good idea for game design in a lot of cases. Unless you're making a simple game, have a very concrete genre that doesn't have a lot of choice in dynamics of gameplay or are extremely planned out ahead of time modularity will generally make things easier to change as you go along. You're right about something like an RPG for the most part though. But in any kind of real time action game sometimes you make things that just aren't fun or need changing or tweaking that a component system lends itself to.
http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/
It's older, but it's the post that I read that made me step back for a minute instead of just jumping in and setting up object hierarchies like I would typically try to do.
Listen to our podcast, read our articles, tell us how much you hate it and how to make it better
We could probably do a game without a design doc up front, but what we'd end up with are a series of little documents plotting things out along the way anyway. It definitely seems beneficial to hammer out major story points and characters before I start building a game world though.
Steam ID: slashx000______Twitter: @bill_at_zeboyd______ Facebook: Zeboyd Games
A* Pathfinding by http://www.arongranberg.com/
In about four hours of reading the documentation and experimenting I've been able to make what appears to be super efficient pathfinding in a fully 3D space (with space ships moving over/around obstacles).
It is really, really good. The documentation is a little light, but still pretty good.
Edit: Oh and it's free. (Well there's a paid version too, but it only adds a couple extra features. I'll probably throw some money Granberg's way if my project ever looks like it'll move out of the 'just a hobby' phase.)
So I want to make a basic SRPG style concept. I extended the editor to help me build a basic grid like board. I have really basic characters and trying to manage movement with them.
So... how should I handle something like a global map manager? I need something that can manage the references to the "tiles" on the board. I am already setting up a 2-dimensional array of the spots on the grid, that way I can reference them via coordinates ( [4,2] ) and get the reference to the "tile" which then has info about itself (type of ground, impassible?, trap?, etc.)
How do other components get access to this data? I'm trying to build a movement component and I need to be able to reference the MapManager to find out info about the tiles around me, where I can move, actually make the move etc...
Is there a preferred method for something like this. Singleton was my first thought, but figured I'd ask some more experienced people.
Listen to our podcast, read our articles, tell us how much you hate it and how to make it better
The top object for a given map has a script that does some basic management like finding out if a hex is valid, or what the "standing height" of a given coordinate is. It's able to do this by looking for components in children. I've also set my map editor to name the children as Map Tile [0,0], so I can always search children by name, which is faster.
The direct children of the map object are "map stacks", which contain position information. Every map stack has a "Terrain" object, which is really just a parent for the mesh for that hex (to deal with Unity's 90 degree rotation of Blender objects, so we can scale Z axis and it actually does what you'd expect). It also has a "walkable" child, which is a plane mesh with transparency. It contains information on what the ground type (soil, water, stone, etc) is and whether the hex can be walked on. I can also manually change the Z position of these objects, it's how the map object determines standing height (and where the cursor goes). So if I have a tile with a lamppost, I can set the Walkable to false, and move it to the top of the lamppost. The visibility of these is toggled based on the game engine state. They're normally invisible, but if they're targetable for whatever reason, they're visible.
I don't know if this helps at all. The white hexes are the "walkable" objects.
They're lit blue when they can be targeted for walking.
You can move your cursor to unwalkable tiles, but they're not lit.
I wasn't sure how to organize/arrange things and I was going down the same path you did. I have a parent object that is just empty but holds all the children "tiles", and I actually had them named like "MapTile 2:4" :P
So that's pretty common then? To have like "god" objects that are just hanging out in the world, all invisible, but managing all of the children below it. And then all your other components can access it? Like asking "hey is this coordinate I want to go to valid? give me a list of valid tiles within range 6" or things like that?
Listen to our podcast, read our articles, tell us how much you hate it and how to make it better
https://github.com/id-Software/DOOM-3-BFG