 |
||
 |
 |
 |
 |
 |
| In consideration of developing software solutions, including game Apps by Commander Tansin A. Darcos 10/10/2015, 10:23pm PDT | ||||
 |
 |
|||
| Jonsey had a comment over on Jolt Country that I realized deserved a full response but is too long to put there so I'll make it here.
After more than 50 years of working on software applications, from the stuff done on wire-wrapped electrical circuit boards, to punched cards, to text entered using keyboards or voice info, to the design of maps for games uing mouse input, to software built by other software, I've come to the conclusion that "we ain't really advanced a whole lot." Now, most of this polemic deals with almost any application development but I'm going to focus on the development of computer games, specifically adventure games. I've always felt one of the principle problems with writing using Hugo or most adventure game systems has been the lack of a well-designed tool chain to complement it. The "Tool Chain" for any language wih which to solve a problem using computers is not just the compiler or the interpreter, but includes the editor, the IDE if appropriate, support libaries, utilities used to make working with sources easier and understanding them better, and everything else used as part of the process of composing a solution to a problem using a computer. If you're editing videos for cut scenes your "tool chain" includes stock footage, sound editing tools, and stock sounds. If you're designing a map for a game it might include pre-built objects such as staircases, trap doors, and whole floors of buildings. If you're not doing a game but are editing a spreadsheet to calculate a budget for a project, your toolchain can include PDF generation tools and ability to create reports from single rows in the spreadsheet. I remember back in the early 1980s whern I was writing FORTRAN on mainframe computers, and I got my first look at the "make" system on PCs where the system kept state as to what modules had been modified and needed to be recompiled and which ones had not, and it blew me away. I realized just how far behind mainframe development had fallen compared with PC environments. So, one of the problems is lacking a good property / class editor / templating system for Hugo or other similar systems as part of the text editor makes the work harder. Cut and paste can help but a good class-oriented editor and appropriate librarian to remember classes and variables used in a program so you can create copies of them where needed or create descendents where more properties are needed for a descendent objects, can significantly improve productivity or performance of the person designing the game. Let's consider a base object that can be overridden to add new functionality and properties. If you have a "water fixture" it pours water into its trap (bowl, basin, floor) and it releases water out of its drain. It may or may not count its own use and may or may not pass usage back to a water meter. Expand that object and you have sinks, urinals, toilets, bathtubs, showers or other functions derived from the base class and where each object's properties have certain features (draining a toilet causes it to automatically refill whereas a sink does not.) But you can have broken pipes where the water drains off, water cut off for the object, master shut off for the building, etc. Now this is a simple class of object; when you get something with 20+ qualities / properties / sibling, descendant or ancestor objects, you have a big problem, especially when you have to keep all of this in your head instead of letting the program do this. And if you need different behaviors dependent upon location (I don't remember which game it was, but the pirate in either DUNGEO or Original Adventure will steal from you on a random basis, but won't steal from you before you get to certain areas in the maze), you have more problems to work out. Now this is just a simple example but it's clear that keeping all this in your head is hard work and is the sort of thing that was the "low hanging fruit" in most application development and moved to automation long ago, or at least I thought it was, and it's something that should have been for most language systems. Moving (human) memory-resident tasks to a database or into a program source as metadata is a much better use of a programmer's / developer's time. Allowing people to work indirectly with abstractions instead of directly on data is one of the things that improves people's efficiency, which is why word processors and spreadsheets were huge, massive improvements in the productivity of office workers. I have been thinking I needed to look at this more and try to fix it. |
||||
 |
 |
|||
|
In consideration of developing software solutions, including game Apps by 10/10/2015, 10:23pm PDT  plz favor object composition over class inheritance kthx NT by 10/11/2015, 4:37am PDT Re: In consideration of developing software solutions, including game Apps by 10/11/2015, 1:29pm PDT it's the unsung classic anonymous posts that are NT by 10/11/2015, 2:50pm PDT Is any of this true? I don't even know any more. NT by 10/13/2015, 8:34am PDT |
