Coding Horrors: You can gather all your technical debt into one easy framework!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »

Dicky B: Mar 23, 2004

C++ is a horrible obnoxious piece of poo poo but it also happens to be the best option for systems/high performance programming and will continue to be the best option probably until all of us are dead. Have a nice day

# ? Apr 30, 2013 21:47

Adbot: ADBOT LOVES YOU

# ? May 17, 2024 16:23

Zhentar: Sep 28, 2003; Brilliant Master Genius

I've tracked down half a dozen memory leaks in a .NET app I maintain in the past couple months. GC saves you from "true" memory leaks with unreachable objects, but there's still a wealth of ways to unintentionally keep objects live for the entire life of the program.

# ? Apr 30, 2013 21:56

Zaphod42: Sep 13, 2012; If there's anything more important than my ego around, I want it caught and shot now.

Pilsner posted:

I simply can't fathom how large C++ applications and 3D games can even function, given how insanely complex C/C++ is, notably with regards to memory allocation. My hat goes off (or condolences?) to those to can make it work. Does anyone actually think C++ is fine and dandy, or would you/they prefer a more modern language with GC, a simple and useful standard library, etc., if they had the choice?

As an interesting note, games are moving away from C++. The game engine is made in C++ and the bottlenecks and the rendering calls and all that, sure, but once that gets nailed down you can take a really, really long time to make tiny little improvements to the engine codebase.

Meanwhile, all the game specific logic is coded in a scripting language that runs on top and is much faster and easier to work in, although less efficient.

All the major players have been doing it this way for awhile, actually.

So as usual, the answer is that no one language is superior, and all have their uses. Sometimes a hybrid system is even best.

# ? Apr 30, 2013 22:23

Internet Janitor: May 17, 2008; "That isn't the appropriate trash receptacle."

The guys on C2 call this Alternate Hard And Soft Layers.

# ? Apr 30, 2013 22:27

That Turkey Story: Mar 30, 2003

awesmoe posted:

GC is frustrating and unpredictable and limited, RAII is much, much simpler than GC, c++ is fine wrt memory management as long as people don't write code like it's 1994. The standard library is incredibly limited but they're working on it.

This. Code written in modern C++ can be more concise and easier to reason about than other mainstream languages, especially with respect to memory management. It's a complicated language, but you get a lot more out of it than simply performance.

# ? Apr 30, 2013 23:21

Slurps Mad Rips: Jan 25, 2009; Bwaltow!

Speaking of C++, I'm on a project currently where only our project lead and myself have experience in C++. I've tried imparting bits of wisdom to these guys while we try to stay under memory budget. (We've gone WAY WAY over, and I've no clue how the higher ups expect us to actually get this to market).

Now I've pulled in a lot of boost, but these guys keep using pointers in the standard containers for our polymorphic types (for data that doesn't really need to be allocated). I've told them hey as long as they properly destruct the items in a container it's fine. I was tracking down a massive memory leak and found this (more or less):

code:

for (int i = 0; i < SOME_CONSTANT; ++i) {
  list[i] = new Item(i);
}
// in another classes destructor many source files away
for (WidgetListDataSource::iterator iter = list.begin(); iter != list.end(); ++iter) {
  (*iter).second->~Item();
}

They were doing so well :smithcloud:

At least they stopped doing the "if (ptr) { delete ptr; }" stuff last week.

Also, if anyone who writes C++ wants to briefly have a conniption, check out Cocos2D-X! It's literally one of the worst things I've ever seen (and we have to use it for this project :smithcloud:

)

# ? May 1, 2013 06:02

QuarkJets: Sep 8, 2008

Zaphod42 posted:

As an interesting note, games are moving away from C++. The game engine is made in C++ and the bottlenecks and the rendering calls and all that, sure, but once that gets nailed down you can take a really, really long time to make tiny little improvements to the engine codebase.

Meanwhile, all the game specific logic is coded in a scripting language that runs on top and is much faster and easier to work in, although less efficient.

All the major players have been doing it this way for awhile, actually.

So as usual, the answer is that no one language is superior, and all have their uses. Sometimes a hybrid system is even best.

As an example, almost a decade ago Civilization IV used tons and tons of Python, which also made the game very easy to mod (because Python is generally easy to pick up). Major parts of the interface, map generation, and scripted events were entirely Python, although it probably ran on an engine coded in a compiled language

e: Also memory management in C++ is pretty straightforward, you people are crazy

QuarkJets fucked around with this message at 08:39 on May 1, 2013

# ? May 1, 2013 06:09

raminasi: Jan 25, 2005; a last drink with no ice

The obnoxious part of C++ isn't memory management, it's every other drat thing.

# ? May 1, 2013 06:29

bucketmouse: Aug 16, 2004; we con-trol the ho-ri-zon-tal
we con-trol the verrr-ti-cal

GrumpyDoctor posted:

The obnoxious part of C++ isn't memory management, it's every other drat thing.

No it's function pointers. It will always be function pointers and lack of proper rtti.

You cannot comprehend true pain until you've implemented a dynamic datasource tableview ui widget in C++.

# ? May 1, 2013 09:16

Rottbott: Jul 27, 2006; DMC

Zaphod42 posted:

As an interesting note, games are moving away from C++. The game engine is made in C++ and the bottlenecks and the rendering calls and all that, sure, but once that gets nailed down you can take a really, really long time to make tiny little improvements to the engine codebase.

Meanwhile, all the game specific logic is coded in a scripting language that runs on top and is much faster and easier to work in, although less efficient.

All the major players have been doing it this way for awhile, actually.

So as usual, the answer is that no one language is superior, and all have their uses. Sometimes a hybrid system is even best.

It does not take a 'really really long time' to improve a game engine. Some are written really badly and are hard to work with, but that's because they're written badly, not because they're written in C++. Bad code can be written in any language.

Conversely games which have too much stuff implemented in scripting languages can waste a lot of programmer time, because they generally have worse debugging tools etc. People also have the idea that 'scripters' can write the game scripts, which often just means cheap/inexperienced programmers who naturally screw it all up when left to their own devices.

Personally I have learned to really hate excessive use of scripting languages, so as a result where I work (and in my personal projects) we don't use any at all. Everything is written in C++ except tools. It's really not as hard as people make out - in fact I find C++ more straightforward than e.g. C# in many ways.

# ? May 1, 2013 10:22

pigdog: Apr 23, 2004; by Smythe

Everquest used to be the most popular MMORPG for years until World of Warcraft was released and quickly dethroned it. Why? Because all of Everquest's new content was horribly buggy and slow to implement... because, it turned out, all of it had to be hard-coded in C++. WoW implemented a Lua scripting engine for its game content and was able to offer so much more at much better quality.

# ? May 1, 2013 11:48

The Gripper: Sep 14, 2004; i am winner

pigdog posted:

Everquest used to be the most popular MMORPG for years until World of Warcraft was released and quickly dethroned it. Why? Because all of Everquest's new content was horribly buggy and slow to implement... because, it turned out, all of it had to be hard-coded in C++. WoW implemented a Lua scripting engine for its game content and was able to offer so much more at much better quality.

Is this an example of why C++ is terrible for games? Because really it's just an example of how World of Warcraft learned from the mistakes of previous generations. Everquest was almost the bleeding-edge example of that whole "release a game, continue releasing new content" model everything follows now. If you design a game originally assuming that what you ship is going to be where non-triage development ends you really can't expect large-scale content expansions to be simple.

# ? May 1, 2013 12:49

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

pigdog posted:

Everquest used to be the most popular MMORPG for years until World of Warcraft was released and quickly dethroned it. Why? Because all of Everquest's new content was horribly buggy and slow to implement... because, it turned out, all of it had to be hard-coded in C++. WoW implemented a Lua scripting engine for its game content and was able to offer so much more at much better quality.

Holy poo poo this is some high-level "correlation != causation".

# ? May 1, 2013 14:11

Hughlander: May 11, 2005

pigdog posted:

Everquest used to be the most popular MMORPG for years until World of Warcraft was released and quickly dethroned it. Why? Because all of Everquest's new content was horribly buggy and slow to implement... because, it turned out, all of it had to be hard-coded in C++. WoW implemented a Lua scripting engine for its game content and was able to offer so much more at much better quality.

Calling the EQ code base C++ is being generous to the term. This is a code base that in a PCH literally has:
#define const
C with iterators would be closer to the truth.

# ? May 1, 2013 14:43

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

pigdog posted:

Everquest used to be the most popular MMORPG for years until World of Warcraft was released and quickly dethroned it. Why? Because all of Everquest's new content was horribly buggy and slow to implement... because, it turned out, all of it had to be hard-coded in C++. WoW implemented a Lua scripting engine for its game content and was able to offer so much more at much better quality.

Actually that was one of the cool things about the windows script control in the 90's, it became braindead simple when doing windows programming to just instantiate the windows script control, run some jscript or whatever, and pass values to and from the scripts. It isn't a new idea by any stretch of the imagination.

# ? May 1, 2013 15:00

hobbesmaster: Jan 28, 2008

Hughlander posted:

Calling the EQ code base C++ is being generous to the term. This is a code base that in a PCH literally has:
#define const
C with iterators would be closer to the truth.

The game was released in 1999, C++ in 1999 was pretty terrible.

# ? May 1, 2013 15:08

One Eye Open: Sep 19, 2006; Am I awake?

Scaevolus posted:

Coding horror: a C++ code base where the author doesn't realize delete, like malloc, works with nulls. He then proceeds to manage all his memory manually, with null checks around the deletes.

I think it come down to the fact that in ~80386 days and earlier delete cost a function call, as it wasn't inlined many(if any) compilers, so it was quicker to run the comparison (which would have been run in the delete implementation anyway) than to call delete. If you were trying for as few cycles as possible(barring any mispredicted branches which might have been there anyway) you would do the test. I suppose it's just been cargo-culted forward, so people still do it.

Calling functions was one of the big bugbears in game optimization/simulation optimization of the early 90s (due to preserving registers, the CALL opcode taking up to ~98 cycles, etc), and as people moved over to C++ and were presented with different optimisation problems, they kept some of the older ones from C.

# ? May 1, 2013 15:29

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Rottbott posted:

Personally I have learned to really hate excessive use of scripting languages, so as a result where I work (and in my personal projects) we don't use any at all. Everything is written in C++ except tools. It's really not as hard as people make out - in fact I find C++ more straightforward than e.g. C# in many ways.

Well if you're writing a game and want a mod community that's larger than the subset of your players who are willing and able to hand-edit binaries in a disassembler, then that approach won't work out very well.

Here's a modern example: http://www.gaslampgames.com/2013/01/30/hooray-for-scripting-and-other-things-we-did-in-the-past-two-weeks/

# ? May 1, 2013 16:11

Slurps Mad Rips: Jan 25, 2009; Bwaltow!

Hughlander posted:

Calling the EQ code base C++ is being generous to the term. This is a code base that in a PCH literally has:
#define const
C with iterators would be closer to the truth.

let's also not forget that SOE wasn't even using source control for the first year or so of Everquest.

# ? May 1, 2013 16:12

That Turkey Story: Mar 30, 2003

bucketmouse posted:

No it's function pointers. It will always be function pointers and lack of proper rtti.

You cannot comprehend true pain until you've implemented a dynamic datasource tableview ui widget in C++.

In modern C++ you generally don't use function pointers unless you are dealing with an old API or C code. We have function objects and lambdas. Even then, what exactly is your problem with function pointers? Is it just that they aren't lambdas?

Rottbott posted:

It does not take a 'really really long time' to improve a game engine. Some are written really badly and are hard to work with, but that's because they're written badly, not because they're written in C++. Bad code can be written in any language.

Conversely games which have too much stuff implemented in scripting languages can waste a lot of programmer time, because they generally have worse debugging tools etc. People also have the idea that 'scripters' can write the game scripts, which often just means cheap/inexperienced programmers who naturally screw it all up when left to their own devices.

Personally I have learned to really hate excessive use of scripting languages, so as a result where I work (and in my personal projects) we don't use any at all. Everything is written in C++ except tools. It's really not as hard as people make out - in fact I find C++ more straightforward than e.g. C# in many ways.

Seconded. I've worked on a couple of titles where a lot of stuff was done in Lua by designers. Here's the issue -- the programmers of the C++ side or C side or whatever language your engine is in spend a decent chunk of their own time exposing the needed functionality to the scripting language, including things like making sure they are "Lua-like" interfaces (make indices start at 1 instead of 0). As well, those who write the scripts, as you pointed out, are often designers that generally aren't great at programming because that's not really their job. If you're not an experienced programmer, you're going to produce poor code regardless of the language you are writing it in. A "scripting" language is usually no easier to write good code in, it's often only easier to learn, so moving the bulk of the code over to one of these languages just ends up gimping programmers that need to write in it. In reality, if you're a programmer and you had a choice to write a large game entirely in Javascript rather than something like C++ or C#, you probably wouldn't do it, and performance likely isn't even the primary reason. If Python and Lua were all of a sudden exactly as fast as writing everything in C, you probably still wouldn't see large titles entirely switch to them.

Scripting does definitely make it easier for gamers to get into modding your game because there's not a steep learning curve and no explicit build process, so I agree that it's a good idea if that's something you're interested in supporting, but I find that it provides more problems than it's worth if your only goal is to attempt to speed up the development process for the game itself. I've had to debug or write or rewrite scripts for designers so much that I really start to question the gain -- I will write base functionality in the host language, expose it to the scripting language so that a designer can use it in a small handful of places (sometimes even just one or two places), then write or debug or rewrite the use of it for them in that scripting language anyway. We've also seen the scripting language become a bottleneck and have had to start moving functionality back to the host language, even when JITed (turns out creating lots of objects in something like Lua is not a fantastic idea -- "hardcore" Lua developers have even developed complicated patterns in an attempt to get around the problem). The underlying issue is that the more programming you do in a scripting language, the more beneficial it is to just work directly in the host language, whatever it may be. Conversely, when you're doing only a little bit in scripting, I'm often not certain it's worth the effort to maintain an interface for the scripting language, especially if the people writing in that language are programmers anyway.

Also, if you don't follow the Game Development thread, check out Orzo's work. It's in C# and originally used Lua for scripting until he ditched scripting entirely for many of the reasons mentioned. He makes very consistent progress -- likely more progress than if he had kept his project partitioned, as I imagine he'd agree. A lot of the "write this part of your game in a scripting language" is cargo cult mentality, especially alluring to those that are new to programming since they're often not yet comfortable in statically typed languages.

That Turkey Story fucked around with this message at 17:25 on May 1, 2013

# ? May 1, 2013 17:05

hobbesmaster: Jan 28, 2008

That Turkey Story posted:

In modern C++ you generally don't use function pointers unless you are dealing with an old API or C code.

Old APIs like say win32?

# ? May 1, 2013 18:14

Pilsner: Nov 23, 2002

pigdog posted:

Everquest used to be the most popular MMORPG for years until World of Warcraft was released and quickly dethroned it. Why? Because all of Everquest's new content was horribly buggy and slow to implement... because, it turned out, all of it had to be hard-coded in C++. WoW implemented a Lua scripting engine for its game content and was able to offer so much more at much better quality.

You're right that EQ was horribly buggy and slow to implement features, but EQ got overtaken by WoW because of WoW's game features, terrible SOE developers (not technically) and a bad expansion that was the final straw. WoW also came 5 years after EQ, and based everything - dos and don'ts - on EQ.

Even still, you can't LUA script everything. For example, core elements like the combat engine, loading of assets, chat, interaction with the world, spell casting and well, practially everything that's part of the core of the game, and how the scripts are actually parsed and translated into actions in the game (for example, boss charges a player) is ultimately written in "real" code. Adding more or less content, like a new zone or a new NPC, doesn't (or: will infrequently) cause bugs.

Eeeeeeeven further, EQ definitely used scripting of some sort. For example, the spawn mechanics of a zone were scripted; an EQ developer has posted an example script:

code:

ENCOUNTER_DESCRIPTION SROHusamAncientNightfall
MONSTER_1_NAME a_desert_madman
MONSTER_1_NIGHT_NAME an_ancient_cyclops
MONSTER_1_PERCENT 10
MONSTER_2_NAME a_sand_giant
MONSTER_2_NIGHT_NAME a_mummy
MONSTER_2_PERCENT 20
MONSTER_3_NAME a_sand_giant
MONSTER_3_PERCENT 10
MONSTER_4_NAME a_dervish_cutthroat
MONSTER_4_PERCENT 30
MONSTER_5_NAME a_desert_madman
MONSTER_5_PERCENT 30

I don't think bosses in the first many expansions had any scripting though, they just had special spells, melee and would act like any regular mob. There was literally no difference.

# ? May 1, 2013 18:17

ymgve: Jan 2, 2004; Offensive Clock

Here's a small thing to make you feel better about your day

# ? May 1, 2013 18:21

Toady: Jan 12, 2009

pigdog posted:

Everquest used to be the most popular MMORPG for years until World of Warcraft was released and quickly dethroned it. Why? Because all of Everquest's new content was horribly buggy and slow to implement... because, it turned out, all of it had to be hard-coded in C++. WoW implemented a Lua scripting engine for its game content and was able to offer so much more at much better quality.

World of Warcraft uses Lua for its client interface, not its content.

Zaphod42 posted:

As an interesting note, games are moving away from C++. The game engine is made in C++ and the bottlenecks and the rendering calls and all that, sure, but once that gets nailed down you can take a really, really long time to make tiny little improvements to the engine codebase.

Meanwhile, all the game specific logic is coded in a scripting language that runs on top and is much faster and easier to work in, although less efficient.

All the major players have been doing it this way for awhile, actually.

So as usual, the answer is that no one language is superior, and all have their uses. Sometimes a hybrid system is even best.

Scripting languages on top of a native engine aren't a new thing. For a number of reasons, Epic and id Software are moving away from scripting languages toward languages with better compile-time checks. Carmack talked about this in 2011:

'One of the lessons that we took away from Doom 3 was that script interpreters are bad, from a performance, debugging, development standpoint. It�s kind of that argument �oh but you want a free-form dynamically typed language here so you can do all of your quick, flexible stuff, and people that aren�t really programmers can do this stuff�, but you know one of the big lessons of a big project is you don�t want people that aren�t really programmers programming, you�ll suffer for it!

But one of the things that we did is�because the other side of it is also performance�you�d think that with our million-times faster systems that, it�s like �ah, scripting some things, performance should be a non-issue.� And it�s striking almost how much that isn�t the case. In the last month of Rage�s development we�re taking some of our Flash GUI stuff and converting it to C++ because the interpreter for doing the ActionScript stuff in the GUI is taking multiple milliseconds sometimes. Even with all of our wealth of processing power, we still don�t have enough performance; performance still matters.'

# ? May 1, 2013 18:28

That Turkey Story: Mar 30, 2003

hobbesmaster posted:

Old APIs like say win32?

An old C API written by a certain company is not indicative of modern C++.

# ? May 1, 2013 18:35

bucketmouse: Aug 16, 2004; we con-trol the ho-ri-zon-tal
we con-trol the verrr-ti-cal

That Turkey Story posted:

In modern C++ you generally don't use function pointers unless you are dealing with an old API or C code. We have function objects and lambdas. Even then, what exactly is your problem with function pointers? Is it just that they aren't lambdas?

I think "Old terrible APIs" about covers it, it's nothing against the feature as much as how people can abuse it. Here comes a void* that is actually a function pointer with one of 3 possible signatures, better ask the god object what it is!

# ? May 1, 2013 18:46

Rottbott: Jul 27, 2006; DMC

That Turkey Story posted:

Conversely, when you're doing only a little bit in scripting, I'm often not certain it's worth the effort to maintain an interface for the scripting language, especially if the people writing in that language are programmers anyway.

Lua can be the exception here, given how simple it is to integrate. I use it for one thing at the moment - player-programmable 'computer' modules in my space game. A few 10-20 line functions are implemented in Lua (e.g. ship stability control) which allows sufficiently nerdy players to fiddle with it. Really very minor but worth it because it's so simple to do.

More involved modding support is the best argument I've heard for it - although my perspective is mainly from writing console games - but even then I'd probably just make modders use C++, it'd do them good.

The worst horrors of game scripting usually involved either a) large chunks of fundamental gameplay implemented in script, making it slow, un-debuggable and obnoxious to call from C++, or b) C++ calling Lua which calls C++ which calls Lua.

Don't even get me started on MenusMaster, Scaleform etc.

# ? May 1, 2013 22:45

Zaphod42: Sep 13, 2012; If there's anything more important than my ego around, I want it caught and shot now.

Rottbott posted:

It does not take a 'really really long time' to improve a game engine. Some are written really badly and are hard to work with, but that's because they're written badly, not because they're written in C++. Bad code can be written in any language.

Conversely games which have too much stuff implemented in scripting languages can waste a lot of programmer time, because they generally have worse debugging tools etc. People also have the idea that 'scripters' can write the game scripts, which often just means cheap/inexperienced programmers who naturally screw it all up when left to their own devices.

Personally I have learned to really hate excessive use of scripting languages, so as a result where I work (and in my personal projects) we don't use any at all. Everything is written in C++ except tools. It's really not as hard as people make out - in fact I find C++ more straightforward than e.g. C# in many ways.

Read what I said. I said you can take a long time not it takes a really long time. :colbert:

SAHChandler posted:

let's also not forget that SOE wasn't even using source control for the first year or so of Everquest.

Good god. Well, I guess games like Quake 3 were still being coded in hard C. So EQ being in C/C++ with no source control isn't so crazy.

1999 was just the dark ages.

Zaphod42 fucked around with this message at 22:59 on May 1, 2013

# ? May 1, 2013 22:56

hobbesmaster: Jan 28, 2008

That Turkey Story posted:

An old C API written by a certain company is not indicative of modern C++.

It certainly isn't but you still have to deal with its crazy interfaces.

boost::bind to the rescue, but still.

# ? May 1, 2013 22:58

more like dICK: Feb 15, 2010; This is inevitable.

edit ^^^ I know boost::bind still has functionality that std::bind doesn't. Is that functionality still needed for Win32 (I don't do Windows)?

Here's a horror RE: scripting in games (depending on your perspective)

The game I'm working on uses Prolog as the "scripting" component. It's used to model some constraint based systems, and a REPL is exposed to the player so they can ~~break~~ fix things as they break :science:

more like dICK fucked around with this message at 23:03 on May 1, 2013

# ? May 1, 2013 23:01

Zaphod42: Sep 13, 2012; If there's anything more important than my ego around, I want it caught and shot now.

Toady posted:

World of Warcraft uses Lua for its client interface, not its content.

That's a good distinction; they're only using it so you can script your own UI and addons.

How much do we know about the WoW engine though? They could be using some kinda scripting system for world building, too.

Toady posted:

Scripting languages on top of a native engine aren't a new thing. For a number of reasons, Epic and id Software are moving away from scripting languages toward languages with better compile-time checks. Carmack talked about this in 2011:

'One of the lessons that we took away from Doom 3 was that script interpreters are bad, from a performance, debugging, development standpoint. It�s kind of that argument �oh but you want a free-form dynamically typed language here so you can do all of your quick, flexible stuff, and people that aren�t really programmers can do this stuff�, but you know one of the big lessons of a big project is you don�t want people that aren�t really programmers programming, you�ll suffer for it!

But one of the things that we did is�because the other side of it is also performance�you�d think that with our million-times faster systems that, it�s like �ah, scripting some things, performance should be a non-issue.� And it�s striking almost how much that isn�t the case. In the last month of Rage�s development we�re taking some of our Flash GUI stuff and converting it to C++ because the interpreter for doing the ActionScript stuff in the GUI is taking multiple milliseconds sometimes. Even with all of our wealth of processing power, we still don�t have enough performance; performance still matters.'

Yeah, that's true. I wasn't saying it was new, just that not all games are pure C++ for performance reasons like he was suggesting. Yes, getting further into the picture even that is starting to be old and games are getting more complicated.

That keynote by Carmack was fascinating (as always), he seems to be really in love with static analysis.

I do of course completely agree with scripting not being an excuse to hire non-programmers, but I guess you have to worry about pointy haired bosses wherever you go.

Hm, I guess Id uses Scaleform for their UI, too? I've worked with it briefly, but I wonder why its so drat popular, seemed kinda meh to me. I guess nobody wants to program UI, and flash designers are cheap?

Rottbott posted:

Lua can be the exception here, given how simple it is to integrate. I use it for one thing at the moment - player-programmable 'computer' modules in my space game. A few 10-20 line functions are implemented in Lua (e.g. ship stability control) which allows sufficiently nerdy players to fiddle with it. Really very minor but worth it because it's so simple to do.

Yeah, though even that's because you want the player to script. I don't buy the argument that, entirely developer side, it's worth it to expose some minimal scripting functionality in an attempt to somehow simplify or speed up the development process of that game. If all you need is a few 10-20 line functions, I find it hard to believe that doing so in the host language is at all more difficult or time consuming than exposing that functionality to a scripting language, and then writing that little bit of code in the scripting language. It's just introducing more work and also more that could go wrong for effectively no gain.

Of course, as soon as you expose the scripting language to modders, you actually do get things that are valuable. You want there to be little to no learning curve so that anyone can make something, even if it is trivial. You want the language to at least be similar to a language that lots of people already know, even if they aren't programmers (I.E. Lua is very similar to Javascript). You don't want the person to have to go through a build process to get things running. You don't really care if someone produces bad code that's impossible to maintain. All of these things are important if you want to produce a game with a large modding community. None of these things are important if you just want to make a good game, except for possibly the lack of an explicit build process.

Edit:

hobbesmaster posted:

It certainly isn't but you still have to deal with its crazy interfaces.

Yeah, true, but at some point we do have to criticize them for simply having old C libraries without modern C++ APIs. It's unfortunate that an ISO language not designed by any particular company often gets looked down upon because of non-standard libraries written by one source many years ago.

Also, stateless C++11 lambdas are convertible to function pointers, which does help a bit for dealing with legacy interfaces without even having to deal with template voodoo. And if you care about what's to come, generic lambdas (lambda function templates) recently got accepted into the next standard, so there will be little reason to even have to deal with bind or Boost.Phoenix anymore, so expression template haters can relax a bit.

That Turkey Story fucked around with this message at 23:25 on May 1, 2013

# ? May 1, 2013 23:10

seiken: Feb 7, 2005; hah ha ha

Seeing as we're talking about Lua embedding in the coding horrors thread, I may as well share this definite horror I just wrote:

C++ code:

// C++ functions we can call from Lua

lua_api(hello) lua_arg(std::string, t)
{
  std::cout << "hello you passed " << t << std::endl;
  // Return nothing
  lua_nil();
}

lua_api(multiply) lua_arg(int, t) lua_arg(int, u)
{
  // Variadic macro + template returns any number of values
  lua_return(t * u);
}

This magic file gets included after a bunch of #defines which mean the lua_ macros expand into namespaces, template function calls and so on, to make these into real C++ functions which pop all the arguments off the Lua stack (checking types) and push the return values on.

Then the lua_ macros get re-#defined into completely different things and the file is included a second time from inside of a function body, expanding into a function which automatically registers all the function names and their addresses onto a passed Lua state (so there's no need to maintain a duplicated list of function names "hello", "multiply" or function pointers anywhere in order to expose them to Lua) :2bong:

Edit: mainly a horror because the error messages are going to be loving nonsensical

seiken fucked around with this message at 00:21 on May 2, 2013

# ? May 1, 2013 23:57

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Zaphod42 posted:

Hm, I guess Id uses Scaleform for their UI, too? I've worked with it briefly, but I wonder why its so drat popular, seemed kinda meh to me. I guess nobody wants to program UI, and flash designers are cheap?

Flash is actually really good at custom interactive UIs. It has an absurdly flexible timeline system for animations and state machines, meaning it's super easy to get juicy HUDs and game menu UIs with a minimal amount of effort, since you don't have to write a 2D animation system and all the tooling that comes with it. It's also vector-based, which means it scales nicely with different game resolutions. Scaleform also put a lot of effort into making everything super easy to integrate with your own game engine, and integrate nicely with the Flash authoring environment.

# ? May 2, 2013 00:07

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

I do think it's a worthwhile idea to have a lighter-weight language for level designers and such to use to wire things up. Push-button-to-open-door doesn't seem like the sort of thing you need a programmer for, and having to stop designing to ask someone else to wire it up for you seems like it would definitely slow things down. I think the trick is to deliberately make it crippled enough that no-one is tempted to try and implement any actual game functionality in it.

See Kismet from UDK for an example of this taken to an extreme.

# ? May 2, 2013 00:23

seiken: Feb 7, 2005; hah ha ha

Jabor posted:

I do think it's a worthwhile idea to have a lighter-weight language for level designers and such to use to wire things up. Push-button-to-open-door doesn't seem like the sort of thing you need a programmer for, and having to stop designing to ask someone else to wire it up for you seems like it would definitely slow things down. I think the trick is to deliberately make it crippled enough that no-one is tempted to try and implement any actual game functionality in it.

See Kismet from UDK for an example of this taken to an extreme.

Even if you agree that nobody but programmers should write code (which I for the most part do, actually), having a scripting language for real programmers to write real code in still brings you all the flexibility advantages along the lines of iteration without recompilation, easy hot-swapping & so forth. Whether these advantages outweigh having to maintain the interop stuff depends on your project (choice of host language, especially) I guess but they're worth considering even if you're not explicitly focused on the mod scene shindig

seiken fucked around with this message at 00:34 on May 2, 2013

# ? May 2, 2013 00:31

pseudorandom name: May 6, 2007

Unreal 4 kept Kismet for level designers who can't code, got rid of UnrealScript entirely, and made it so you can hot-swap the C++ game logic without restarting.

# ? May 2, 2013 00:39

That Turkey Story: Mar 30, 2003

pseudorandom name posted:

Unreal 4 kept Kismet for level designers who can't code, got rid of UnrealScript entirely, and made it so you can hot-swap the C++ game logic without restarting.

If Cling picks up some steam, I could definitely see it making stuff like that much more trivial for any project to be able to do. It would be useful to be able to "script" in C++ for fast iteration (assuming the host language is also C++), and since both the scripting language and host language are the same, you can very easily take all of that code, or parts of that code, and use it directly in the built project once things are more set in stone.

# ? May 2, 2013 00:47

Freakus: Oct 21, 2000

Jabor posted:

Push-button-to-open-door doesn't seem like the sort of thing you need a programmer for, and having to stop designing to ask someone else to wire it up for you seems like it would definitely slow things down.

And next thing you know you have 10+ ways to do the same exact thing in your script codebase.

# ? May 2, 2013 00:48

Adbot: ADBOT LOVES YOU

# ? May 17, 2024 16:23

UraniumAnchor: May 21, 2006; Not a walrus.

So I ran across this while trying to write some Ruby:

code:

$ cat gently caress.rb 
def what
       return 'the'
end

puts "'#{what}'"

if false then
       puts "hello"
       what = "gently caress"
end

puts "'#{what}'"
$ ruby gently caress.rb 
'the'
''

On what planet is this sane behavior? Can somebody explain to me what is going on here?

# ? May 2, 2013 01:27

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »