• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

issch

Members
  • Content count

    699
  • Joined

  • Last visited

Community Reputation

479 Neutral

About issch

  • Rank
    GDNet+

Personal Information

  • Location
    Ireland
  1. I really dislike parallax scrolling on websites. I find it very distracting and makes it hard to focus on the actual content. Please don't ever do it.
  2. I'm a gamer and I know a lot of other gamers and all of us use steam quite heavily. A handful occasionally buy games on gog.com too. Most buy humble bundles. Very few use any of the other distribution platforms (desura, origin, impulse). Personally, I wouldn't install anything other than steam, so as a gamer, its highly highly unlikely that I or almost all of the gamers I know would install another distribution platform.   Unless it has something EXTREMELY compelling.   I mean, more compelling than Humble Bundle's pay what you want bundles (or, at least, a bigger/better library of HIGH QUALITY games in that model). Indie games are a dime a dozen - the greatest find their way into Humble Bundles or get onto Steam through the greenlight program anyway, so a large free-for-all in Indie games doesn't cut it IMHO. Too much noise. So unless your "official" catalog is really great or has some insanely good exclusives, I don't see how this can compete without something else that is extremely compelling (and the only thing I can think of is _maybe_ a hybrid mix between Humble Bundle and Kickstarter, but I'm not sure if it would work or if that's enough).   I'm not sure what you can offer developers (especially medium and bigger studios) to help make your catalog great.   Sorry to be so negative, but its a very tough space to break into IMHO.
  3. Does anybody remember the pink gang? Though that may have been 2004. I had a different username in those days.
  4. In my experience, native clients are not dead, at least in some industries when it makes sense (eg visualisation heavy or processing heavy applications and applications where offline access is desired). I've seen plenty of desktop GUI applications been built in Qt. I haven't seen that much in Java lately, but I'm sure it exists. Mobile native apps are also very popular.   There is definitely a trend of things moving to web apps, but I don't think its over yet for thick clients. It will probably become ever-more niche though in the coming years.
  5. [quote name='LorenzoGatti' timestamp='1345731283' post='4972578'] Don't be too philosophical: classification of objects and relations are only important in software design if they are actually used.[/quote] I was merely pointing out how composition has a better real world analogue than inheritance. An analogy to explain how is-a isn't as clear cut as it first seems. In most software, you are unlikely to require the flexibility of adding or removing components at runtime, but I feel that in games, having the ability to do so should you want to is a huge bonus and allows you to do cool things that would otherwise be hard. Ideally, the development kit would be able to bake entities that do not use the flexibility so you don't pay for it if its not used, but I see that as an optimisation (which should be done later). I think it rarely makes sense to hard code limitations into the very design. [quote]Howitzer and MachineGun because the distinction cannot possibly matter, ever, because all code works with generic Weapon entities.[/quote] Sure - I would see them as being the one Gun or Weapon component and the differences between them are defined purely in a data-driven way: their attributes have different values. Data-driven design is certainly a very good thing. [quote]Removing pieces of objects is also utterly uninteresting from a software design viewpoint, not only because we never ask whether the mutilated object "is-a" something[/quote] Sure - but I often see it driving a design. Often people start with "Well, X is-a Y, so I'll derive X from Y and..." while I think this is the wrong approach. Instead, I feel is-a is only useful in the sense of "does it provide the interface I need?" - think of it like duck typing. So, instead of trying to figure out if something is a type of something else or if it has a something else instead and then building an inheritance hierarchy from this, I feel a better approach is to compose all components rather than inheriting from them. I used to like hardcore OO a number of years ago, but these days I find it has too many limitations, both in design (as I've been trying to articulate in this thread) and technically: eg, OO and concurrency/parallelism, OO and cache/memory friendliness etc. Therefore I nowadays prefer a functional-programming approach, though I still code in a style that I would consider somewhat OO - except that my entities are now compositions of components with little or no inheritance in sight - functional programming makes it easy to compose both data and functions. When I program in C++, I obviously do use classes and even inheritance, but I still like to design my programs with functional programming in mind and I find that it not only simplifies the design and makes it more flexible (in real life that flexibility often gets traded off for performance later when its apparent that having two components instead of one is 1) not required and 2) a performance issue), but it also makes it easier to support concurrency safely and to solve cache/memory issues - hell, that was one of the big goals of component entity systems after all. [quote]but more importantly because the altered entity is either in a valid state or corrupt, according to the invariants and expectations that the code contains; nothing uncertain or ambiguous can happen.[/quote] Sure. This is a very important point, regardless of the design.
  6. [quote name='CC Ricers' timestamp='1345646602' post='4972210'] LorenzoGatti has a point, that the Tank and Cannon example may not be a very good one here. In most cases having a distinct Cannon class is not necessary. For most use cases in games, you are breaking down the object into more parts than you need to. [/quote] Sure - you can always simplify and flatten things down if you like. I mean, on the other extreme, you could represent all Actors as the same class, have a bunch of flags represent the different things your Actor might want to do (canShoot, canFly, canCarryPerson, isPerson) and handle all the code in one place but vary the models or sprites or whatever visual data you have. Obviously a balance between the two extremes needs to be found and the question one needs to ask is what level of flexibility do you need and what data do each of your game systems need. If you have vehicles that drive with reasonably accurate physics (so any game where driving is a big focus), your physics engine might indeed simulate wheels and your game logic might indeed have an engine that handles how it drives (or at the least is a pure data container with all the properties representing the engine: power, weight, whatever) - the point, as I see it, of component entity systems is that the components can be simple data containers if that's all you need, or they can have systems with complex logic associated and components in themselves are extremely cheap (eg they could be allocated from a memory pool, they could be cache line aligned, the processing loop could prefetch...). But that's besides the point I was implying in my previous post - obviously the example was a contrived one. The real point wasn't even specific to game programming, but rather that in my opinion composition is much more natural to inheritance in that with real world objects, entities can often be classified as many things (I'm a living thing, I'm human, I'm a programmer, whatever...) that are dependant on the entities state (either internal or external) and that entities are composed of many things. Also often removal of some of these things does not cause the entity to lose a is-a relationship, removal of other things might (but exactly which things may not be well defined - if I kept removing parts of my body, when do I stop being human?). Then I went and mentioned some ideas which [i]could[/i] be used to take the concept even further. I think that this idea is just as applicable in software outside of games too. But obviously, as you imply, a balance must be struck to find the level of abstraction that best fits the problem space - but isn't this always the case, regardless of how the problem is being modeled (OO or otherwise)?
  7. On the topic of is-a vs has-a: With the traditional inheritance-based approach, every entity must have at least one is-a relationship and zero or more has-a relationships. So, if a Tank is composed of a Vehicle and a Cannon, is a Tank a Vehicle that has a Cannon, or is it a Cannon that has a Vehicle? Obviously the former, in this case, so lets go down to the next level. A Vehicle is composed of a Chasis, some Wheels and an Engine. Is a Vehicle a Chasis that has Wheels and an Engine? Is it an Engine that has a Chasis and Wheels? Again, the former makes most sense, but at what point does a Chasis stop being a Vehicle? If it has no Wheels and no Engine (and so is basically a stationary frame), its hardly a Vehicle any more: [i]"A vehicle is a mechanical means of conveyance, a carriage or transport."[/i] So you could encode some rules into your class that ensures that a Vehicle always has an Engine and Wheels. But what if we want a Plane? A Boat? A HotAirBalloon? Through the use of additional layers of abstraction and complicated inheritance hierarchies it is possible to come up with a structure that allows this kind of flexibility (A Vehilce is a Chasis that has a PropulsionSystem, A PropulsionSystem is a... whatever, through additional layers in the hierarchy, eventually we can encode what we need), but at the cost of significant complexity (and complexity = bugs, often!) and work and god forbid something needs to change later! The alternative is to introduce an abstract "is a" which we will call an entity. An entity consists of (is composed of, has a) a number of components. Components are generally self contained. So a Tank is an entity and that entity consists of a Chasis, an Engine, Wheels (or Tracks), a Cannon... A Plane is an entity which consists of a Chasis, JetEngine, Wings.... A HotAirBalloon is an entity which consists of a Basket and a Balloon... The rules of what makes a Vehicle a vehicle or a Tank a tank (or a Tank a Vehicle) are now longer hard coded into a class, but instead is now coded into the constructor function of that entity: make_tank(...) contains all the code to make sure that the entity it creates adheres to the interface required for a tank or a vehicle or a weapon or whatever else that entity should be. It is this interface which defines the is-a relationship. Duck typing, if you will. The concept could be expanded to allow entities to be derived: a Tank is a Vehicle entity with a Cannon component (and its basically a union of the set of components that make up a Vehicle and the set of components that make up a Cannon - each component could itself be treated as an entity which contains only itself in its set, so if later Cannon consists of a Turret and FiringMechanism, the definition of Tank need not change). But you should also be able to swap components out: A Tank = Vehicle ? Cannon ? Tracks ? Wheels. Finally, the concept could be extended to allow interfaces (similar to Java interfaces, but that are implemented by the union of the components in the set that makes up the entity - again, duck typing). That is, IVehicle is an interface through which you can interact with vehicles. It doesn't care how the vehicle is a vehicle as long as it acts like one (ie it has the IVehicle interface). It could meet this interface by composing the Engine and Wheel and Chasis components or through Basket and Balloon or whatever you want. I feel that is a is an abstract concept that describes the union of all the has a parts - a set of interfaces (a Tank is a IVehicle and a IWeapon for example) that describes what the set of components (ie entity) represents and I feel this is more true to real life than inheritance hierarchies, which don't seem very natural (from a real live POV) to me at all.
  8. Trying to shoehorn parallelism into a program is never the right approach. To really make use of it, the program must be designed with it in mind. Furthermore, shoehorning parallelism into a program does not really mean you have experience in multicore programming. Injecting people with random-but plausible medication does not mean I have medical experience. Also, if they are asking for professional multithreaded programming experience (which is what companies often mean when they ask for experience), this won't really help you either. Having said that, if you really want to learn multithreaded programming, I would recommind reading [b][i]both[/i][/b] of the books I mention below. [b]Multithreaded programming is hard[/b] and you won't get good at it reading internet tutorials. You probably won't get good at it by reading any one book. I've found both of these books to be very good, but even after working through them (and reading alone is never enough), you must practice what they teach. After reading the books and having practiced the concepts taught for yourself, my recommendation is to never use this in production code at all - instead, find a task-based library written by experts and use that. Do not roll your own threading code and do not use [i]threads[/i] for performance[sup][1][/sup]! Instead use a task-based library. I personally recommend Intels [url="http://threadingbuildingblocks.org/"]Threading Building Blocks[/url][sup][2][/sup], though other equally good libraries exist. Anyway, here are my two book recommendations (to be read in this order):[list=1] [*][url="http://www.amazon.com/The-Multiprocessor-Programming-Maurice-Herlihy/dp/0123705916"]The Art of Multiprocessor Programming[/url] [*][url="http://www.amazon.com/Patterns-Parallel-Programming-Timothy-Mattson/dp/0321228111/ref=sr_1_1?s=books&ie=UTF8&qid=1337390314&sr=1-1"]Patterns for Parallel Programming[/url] [/list] [sup][1][/sup] Threads are a decent choice for [i]concurrency[/i] but a bad choice for [i]parallelism[/i]. That is, if what you need is asynchronous execution (eg, loading resources from disk without blocking while your game is running) - concurrency - then threads are a good choice. If, however, you want to use multiple cores to increase performance by doing multiple things at once - parallelism - then you should not use threads directly, but use tasks instead. The idea is that you have exactly one thread per core and work is scheduled between these. [sup][2][/sup] A good way of learning to use Intels Threading Building Blocks it through the [url="http://shop.oreilly.com/product/9780596514808.do"]OReilly book[/url] (though the tutorial on the official site is equally good). The first chapter is available [url="http://softwarecommunity.intel.com/isn/downloads/intel_tbb_ch01_for_promo.pdf"]here[/url].
  9. [quote name='ApochPiQ' timestamp='1334595834' post='4931781'] In brief, I quit contracting for four reasons: [/quote] Thanks!
  10. My suggestion is to develop using the [url="http://impactjs.com/"]Impact[/url] html5/javascript game engine and target browsers and mobile (iOS and Android through AppMobi (both) or iOSImpact (iOS)). Browser may be hard to monetize, but AppMobi and iOSImpact package your game for the app stores.
  11. [quote name='touch_the_sky' timestamp='1334267294' post='4930713'] [quote] If someone offers you 200k[/quote] Just an example, I did think that no one will think about this sort of money as an entry-level salary though;) [/quote] The most effective way to get a pay increase is to switch employers[sup]1[/sup]. Gone are the days where you work for one company for your entire life. It doesn't matter if your pay is capped at X in your current job if you can switch jobs and get X+n. The important thing is to do things which will make said other employer want to hire you when the time comes and if your current job isn't making you more employable over time, then it may be worth leaving a little earlier than you otherwise would or engaging in open source projects or anything else that makes sure you'll be valuable enough to other employers that they will pay more than you currently make. Also, learn to be a good negotiator. I keep reading about how people consistently accept much lower than the company was prepared to pay because they accepted whatever the company offered without negotiating properly. [sup]1[/sup]Employers will give you pay increases if they're any good at all, but often switching will give you larger increases and sooner. If you really like your job and the people you work with and your employer does give you reasonable room to grow and increase your earnings, then by all means stay! [quote name='ApochPiQ' timestamp='1334555916' post='4931642'] As an interesting data point, I personally freelanced for a number of years before giving up and joining the rat race. I'll never go back to contracting, and if you're genuinely interested, I'd be happy to lay out why. [/quote] I'd be interested to hear why, though I suspect I know already, since I've done both contracting and corporate employment myself (and am now doing a startup).
  12. [quote name='Antheus' timestamp='1334526977' post='4931553'] But why not? [/quote] [quote name='Antheus' timestamp='1334526977' post='4931553'] Why shouldn't I experiment with live data. Best way to ensure my work is correct is to use actual data set. [/quote] I completely agree. I don't think we're there yet, in the general case, but this is something we should be striving for. In a way, I feel like for in-memory data, functional programming and pure-functional data structures should help here: if your data is immutable, then you can work directly on the live data as long as you don't commit the changes back to the data store and have some kind of separation so that real users don't see your modified data. I think for databases a tiered approach "should" work - your test code hits the test db, if the item doesn't exist or is out of date, it hits the real db, which is read only to the test code. I do some web development contract work for a recruitment site sometimes and the development server basically uses real data copied from the real database periodically (after anonymizing and other things to make sure test emails don't get sent out, etc). The test code then works on otherwise real data. Not quite what you're saying, but part way there. [quote name='Antheus' timestamp='1334526977' post='4931553'] Stuff that was modelled upfront worked OK since it took limitations into consideration. But as requirements changed, they couldn't cope. [/quote] People his this problem all the time, regardless of languages and tools used, visual or textual doesn't matter. The various design principles help, but overall there is no substitute for experience. [quote name='Antheus' timestamp='1334526977' post='4931553'] Can they? [/quote] In my experience, yes. For example, in Max/MSP, I can abstract and modularise code just like I can in Java or C++. I think it could be easier and I feel the reason that it isn't is that most of these visual languages are designed as domain specific sytems, so they often ignore general purpose programming aids which help modularity, extensiblity and reuse. Either that, or they are (or were?) not designed with textual language programming principles in mind. In any case, Max/MSP and Synthmaker got me part of the way there and I can see a clear path to improving the situation in both those languages. Even without these "improvements", you can write good code, its just that the improvements would make it easier to do. [quote name='Antheus' timestamp='1334526977' post='4931553'] Could those fixes be made in visual language? If not, why isn't the platform itself written in these? [/quote] Do you mean could the fixes be implemented in visual languages themselves? If yes, then the answer to both question is that its a bootstrapping problem: current visual languages are largely domain specific languages and lack all the general purpose features that I feel they need. In the case of Max/MSP, there is a lack of rich type system - you have ints, floats, symbols and lists of these. You cannot nest lists, lists of symbols emulate strings. Max/MSP is optimised for audio and video, but everything else is kinda inefficient. Clearly Max is not a good fit to implement itself. But you could certainly design a language thats very like Max but supports, say, C's data types (C's primitives, structs, pointers/references for recursive structs) and a set of components to act on these and then I think you could rewrite the whole thing in itself. Or parts of it. If I were to build such a language, I'd use a haskell-like type system with algebraic data types and type classes. I'd have components for dispatch and pattern matching and I'd support functions (which could be simple expressions, or visual dataflow networks in themselves) as values which can be passed to higher-order components that act on sequences (where a sequence is a type class of which lists, vectors, maps, file systems, regexes, etc etc are members). I believe such a language would have similar pros and cons as a similar textual language - only thing changed is syntax (and possibly dataflow vs control flow considerations, just because dataflow is more obvious in visual syntax and control flow is more obvious in textual syntax). [quote name='Antheus' timestamp='1334526977' post='4931553'] Today's languages work with that, quite effectively. [/quote] I don't think they work with it as effectively as we would like. Codebases stagnate and become unmaintainable (the web contract work I mentioned is a testament for that - after passing through a few people before getting to me, the code is in serious need of refactoring, but the client does not want to pay for refactoring because.. it works). I don't think this has anything to do with textual or visual syntax and I think visual languages can "solve" this just as much as textual languages. I also think that placing data flow at the forefront rather than control flow, and a functional style that isolates side-effects makes a huge difference here. I can see this when working on PrescienceAI code in Clojure and I feel that visual languages can do the same. If they actually do or not, however, depends on the language designer/implementor. [quote name='Antheus' timestamp='1334526977' post='4931553'] But also depends on the domain. Music production has traditionally been a good fit for alternative models. Much of more mundane work isn't. [/quote] I would say Max and Synthmaker are signal processing DSL's. Flowstone is basically identical to Synthmaker as a language, but contains built in components for interacting with embedded systems for robotics - which is also signal processing really. I think a reason that music has been a good fit for alternative models is because the users weren't (and still mostly aren't) programmers so traditional programming tools weren't going to hack it. This meant they were open to new ideas. Also, audio, and signal processing in general, is ideally suited to dataflow/stream programming since thats exactly whats going on and visual languages are very suited to this too because they can visually represent the "circuits" along which the signals are routed. This made it an obvious fit - but I think that general purpose programming, especially in a multicore world (because dataflow is similar to functional programing and both are better at multicore than imperative programming with mutable shared state), can also benefit from visual programming. But again, let me say that I don't think we will ever (or should ever) replace textual languages - instead we should augment them with visual languages so that we can choose whichever suits ous needs best. [quote name='Antheus' timestamp='1334528500' post='4931560'] Majority of important code is written in arcane rule engines, Visio diagrams, proprietary config/declarative languages. It's just not advertised as code or programming, it's stuff people do to get the job done. Software Engineering doesn't apply here. Yet these are the people who can benefit most from programming. [/quote] Exactly and as visual programming is more approachable to non-programmers than textaul programming (the proof lies in how many non-programmers use the languages I listed before and stuff like spreadsheets), isn't this something that should be used by these people? Lower barrier to entry means more productive work done.
  13. Antheus, regarding REPLs, I'm not sure what your point is exactly because lots of Common Lisp, Scheme, Smalltalk, Clojure, Ruby and Python programmers successfully use REPLs to program, test their code and experiment every day. I know of one or two big-data companies that do a lot of work in the REPL during development (including my game analytics startup, PrescienceAI, which uses a lot of Clojure on the backend and as most Clojure programmers will tell you, the REPL is an integral part of every day development). I'm sure some people (certainly some of the Common Lisp and Smalltalk folks) program the live production system in a REPL, but I think most people code against a development system, like when running integration tests or unit tests you don't run against the production data. You wouldn't run your test suite against a production database, so why would you develop in a REPL that touches it? [quote name='Antheus' timestamp='1334515644' post='4931506'] VisualAge. The moment we finally killed off that code branch the entire company held a party. Our progress improved tenfold.[/quote] One (or two or three) failed experiments (or products/languages/tools as the case may be) doesn't mean the whole paradigm is flawed. For every successful textual language in use today, there are dozens of unused "failed" ones too. I'm not familiar with VisualAge so I can't comment on its merits or flaws, but I can say that for the visual languages I have used (Max and Synthmaker being the two I've used most extensively), while there are problems and flaws, non of these are inherent of visual languages and all can, in my opinion, be fixed. [quote name='Antheus' timestamp='1334515644' post='4931506'] Visual programming looks great on paper. But it doesn't scale. It's somewhat related to human mind as well. There is 7 billion of us, but a person only has a social circle of ~150 people. It's not impossible to have more, it just doesn't quite work out. [/quote] Can you explain what you mean? And define what you mean by "scale" - I assume you mean either scale to large programs or scale to large teams. In either case, I'd argue that textual languages don's scale particularly well either. We make them scale through code standards, through standardised interfaces/APIs, through compartmentalisation, encapsulation and abstraction. We make them scale through modularisation. We make them scale through version control, diffs, refactoring often, unit testing and automated documentation generation. All of these things can be done equally well with visual languages. As a small example, last month I worked on a max4live project. If you're not familiar with max4live, its an interface for Ableton Live that lets you run Max code inside Live (with a special API for integrating deeply with Live). So basically its Max/MSP, a visual programming language. Now, while I admit that the UI code was pretty painful to do (I could have done it using the Javascript component if I'd wanted to defer that to a textual language instead - I do find textual languages more suited to certain tasks whish is why my ideal environment would allow you to mix both textual and visual, as stated in my other post - right tool for the job and all that), I found the reason wasn't because of an inherent flaw in visual languages, but rather because of flaws in Max specifically - flaws which could be fixed (like providing a richer set of data types). I spent some time looking at a lot of other peoples Max code and a lot of it would make me agree that it doesn't scale. Some large (relative to the average size of a Max program, not relative to software in general) programs were a giant mess of lines and are extremely dificult to follow - no wonder one would think that it won't scale, either to larger programs or larger teams - it quite literally was spaghetti code. But then I wrote my own largish piece of code and I wrapped each self contained bit of functionality into its own component by following basic OOP principles (Single Responsibility Principle, Separation of Concerns, Open Closed Principle and Dependency Inversion Principle) and I actually find Max to be a pretty good fit for OOP. This made me realize that the reason that a lot of Max code found "in the wild" seems so anti-scalable is that most of it is probably written by musicians and artists rather than programmers with formal training into good software engineering practices and OOP principles. This doesn't make visual languages flawed or bad - bad code can (and is) written in any language, especially if it lowers the barrier to entry as more people who are not aware of best practices and ancient software engineering concepts will write code in them. I do, however, think that visual languages can be made in a way that is "more scalable", though in the end, as with textual programming languages, it depends on how strictly the individual programmers adhere to standards, practices and patterns. One final note - I do a lot of my brainstorming and pseudocode on paper in what is basically a visual programming language very similar to Max. When the concepts and designs solidify, I type it out in a textual language. While I was developing in Max, I found I could skip the "think on paper" step and think in the Max editor instead. Instant feedback of the live programming environment helped of course (and I done each step in isolation to the rest of the system, so no side-effects/touching real data). I feel that a visual language and environment could be developed that basically lets me brainstorm, experiment and design with executable visual code. The term executable pseudocode is sometimes thrown around and for me, that is what this would be. I'm not saying visual programming is some kind of silver bullet or even that its for everyone, but I do feel it is something that could improve certain areas of programming for a lot of people and is worth exploring more - as the list of successful languages in my other post show, they already have improved programming in certain niche areas. [quote name='way2lazy2care' timestamp='1334523196' post='4931530'] Something more like Unreal's kismet is what I had in mind. [/quote] We're on the same page - this is exactly the kind of thing I'm talking about (and another item for my SO list).
  14. Contraforge, from your posts it seems that while you may have plenty of experience in C++, Java, C# etc, you have very little experience in the wider spectrum of programming languages. Your comment about not having used closures, for example, makes it seem to me that you have not used a functional programming language before. Before you start designing your language, I would highly highly recommend that you spend some time learning some more programming languages in different programming paradigms. I'd suggest a Lisp variant (Common Lisp, Scheme, Clojure), a hardcore functional language (Haskell, ML, Erlang - Scala and OCaml too, but be careful not to overuse the OO and imperative parts since the goal here is to learn about functional programming and type systems), a logic programming language (Prolog or mercury), a concatenative language (Factor, Forth or Joy) and a language designed for concurrent programming (Clojure, Erlang, Cilk). If you want a quick, easy and fun way to get exposed to a large variety of programming languages and paradigms, I would highly recommend the book [url="http://pragprog.com/book/btlang/seven-languages-in-seven-weeks"]Seven Languages in Seven Weeks[/url]. Its very accessible, easy to read and quite a lot of fun (imho) to work through and will quickly teach you enough to be effective in Ruby, Scala, Erlang, Prolog, Clojure, Io and Haskell. After you have read that book (or exlored a number of [i]vastly different[/i] languages by yourself), I guarantee you will have a whole new perspective on language design when you come back to working on your language, you will have much clearer ideas on what makes a language good or useful and you will be a better programmer to boot.
  15. [quote name='ApochPiQ' timestamp='1334276342' post='4930756'] Visual languages have been tried before. [b]There has never been any appreciable success.[/b] [/quote] I disagree - there are many visual languages and quite a number of them are very successful in their niche areas. Check [url="http://stackoverflow.com/questions/461796/dataflow-programming-languages/949771#949771"]this stackoverflow answer[/url] for an incomplete list of visual dataflow languages (and that doesn't include non-dataflow visual languages). For example:[list] [*]LabVIEW is a pretty successful and popular visual language used by scientists for data aquisition and simulation [*]Max/MSP (and the Ableton Live plugin version max4live) is an extremely popular visual language for multimedia and used by many (non programmer) musicians [*]Puredata (aka Pd) is an open source version of Max/MSP and is reasonalby popular [*]Synthmaker is a visual dataflow language used to create audio synthesizers and effects and can be used to create VST plugins. Flowstone is a version of Synthmaker which has been updated for use in robotics. [*]SCADE is a visual programming environment for the Lustre programming language and is used for critical systems like power plants, transportation and aerospace - I heard somewhere (maybe their website?) that the Eurocopter was programmed using SCADE. [*]Many media applications use visual dataflow programming tools as embedded languages and they seem to be reasonably successful for non-programmers to use (usually artists or musicians) - eg, Blender includes one for shading and I've seen some game engine toolsets come packaged with some too and iirc the Fmod tool also includes a visual programming tool for effects programming. [/list] I think they most certainly have had [b]appreciable success[/b], just not by mainstream programmers, though I believe that could change. For example, I have been using a Max/MSP a little bit and have found that it is severely lacking (one simple example is that you can't nest lists). The flaws can be fixed though. My ideal programming language would either have both a visual and textual representation that you can convert between at will (Faust does this) or at least be split into both visual and textual forms. I find mathematical expressions and classic algorithms, as well as a lot of data structures are easier to represent textually, but any data routing/flow code (which in my experience is about 80% of business code) is much more natural and intuitive than textual code. Finally, the visual languages I have spent a reasonable amount of time with (mainly Max and Synthmaker) have programming environments that rival Smalltalk and Common Lisp when it comes to interactive "live" coding and definitely beats most REPLs I've used (Python, Ruby, Clojure...). Personally, I would love to see more experimentation with visual languages as I feel that there is a lot more to be done in this area, even if the concepts are ported back to textual languages or only used in IDE's rather than the languages themselves, that would still be, IMHO, a success.