Brent Taylor

Two things. 1) Desktops and laptops...really aren't getting any faster these days. They haven't for a while. i7's introduced hyper threading, which, in the general sense, is just better pipelining of instructions. The same number of instructions are being passed to the proc as the previous generation and at the same speed. Just fewer nop's are being used. 2) As for everyone using desktops over laptops...Thats debatable and very much subject to their field of choice. I live in the Bay Area of California. Very close to San Francisco and the Silicon Valley in general. The vast majority of coders around here are running laptops. This includes game developers. I'm not saying "laptops have taken over", but I would point out that laptops have been greatly outselling desktops since roughly 2004.

Remember, I highly expect to be able to simply dock our mobile device and be able to USE these larger screens. As for speed, they're getting faster and faster with each generation. The new ARM chips they are showing off are blazingly fast. And of course, when docked, they can use more power and achieve a higher speed.

Exactly. We're smack dab in the middle of that shift right now. For example: http://usa.asus.com/Tablet/Transformer_Pad/ASUS_Transformer_Pad_TF300T/ I see this as only an intermediate step in that direction, but it is a step. Sales are doing fairly well. iOS even allows for bluetooth keyboards and devices (as I'm sure Android does as well). We're getting close. I predict we'll have a working device that does exactly what I talk about within five years. It'll see widespread use in ten with all the knockoffs that'll come about.

Thats not quite what I meant about mobile devices replacing desktops. We're already starting to see it happen here and there. I highly expect our tower will be replaced by our cell phone/mobile device. Place it in a small docking station and we have a full monitor, keyboard and probably a mouse. There's little reason we couldn't do development on such a device. This is already starting to happen.

---- Let's just quit the argument at this point. There's no bashing going on in this thread. There are users legitimately concerned and upset about the sudden change. LE2 may work just fine now, but longterm support is one of the primary reasons for buying an engine. If the engine changes too much and no longer fits your needs, then it no longer is being supported in a manner conducive to your goals. A large portion of the vocal people in these boards have little interest in mobile dev. The sudden platform focus change is a legitimate concern. EDIT: I would like to mention, on a personal note, I'm fairly happy with the direction Josh is taking on this. Mobile games are here to stay. In fact I highly expect that within the next decade, our phones (or other such mobile device) will be our primary computers for most tasks. The only people still running Desktops or Laptops will be content creators, where the extra power may be necessary. And I'm not sure programmers really need all that much power in reality.

You are certainly entitled to the opinion that people bashing the engine. You however are not entitled to tell them to stop.

You clearly haven't seen his other charts. Honestly, that chart is an improvement for him. No, you're a fanboy because apparently we're not entitled to a differing opinion than your own.

You'd unfortunately be surprised. It's one of the reasons I recommend things like Github or Bitbucket so heavily. Aggror, have you looked into Assembla? They have a free package along with forums, wiki, ticketing and Git hosting.

Keep in mind most if not all functional languages are procedural/imperative languages as well. Functional languages simply have a general feature set that other procedural languages simply do not have (C for example). Not exactly. Keep in mind functional languages borrow heavily from lambda calculus. C for example lacks functions as a fundamental data type and doesn't support closures (which are fundamental to functional languages). Lua does support these things. Keep in mind, as mentioned, Lua is a procedural language. It's also multi-paradigm. For example, you rarely see looping constructs in functional languages outside of recursion. However, lua still uses functional paradigms even when using some of these "foreign" looping constructs. For example one of the foreach loop variants iterates over a table, passing each element over to a user supplied closure. In most functional languages you'll see this functionality in the map/fold/reduce functions. Lua is multi-paradigm, but it's functional roots are fairly dominant in it's entire feature set. From it's support of closures to it's Lisp like choice of a Table as it's primary data structure and the way things are designed to be used. It's very powerful, yet that power is rarely tapped as few people these days actually know how to use a functional language. You can use Lisp or Scheme as if it were C but you'll quickly find that it becomes very cumbersome until you make that paradigm shift. If you really want to learn about functional programming, pick up a pure functional language like Haskell or maybe even Scheme.

I don't have a thought, just a sound... *ugh* Lua is probably one of the most misunderstood languages in the public eye. Everyone forces OOP down it's throat all the while calling it a proceedural language. We have hacked up partial implementations of OOP paradigms in the language all over the place attempting to turn it into something it's not. Lua is a wonderful language, but it is not a language with an OOP paradigm. Lua is a wonderful language and people call it a proceedural language largely out of ignorance (If it's not OOP, it MUST be proceedural!) Lua is a wonderful language and it is a functional language. Let me say that again. Lua is a functional language. It is not a pure functional language seeing as it does in fact revolve around state and mustable data due to being designed as an embeddable language, but it is still very much a functional language. A few common misconceptions: Functions are NOT ojects. They are a fundamental datatype in most functional languages (Lua, Python, Lisp, Haskell, etc.) Tables are not Dictionaries, Hashes, Tree's or lists. Tables are a data type who's functionality is designed to be altered via metaprogramming and in effect creating new data types. Embrace it! Lua is not an OOP language. This doesn't mean you can't write an OOP model in the language. Did you know that the entire OOP paradigm was written in and for functional languages? It was originaly created in smalltalk. That said there is little resemblence to it's original intentions. One of the key original OOP concepts was a lack of global state for objects. Sadly this never carried over outside of the functional world and is part of the reason parallel programming is so difficult in the usual OOP languages. Excuse the rant. This is just one of my pet peeves (of apparently many). It's rarely taught or even understood that there are more paradigms than OOP, proceedural or imperative programming. Functional programming is only one of a great many. When I was teaching I made sure my students knew they existed and at least at a basic level, understood the difference. ---- Now as to the original question...Yes, there's no reason you can't make an entire game via Lua, depending on the scope. LE2 has it's problems with Lua, as has already been pointed out by others in the thread and so I would not suggest it. But it can certainly be done.

Do keep in mind, you can have your compiler take full advantage of any feature your processor supports. Though, in most cases, compilers default to featuresets that are common amoung most chipsets of it's type (AMD and Intel for example).

Whoever told you this is in denial. It wasn't even close to "100 times slower" when the first C compiler was released. On the whole, few programmers are going to produce assembly code more optimzed than your average compiler. Even then, it's rare to shave off more than a few pico seconds in any particular function.

Thanks for the kind words. Oh don't get me wrong, just because you fit in one group on my chart doesn't mean you won't fit in another the next day. The only difference between the three groups I listed is the willingness to learn and how far you want to go. There are only so many hours in the day and we need to prioritize what is actually import to us. Priorities what they are, not everyone has the time to continue broadening their knowledge set in a given subject. There's nothing wrong with that. I only get grumpy when someone actively refuses to learn something. ---- Just one last thing I want to clarify. When I say "academic" learning, I do not necessarily mean schooling. In fact I'd say it's rather rare to actually learn how to program in college. At most, people learn syntax and some of the basics. I consider "academic" learning to simply be active studying. Whether you get your information from school, books, online forums or google....really doesn't matter.

Unit testing isn't done very often in most dev houses (web dev tends to be the notable exception). You'll see it a lot in Java dev houses and of course with Ruby on Rails devs. I've seen it occasionally elsewhere, but it's fairly sporadic. In my experience there are really three types of programmers: The most common are those who are fresh out of college and their acedemic learning stops there. They tend to work for VB or VB equivalent Java shops. They may have some grasp of the basics, but they tend to do a lot of copy and pasting of code found on google. You don't want to work with these people if you can avoid it. Unfortunately most of the non tech biz hire these almost exclusively, usually out of ignorance or the cheaper cost. Your general programmers are a little better. General programmers tend to stick to one area of expertise and rarely learn anything outside of their usual problem domain. They do know the basics and maybe a bit more, but new paradigms or frameworks aren't much of a concern as what they already know and use works just fine. General programmers will do the occasional personal project but it's rare it's outside their usual problem domain. When it is they tend not to learn the new concepts or paradigms that go along with it and produce cobbled together projects as a result. And you have my favorite group. The fabled "Rock Star" programmer. They are constantly working on personal projects, always learning new frameworks, concepts and paradigms. These guys actually know the difference between OOP, procedural and functional languages. Usually they actually know a functional language and their code is better for it. These guys don't have a primary problem domain, they are simply problem solvers at heart. They love a challenge and they love teaching even more. They hate working with the first group and love working with the second group provided they are willing to learn and experiment. To be clear, "Rock Star" programmers are not know it alls. They have a lot of experience, but they never look down on you for not knowing something. If they do, they aren't a Rock Star programmer. They're just a jerk and a nuisance to a good team. You'll run into all three and some of them just rub you the wrong way. As for me, I've done a lot of things. I do mostly freelancing at this point in any number of areas. I taught both programming and game development at the university level for two years. I worked IT for a school district for three years (experience with both Windows Domain Controllers and Linux server/client rollouts). I've been reverse engineering programs, file formats and protocols for as long as I can remember. I've built VPN solutions in perl, inventory applications for store chains, software for automating different types of reversing and analysis, quake 2 mods and UT2k4 mods. I've a lot of experience in developing game engines and of course games themselves. Heck, I've even done a little OS dev. Oddly enough I originally went to school for art. I've got a pretty decent amount of experience doing 3D modeling, texturing and animation. My projects folder is littered with experiments and personal projects and I've got a pretty decent portfolio as a result. At the moment I'm working on two different startups (Quest Companions, check us out on Google!), one being a web service, the other being a game dev house. I'm 25 (26 in May). You're making me feel old.

It's a good mindset to have, even if you don't actually write unit tests for everything. As you become more experienced as a programmer you tend to code by the seat of your pants less and less. That time is taken up with proper planning. When you're doing it right, unit testing takes little work and time but produces far more stable code.

First, I'd just like to point out, you'll notice I didn't say I agree with TDD, I only specified what I believed to be a misconception on your part. I was defining what TDD is, versus your explanation. ---- Now that said... Put this in the context of most applications are either web enabled or cloud based to begin with. Where security is of the highest concern. TDD can and often will close off a number of attack vectors. The problem isn't just the public facing API's and views, it's anything down the call stack that happens to see that data that is at risk. TDD certainly lowers (but does not eliminate) most attack vectors. That's a big deal.

@Pixel Perfect Not necessarily. There's a big difference between simply compiling and running your code to make sure it works and TDD. TDD relies heavily on unit tests. Small tests that check the input, output and result of every function, object and method in your code are behaving as intended. It's time consuming, but you produce far more stable software. Now you'll find this isn't often done in game dev houses for a number of reasons. It however IS very common in web dev fields and any number of other development fields. I'd say the Ruby on Rails community in general would be one of the larger and best examples. It's integrated directly into the Rails solution. @Rick I follow it sporadically. It depends entirely on the work I'm doing. I do a lot of Rails work these days, so I've been doing quite a bit of it as of late. Not so much when I'm doing gamedev work, though I should seriously consider it.

Not at all. Derisive remarks? Anger and frustration over something rather minor. No, I didn't read your post with an angry face. I read it at face value. Seriously, chill dude. Mistakes happen.

Dude, try and calm down a little. Yes, he bumped a thread from two years ago. I don't think he noticed he had done so at first and he's just shrugging it off. No need to get hostile.

I think you're misunderstanding things very slightly. While Lua can be used in the editor, that is generally used for quick tests, not for actually building your game. Furthermore, if you're building your game with C++, generally lua is used strictly to script entity behavior. If you're using C++, you can load levels created in the editor. Check the documentation. Specifically here.

Those seem like pretty good reasons. Would you want to use an engine, that in your view, is more expensive and you didn't like?

I'd be very cautious about using that website. Just doing a quick glance through the Character, Vehicles, Watercraft and Weapons sections you're looking at pretty much nothing but copyright and trademark violations if you were to use them in your game. Characters are pretty obvious. I'm pretty sure Michael Bay (and a good many other individuals and corporations) would have an issue with one of the Transformers showing up in your game. Vehicle and Weapon manufacturers are also very strict about their use in games. They all require licensed usage in most cases. Turn 10, for example, just now finally came to an agreement with Porche to have their cars in Forza 4. Dice is now having issues with Textron (owners of Bell) over the use of the Viper and Huey (and several others) being used in Battlefield 3. Someone forgot to get proper licensing apparently. Just be aware of what you include in your games.

Yes it was necessary. I'm not sure where this trend of asking questions in the status updates started, but it needs to stop. It's not easily searchable for when other people have the same question. It's also completely contrary to the purpose of a status update.

It really doesn't matter if it's an issue with Newton or if it's an issue with LE. Either way, it's LE's problem as far as the consumer is concerned. Josh supposedly has a way around it, but it's not going to be fixed in LE2 if I remember correctly. Don't get me wrong, I believe Josh when he says he has a work around/fix for it, otherwise why in the world would he use it for LE3?

While that is a "solution", it's a pretty crappy one. It's not at all uncommon to model things at 1.2-10x the size and scaled in the game engine. Makes tweaking and such much easier later. And no, scaling back up, tweaking and scaling back down isn't a solution once everything is all rigged. There can be a lot of complications in doing that. LE is a great choice. I just hate that this issue is downplayed. There are few bugs with the engine, this one just being the most prominent. In general, bugs are fixed regularly and rather promptly. I've seen bugs go into the bug tracker to be fixed the same day and released. This is a good thing.