Rick

CSG editors are additive or subtractive. I think UDK was subtractive which I have a really hard time with myself. I would rather build the structures like in the real world vs carve things from a block, but some people prefer carving from a block. Although this is one use, it can be used in the final production of the game as well as most every FPS game 10 years ago did, and a good number today still to. UDK is a good example as most games made with it will use csg in some fashion most likely. Of course as stated you can still add models to help with the realism. Artists aren't level designers and most likely don't understand the flow and all the details that go into making levels (it's a science from what I've been reading). They also change often during play testing so going back to an artist to do that would be costly and time consuming vs having some lower paid level designer to do it via csg.

@Flexman, as I'm sure you are aware 10 some years ago games like Half-Life use CSG for a decent amount of their level design. That can still be used today to make quality games that people will buy. Ideally you want level designers to make your levels not full blown artists (because they are 2 different talents) and level designers can work with CSG much easier than any 3D modelling program.

I'm excited to see what kind of particle editor you can come up with because it's really needed here! Welcome.

I've just been making my buttons and labels as static images mostly because using fonts for text seems to be a pain if you think about your window scaling and wanting your GUI to scale with it since from what I can tell fonts don't scale, you would have to make a ton of fonts for different resolutions and pick which one you want. Using static images I'm able to create really big controls like buttons or labels, and then scale them down while keeping their ratio so they still look the same. Now doing all this with a complex layout can be a pain to pre-calculate positions or doing it by trial and error and restarting your program every time you make a change so I store all my GUI information in sqlite and I have a 2 second timer that looks for changed values that I did during run-time so their properties can be reassigned at run-time to show the change immediately in the game. This has worked out amazingly! I also treat position and size as % of the parent where 0,0,GraphicsWidth(),GraphicsHeight() is the base "desktop" parent. This too has worked out well for scaling the GUI with different screen sizes and since I'm using Lua I can see this real-time in the editor as I resize the editor. When I'm finished with this game I'll try to release this system so others can just plug their own image controls in a sqlite db and see it work.

Yeah, I can interpolate with a given step value. Maybe I need to look into the Curve function to get that slowdown when nearing the destination. Again, wasn't really asking because I couldn't figure it out (I've posted interpolation code on the forums here before somewhere), just thought someone had built a nice and neat MoveEntityTo() function already that I could just blop into my code when I was ready for it. A post asking if someone had something takes about 15 seconds to write up. Writing, testing, and tweaking the code to get the feel of PointEntity takes longer so if someone already did it and was willing to share could save me time as it wasn't a need for right now. Will get to that part in my code next week. Thanks for a reply

So the word DO is new to me. I found some sites that have a powerpoint presentation around the idea. http://www.slideshar...oriented-design https://docs.google....G5yM3pjZA&hl=en From what I can gather, correct me if I'm wrong, but it's pretty much going back to procedural programming with more focus on how you group your data so that it leads to a number of benefits. This article shows a pretty basic example as proves a pretty interesting point. http://molecularmusings.wordpress.com/2011/11/03/adventures-in-data-oriented-design-part-1-mesh-data-3/

There is a large market out there that isn't "AAA" quality. But I do agree that future proofing your code is dangerous and should be used with caution because it can lead to longer development time and for indies that just means more chance of failure. That being said once you get a truely flexible system it can last a long time. Blizzards Lua UI implementation would be a good example of this. I imagine this will spark some conversation.

I tend to lean towards 1 main loop that is about 10 lines or so only. It has the basic LE framework stuff and Flip() and then branches off to the current game state draw and update functions or classes depending on how you do it. The game states would be like "developer.logo", "leadwerks.logo", "main.menu", "gameplay". Each having their own draw and update methods. In C++ I make them their own classes since this breaks things out very nicely and allows for very easy reuse. They would be deriving from some GameState base class so all game states could be stored together in a map with a string key. The game state variable is available for all game state instances so that they can change between each other. As long as I use this same setup for each game I make I simply include the header and source file for the "developer.logo" and "leadwerks.logo" (and any other common gamestate between games) (since those 2 are the same) and it tends to lend to nice reusable code. while(!gameQuit) { UpdateFramework(); gameStates[activeGameState]->Update(); DrawFramework(); gameStates[activeGameState]->Draw(); Flip(); } You can also get fancy with transitions and whatnot with this if you like. Some variations would looping through all elements in the gameState map and checking an active, enabled, or visible flag and calling Update() or Draw() on each one to give a layered game state environment. This in itself might give you more than the 8 classes you have and be a nice logical separation.

Has anyone ever made a MoveEntityTo type of function to move an entity from it's currently location to another entities location at a given rate? It would basically be just like PointEntity works but with position instead of rotation? Spending my efforts in another place in my game right now so thought I'd just check the forums to see if anyone has built such a function already to save myself time as soon I'll have use for such a function.

So actually that didn't work. It worked because I had that same file in my leadwerks directory. Can't I make the editor read the scripts folder under my own game directory? I would think the path options would do that and I have that set to the Scripts folder of my game directory.

I get this every so often and I forget what I do to make it work. At the top of my main game script I often want to load my own scripts that I made. I know sometimes it works because that Scripts/Timer is mine and it loads fine right now (I made it months ago), but then I create a new file and try to add it "/Scripts/GUI/GUIManager" and now when I run the editor it says can't open "Scripts/GUI/GUIManager". /Scripts/GUI/GUIManager.lua exists in my games path At the top of my main game script require("Scripts/table") require("Scripts/Timer") require("Scripts/GUI/GUIManager")

Not sure if LE3D will have a base GUI (if not then that's one request), but I'm creating a system right now for myself where I'm able to update a little custom GUI I have in real-time and it's amazingly handy. One of the big pains that I've had is sizing and positions controls correctly. Often it's either draw it all out on paper and miss something there only to find out it's all crazy when I put it in the game, or do my best at where I think it would be in game and of course mess up. Either way it often leads to running the game over and over again to see how it looks, which is a pain. Using SQLite, or could use xml (text) files, to define my GUI properties, I'm able to get to a screen that has some GUI elements on it, go into the SQLite DB and start tweaking values like size, position, color, whatever and see it happen on the screen. It's handy and speeds development up. On that same note being able to resize the window and such would aid in this to make sure things look good in every resolution. I'm using % based values so if it looks good on 1 res it should look the same in all, but would be nice to do that on the fly in real-time. Just a thought with experiences that I've had with GUI's.

LE is OpenGL based not DX based.

Is there going to be a link somehow from Visual Studio (or other IDE/Compiler) to the project type we make? You aren't writting your own IDE for C++ are you?

Callbacks are functions that you define (but the engine tells you the prototype for) and the engine calls. For example, collision. I would have assumed you were using physics collision for picking up coins but maybe not given your question. In LE you can define a collision callback function and when 2 physics bodies collide the function will get called. Note that it'll be a repeated call until they don't collide anymore. The function parameters are filled in by the engine itself so you can work with the data. In the collision method it tells you the 2 entities that collided, and other information about the collision. http://www.leadwerks.com/wiki/index.php?title=Entities#Callback_Functions The crappy part about how LE does it's callbacks is that it's C oriented so if you are using C++ and heavy OO design, you most likely have to do some extra work to make a normal C function work for your design (Unless you are using EntityKeys for everything which I doubt). For the collision callback using C++ I often will use SetEntityUserData() inside the class that stores my object, say a GameObject, and assign the model a 'this' pointer. I then define a OnCollision() member function in my GameObject class. Now inside the global Collision callback I can call GetEntityUserData() on the LE entity, cast it to GameObject, check that the cast worked, and call it's virtual OnCollide. Anyway that might be when you get into it more

Nice to see more demos!!! I haven't played the game yet but will download it now. One thing that just jumped out at me from reading your blog post above here was the gameplay side next steps. As I'm going down the list everything seemed reasonable, then I read the last entry and it punched me in the face That in itself is a giant task when compared to the other tasks in your list. You could break that into a couple smaller tasks. A login mechanism, in itself when you look start looking at security isn't trivial. Simple online movement of characters could be another one and will take time. Stuff like that might help break that 1 giant task into a more manageable task.

I believe it's more like color-keying. I'm specifically trying to create a circle health bar like in diablo. To do so the red health would actually be a rectangle image with the areas that aren't the circle aren't drawn.

Ah bugger. Yeah if you don't have mind showing a really short demo that would be cool. I must have gotten the order wrong or something. I was trying to use pure pink as the mask color.

I believe I asked this before but didn't get an answer, or the answer from Lum didn't seem to work. Does anyone know if you can do 2D masking with LE drawing commands?

In games like Diablo where you mindlessly just kill things and you don't have a target, what is the best way to implement melee attacking? These games seem to have very fluid systems for melee attacks which aren't very presice in their targeting. Do they use physic bodies around the weapon itself, do they just do a cone in front of the player and just damage everything inside this cone when the player attacks? Just curious if anyone has an idea about how best to get that same smooth attacking style.

I'm not a news reporter here lol. Cut me some slack.

I agree someone would have to have read my whole comment to see that I did include the C++ part of your statement in the arument itself and that I didn't quote the entire thing. I'll try to quote entire things from now on, or just leave the quotes out and let people figure out the context for themselves as they read the entire thread. Sorry for that, it's just lazy and implied quoting on my part. Honestly it's exhausting sometimes trying to give arguments in text as you have to cover your butt so much as to not offend or leave gaps. I much prefer in person

That chart actually seems to point out Lua JIT with JIT turned on or off is faster in certain situations than a good number of languages and very comparable to C in some situations. In my view run-time speed is not the end all be all. Very few indie people are actually pushing the speed limits. Most indie games are pretty basic. I still think on pure count alone on advantages Lua beats C/C++. Then it comes down to how you weight advantages/disadvantages. Again, I love C/C++. I love it's syntax, but I can't argue with the number of advantages. I'm pushed myself to do both in LE and this is my findings. If others have actually given both a real try in LE I'd be curious to hear their opposing thoughts, but there doesn't seem to be to many of the mixed Lua & C/C++ crowd out there.

I would say in my experience, enums for that purpose aren't dynamic enough. Ideally all animations would be stored in a database system (sqlite for example) so they can be added/removed without getting into the source. It's just more flexible to do that. Doing that one could make an argument to use an int ID, but to speed up debugging I often find using strings more convenient. It skips a lookup step of trying to figure out what the int value means. If the code hits a breakpoint and I mouse over the animation name variable value and it says "walk" I get more value from that than if it says 25. I'm not a big speed freak though as most basic indie games aren't pushing any boundaries. I value debugging speed and flexibility more than raw run-time speed myself because not to many people are pushing the envelope.

Generally if I take something out of context in a quote it's because I personally feel a certain part has no merit. I should maybe explain that in my postings but I guess I just keep it in my head . I felt that the "For anyone already familiar and skilled in C++" has no merit in the statement. I know C++, and I was listing reasons why Lua has some advantages over it (agree to disagree sort of thing). In all honestly even if you put the knowing C++ part in, it doesn't change the fact that statements like that can be disagreed with (which I was trying to do and list reasons why). That was the general message of my post. That in my argument knowing C++ already, has nothing to do with altering ones view on how or when to use Lua in making a game. Again, that's the agree to disagree part as full games have been made with both langauges, no right answer can be found. So it's not that I'm taking your posts out of context, I just decided to omit why I quoted a certain part. I was trying to list why the first part of your comment has nothing to do with the last. Basically I'm arguing your whole statement, without quoting your whole statement but keeping your whole statement in my head while making my argument. If that makes sense. So it's not that my explanation took your quote out of context, it's just that I didn't quote your entire statement before I gave my argument. My explanation does list why knowing C++ already doesn't mean there aren't advantages to using Lua other than a simple scripting langauge, in where your entire statement was you couldn't find any if you already know C++. I hope that makes sense because that's how it went down in my head