-
Posts
7,936 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Downloads
Everything posted by Rick
-
I just don't understand where the line can be drawn then I guess. Who are we to judge others when we aren't creating all our own shaders to use in our games? We didn't make our own deferred rendering system. We didn't make our own physics library. Why is it OK to share that code and not learn how that code works but not OK if someone wants to use a 3rd person script and doesn't fully understand how it works? I know you said before you aren't judging but with that comment you are. I think it's a slippery slope to be drawing lines in the sand saying someone wants it handed to them when we are getting things handed to us by Josh and other 3rd party libs like RakNet, OpenAL, & Newton. People come here to make video games. There are an endless number of ways to make a video game, why would we care about how someone goes about doing that so much? If the method works, and the game is fun, should we really care how that person went about it? I would venture to say the person who made a small mobile game in Unity that used predefined components (because Unity has a decent amount of them) has learned more about completing and shipping a game than any of us here. I doubt he really cares if he doesn't know how that pathfinding component exactly works. That being said Roland has a cool system he's working on and some people are giving input. There is no harm in that and it does not affect someone who doesn't want to use it. I believe letting people talk about design is no harm and only helps the community. I would encourage anyone to finish a game. Practice finishing games, no matter how lame and stupid they are, is good practice and time well spent. I've read over and over again from experienced game developers that say start small and FINISH a game. There are a number of reasons why finishing a small game helps. The main one being does one have what it takes to get past the boring stuff. In every game there is the boring stuff that has to get done. I would venture to say if one can't get past the small amount of boring stuff that is involved in a simple game then there is no way one could do it in a complex game (which of course we all want to make). If a game has actual gameplay components I would never make fun of someone for completing it because I know how hard it is to do such a feat and many people here have never done it. Which helps explain why there are only 5 games in the Asset store. Lum's first tetris game on the old forums doesn't count of course
-
I hope not that would be bad
-
Just support Lua and be done with it already
-
The horrible and disgusting "static class"
Rick commented on Mumbles's blog entry in Rachel's Dev-Blog
Clearly you can do whatever you like, but I would suggest using more common ways of doing things so 1) Other people aren't confused by your one off way of doing something and 2) You can read other people's code that are following design patterns and such. You should check out singletons if you haven't already. It's sort of the standard in C++ to do what you are trying to do. -
The horrible and disgusting "static class"
Rick commented on Mumbles's blog entry in Rachel's Dev-Blog
You are doing C at that point. You can code your entire game that way if you like The way I see it this is what the singleton pattern is for. Nice article. -
Just curious, and I'm not saying your designs are bad, but didn't you make a blog post once about letting experts do their thing. Just thinking you should have your designer expert give you multiple ideas like this and you pick and make slight changes instead of the other way around.
-
Because generally they were all far from finished OR not meant to be anything to serious. I'm not going to spend the time to make an installer for a cheaply made Simon Says game that I'm giving away. Every game is free and for the most part there is just no point in spending the time to do an installer. If we were selling games they would all have proper installers.
-
Everyone knows the real game devs are 15 year old girls. B) I like the bubbly look. Like MSN Messenger.
-
http://www.totalpcgaming.com/latest-pc-news/steam-user-accounts-hit-25-million/ 2009 numbers http://mashable.com/2010/02/20/farmville-80-million-users/ Q1 2010 http://androideep.com/angry-birds-download-count-to-android-phones-reaches-30-million.html Heck, there are more people that have downloaded Angry Birds (1 game on a mobile device) than all that are on Steam. I'm no math wiz but... I'm not saying I like farmville or have even ever played it, but it says something about where the most people are.
-
So for Lua this will handle the packaging of the project as well? Will it take only what is needed and include it in the final product?
-
Actually that would help the economy since people would be spending
-
I think Josh mentioned Lua will probably be the easiest to migrate. Not sure about the others.
-
Fair enough. Excited to get in there.
-
Asking for editor events accessible via Lua. My pathfinding was just an example usage as to why editor events could be useful in general. There will be other useful scripts that could be created if we are able to tap into these events. The example I was looking at was more around the grid creation not so much the path. In the system I have so far you put the terrain pathfinding model in your scene and it builds the grid to the terrain over multiple cycles allowing you to do other things while it's making the grid. When an object is added in design mode ideally I would know that via an event and again over multiple cycles if required close the nodes the object is sitting on. Similarly if the terrain is altered an event would be fired and over multiple cycles the pathfinding model automatically adjusts the height of the nodes in the area the terrain is on. Would just be nice to make this all automatic right in the editor as I like that sort of thing personally. Again, pathfinding just an example, but there will be other situations where it'll be nice to know when editor events are happening in design mode in our scripts. I don't feel scripts have to just be game scripts, but design mode functionality can be added to give more functionality and easier usage. Again, just a preference I have and would like to provide anyone using my scripts. Which is why having a global variable that tells you when you are in edit mode vs run mode would be ideal. This is what I do with my Pi-Main so all my other Pi scripts know what mode I'm in because it's nice to have different functionality depending on the mode. Not really asking for a plugin system (although it would be nice eventually), just asking that you think of a bunch of different events the editor could fire and let Lua hook into them so scripts can know when the event is fired and they can react if the script developer so wishes. Possible Events ============= Terrain modified Terrain created Terrain deleted Save command Entity added to scene Entity removed from scene
-
So upgrading worked. Now is there a way to get meters per tile because that looks like it affects the size of the terrain as well, and I would need to know that.
-
That is one options but if I know when an entity was added and what entity, I'm pretty sure I can make it have 0 delay in updating the grid to close those nodes. I guess I would also need an entity move event also to update nodes as it moves. Why not shoot for the stars I guess Real-time updating would be pretty sweet! I can do this now but I have to maintain a list of all objects and compare every so often to find what is there or gone and positions. I would take a button feature also. Thinking more I'd need to have a remove entity event fired before it actually gets removed also. Having to press a button to do the calculation is more logical than it just automatically happening? I think your assumptions is that it'll take a little while to calculate. I compare this feature to lighting where you used to have to generate the light map in a scene. Isn't it easier and more convenient in LE when you don't have to do that and it just works real-time
-
@Josh, are you thinking of letting our Lua scripts in LE3 tap into editor events (that you would have to define of course)? For example when a new entity is added to the scene it would be nice to know about that via an event that any of our Lua scripts could hook into and maybe passing in the entity as a parameter. For me personally I would want to know that because I'm creating an in LE editor terrain pathfinding thingoid. A person drops this pathfinding thingoid into the scene and it generates a grid on the terrain. Then when they are placing objects in the scene I would like to automatically set the nodes that the object is over to closed. The most efficient way I can see to do this is via an event that the editor would fire saying a new entity was added that any script can tap into. I think for logical scripts there is probably a good number of events from the editor that could be useful to tap into.
-
I am indeed using 2.43. Bugger. Thanks.
-
@ macklebee, good point. Guess I was thinking it had to be in the pak file but I guess it makes sense it doesn't have to be if everything just uses the abstract idea. @Josh, I was trying EntityColor() on these but no matter what I used for Vec4() parameter it was turning the cube black. EntityColor(pick.entity, Vec4(1, 0, 0, 1) would result in a black cube. So just figured it doesn't work since on the wiki under that command it mentions something about not working on Meshs.
-
Combine the above with forum topic at hand and community separation and this sounds like a good case to only officially support 1 language and honestly I personally wouldn't care which one at this point.