Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 26 Feb 2007
Offline Last Active Today, 05:49 AM

#5199236 Thoughts on Rust?

Posted by Ravyne on Today, 05:40 AM

Frankly it doesn't sound much different then C++ making RTTI optional.

C++ needs its runtime for a lot more than RTTI. My understanding of C++ is that its so limited without its runtime as to be nearly useless. Rust seems to retain much of its character still, and certainly has enough expressivity to bootstrap its full self.

Rust is a classic example of what happens when you try to anticipate everything that could ever go wrong, and then build a language feature that tries to make that less dangerous."There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies." - CAR Hoare.

How recently have you looked at it? I certainly respect your opinions on programming languages, but I'm curious as they've really cleaned up a lot of the cumbersome syntactic patters that had appeared. The language has become markedly clearer in the past 6 months or so.

#5199196 Thoughts on Rust?

Posted by Ravyne on Yesterday, 07:59 PM

I plan to add more to the discussion when I have a bit of time, but I personally don't lump Rust into the "academic" language camp, like I would, say, Haskell. Aside from the memory safety aspects, its not really a big-agenda language, as most academic languages are. They have an opinion of what is useful and pure, but they seem to be moving along with an eye towards pragmatism. People are doing interesting things in Rust now, and Mozilla is committing to using it in production, client-side code in a more significant way than even Google is with Go. My own guess is that Rust will prove out to be a useful branch on the evolutionary tree of programming languages.


For games, I think the immediate question is whether the extra memory safety will be in the way of things we are all used to doing in C and C++ as game programmers, and whether and how long we will develop abstractions or learn ways of segmenting that code off in Rust's unsafe blocks, while still letting us do the bulk of our work under and within the bounds of its the greater memory safety. If the industry or early adopters were to show that it is possible, then the wins are very tangible.


On the down side, they didn't leave garbage collection out entirely.


But neither is it in the core language -- its a standard library module. Rust can run on bare-metal with no runtime, all it needs is a stack.

#5199184 Is it possible to use Dart lang for Apach server?

Posted by Ravyne on Yesterday, 05:43 PM

You can run Dart itself on a server using Dart.io, what's the need for Apache exactly? If you're doing something relatively simple perhaps its sufficient for your needs to write your own webserver in Dart itself, for example serving static pages ought not be too difficult. Depending on what you're using from PHP, it might not be beyond possibility to provide that functionality yourself.

#5199159 Easiest coding language?

Posted by Ravyne on Yesterday, 02:49 PM

For me to leave the impression that its just a more elegant version of C++ is certainly selling it short. It does a lot differently than C++, different concepts and models for things, and a few tricks of its own. For example, one rather neat thing about it is that a defined subset of the language can execute on bare metal with no runtime support and you can compile against this subset, so its suitable for embedded systems but also higher-level than C -- I intend to do some bare-metal programming in Rust next year, either on the Raspberry Pi, Nintendo DS, or GBA, just for kicks. Anyway, when I said it was an safer and less cumbersome alternative to C++, I meant that its focussed on safety and is a more-coherent language than C++ is, but it serves mainly the same domain and you're programming at roughly the same level of abstraction with a procedural language -- but it is a very different language than C++, not a direct derivitive; its much further removed from C++ than, say, D, C#, or Java.


Anyways, I'll stop derailing the thread now :) If anyone wants to continue this thread of discussion, PM me, or start a new thread and PM me the link.

#5199139 Easiest coding language?

Posted by Ravyne on Yesterday, 01:07 PM

For practical real world use...?

No, not really, at least, not yet

But soon, if you're so inclined. The plan is that they will release version 1.0 of Rust in January, at which time the language will be 'stable' -- it will continue to grow and evolve, but things that are stable in 1.0 won't disappear or be radically changed thereafter like they might have been in the early days of the language.

IMO, Rust is interesting, and because its got the backing of Mozilla and because they're already writing their next-generation webkit competitor in it, its not going to be just another academic exercise.

That said, its aimed at the same domain as C++ and while there are many important differences between them they are not the kind of radical differences you would experience in a functional or dynamically-typed language, so it might not be that fruitful as an exercise in expanding your brain -- one would be most interested in Rust if they were looking for a safer and less cumbersome alternative to C or C++.

#5199051 Easiest coding language?

Posted by Ravyne on 18 December 2014 - 09:39 PM

I don't think anyone's recommending that OP starts with Lua and never moves on, or to try and create complete software in Lua alone.


Lua is a nice start because of the reasons Serapth mentions that make it a good language in which to learn programming concepts. When one is ready to move on to a more production-ready language, Lua skills remain valuable because its a popular scripting language in all kinds of software but in games especially. LuaBind makes it relatively easy to write your game's core low-level logic in C++ for things like performance and battery life, but to script high-level game behaviors in Lua for its ease of use and better productivity.


Lua is a perfectly reasonable start, as would be C#, or Java (as much as I dislike the language myself), or JavaScript -- all of which remain useful skills even if one changes gears. C and even C++ are not bad choices, provided you are willing to take things slowly and deal with a certain amount of non-trivial trivia.


The easiest language to learn is whatever is easiest now -- there is no requirement beyond that, not even that it is suitable itself for production work.


Anyways, every programmer learns and throws away knowledge of several programming languages over their career, but it does not mean that time was wasted because they were a necessary stepping stone or maybe just an interesting exercise. Of the first 4-5 languages I learned and used (4 BASIC variants, and C), I never use BASIC of any flavor these days and use vanilla C only rarely, on top of that I've learned and played with a dozen or more languages just to see what was interesting about them and stretch my brain a bit (Haskell, Scala, Lisp, SQL, D, etc.), and I've written code in a few flavors of assembly over the years (z80, 6502, ARMv4, x86) -- I use today maybe 10% of the languages I've non-trivially-used over all my years, namely C++ (and a little bit of vannilla C), C#, and JavaScript. Even now I've got my eye on Rust, eagerly awaiting its stable 1.0 release scheduled for January.

#5199009 Best code to use for a web browser game

Posted by Ravyne on 18 December 2014 - 03:45 PM

To run your game within the browser there really are only a few options -- All browsers run Javascript and this performs well enough for simple (and even relatively complex) games if you take care. On Chrome, there's a technology called Native Client (NaCl) which is a way to run native C++ code compiled with a special compiler inside a safe sandbox, the sandbox exposes things like OpenGL ES and some other platform features, but blocks certain things like file-system access. You then have the Unity web-Player which allows your unity games to be run in a variety of browsers (and of course you can publish a unity game directly to mobile or other platforms, and I believe it can also publish to NaCl).


For easily putting your code on any platforms you choose to target, and for relatively simple games that aren't doing anything far outside the box, Unity makes good sense.

#5198871 constructor for class that contains another class and constructor C++

Posted by Ravyne on 17 December 2014 - 07:21 PM

Just to reinforce what others have said -- this is not a good use of inheritance -- Sean and Wintertime lay out the case against it nicely. Its better to have independent vector classes of the common small dimensions 2, 3, and 4, and a general-purpose compile-time/run-time sized vector for larger/arbitrary dimension if you need it.


What you've probably done is misidentified the nature of their shared interfaces and conflated it with a desire for code-reuse. That is, influenced by wanting to reuse the code of vector3, you have assumed that vector4 simply extends it. In reality, vector3 and vector4 do inherit a common interface, but that does not imply that one should inherit from the other -- conceptually they both inherit from a common interface that you have not defined. For completeness, also note that while there is a common interface, it is only a subset of the operations that apply to all vectors (e.g. the cross product only exists for vectors of sizes 3 and 7 (e.g. not for 4, which you are deriving from 3), and there is a psuedo-cross-product in 2 dimensions that's not correct in a mathematical sense but is sometimes useful nonetheless).


Now, before you go off an try to implement this common interface I've spoken of, stop, because its not an idea that's good to take literally. Firstly because the necessary virtual inheritence would kill performance, and secondly because you simply don't use vectors of different dimensions interchangeably very often -- almost never. In such cases, you should either be using that general-purpose runtime-sized vector to begin with, or alternatively a function template can be used to leverage duck-typing, which is essentially a loose, anonymous interface of the type you need here. In cases where they are not used interchangably, but where it seems beneficial to allow a vector4 to act as a vector3 temporarily, its better to provide a conversion operator and/or a vector3 constructor that takes a vector4. Note that when going from a lower to a higher dimension vector you need to be explicit about what the missing coordinate (e.g. W) should be assigned to.

#5198863 How much do I pay someone for coming up with some ideas for my game?

Posted by Ravyne on 17 December 2014 - 06:38 PM

Your agreement complicates things, only a lawyer can advise you of your legal position, and no one can tell what the outcome of your friendship will be. That said, if it weren't but for the agreement, I would personally sleep perfectly well if I were in your position -- people sit around and spitball ideas all the time, a telltale sign of this is when the ideas are discussed in terms not much deeper than "do X like Y game, but also with W from Z book." I mean, people mention vague premises they want to explore, or very generalized game mechanics all the time -- and since those are not "designs" its well and truly bullshit for them to come back and accuse anyone of stealing their design when someone else has gone off on their own and put their own spin to it.


Now, if they guy provides value in some capacity -- design, business, etc. -- and you want him onboard for the future, just tell him that there's a place for him in a future company or whatever, but that the 50-50 notion just doesn't seem fair given the disparity of what you've put in -- keep in mind, however, that the first step is to fairly acknowlege the value he's provided not just for this game in specific, but in all things under your agreement that has brought you to where you are now, because your upcoming project didn't simply spring forth from its ideation, but also from all of your collaborative works before. Likewise, weigh the actual likely financial gain this might lead you to going 50-50 on $100 million is a very different story than going 50-50 on $1000, and even if it may not be 'fair' it might not be worth taking the lion's share of the latter if it means damaging a friendship.


Finally evaluate what he has done and what role he will continue to play going forward, if any. 50-50 doesn't seem like a fair split for what he seems to do for you. Likewise, you'll want to keep some money in the business if you're serious, and that should be figured in before either of you take a penny for yourselves. This is a valuable lesson in thinking through your agreements before letting them take root.

#5198702 Mobile Arcade

Posted by Ravyne on 16 December 2014 - 10:57 PM

Dude, what the hell? You go and downvote all 3 of my posts, and apparently everyone else's, because you don't actually want to listen to any of the advice you asked for?

I'm taking a mental note not to offer you any more help, and if this is what you do I'd encourage others to do the same. Don't let the door hit you on the way out.

#5198672 Mobile Arcade

Posted by Ravyne on 16 December 2014 - 07:04 PM

I'm not familiar with the terms of google play, but IIRC on iOS you're contractually bound to process all payments through the appstore, except for specific kinds of content (e.g. Subscription publications like magazines) and even those kinds of content that are allowed to do so, they can't, last time I heard, offer a way of using the alternate payment system or even advertise that it exists within the app, and furthermore that they are bound to provide an in-app purchase button that goes through the app store and must carry the same price as the alternative method.

You probably want to check whether similar clauses apply to google play apps.

#5198410 Mobile Arcade

Posted by Ravyne on 15 December 2014 - 02:56 PM

Another option would be to use the Patreon platform to manage subscriptions (which would allow you to do auto-pay too) -- its not known for being used as such, but it is effectively a platform for digital subscriptions. If the Patreon image is not suitable for your needs, it's based on Overdrive which you could integrate directly with your own site.

#5198406 Mobile Arcade

Posted by Ravyne on 15 December 2014 - 02:48 PM

Yes, your identification scheme won't work, IPs change and can easily be spoofed. MAC addresses too. You're talking about Identity/authentication -- that's what logins are for. I suggest you simply integrate with social networking sites (to lower friction for those who use them) to provide identity, and have your own login service for those who don't. Alternatively, you could put some kind of user-specific certificate that expires monthly behind a paywall (you'll still need to provide a way for a user to get it again if it gets lost, and if you want to automate that process you'll need a login system anyhow), and use it as a token necessary to access your site's content or access its services.

#5197495 How2Ensure UDP-Packets reach target (high performance)?

Posted by Ravyne on 10 December 2014 - 08:37 PM

Also, your scheme fails because what if an ack packet is lost? Do you also keep sent Ack packets in the AwaitingAck queue, themselves waiting for an Ack-Ack? And what then of them, an Ack-Ack-Ack scheme? Hopefully you can see where this is going -- its unreliable all the way down.

Keep sending the message blindly until you get a ack that's equal or greater than the message. I'm not aware of any way to do the kind of ping-pong ack packet-for-packet the way you describe.

Also, some messages are latency-tolerant and can't really be acted upon until you have the complete message in order, when you hear latency-tolerant and in-order, think TCP. User chat messages are a good example of this, and a candidate for sticking into a TCP stream, which frees up your UDP stream for un-ordered but latency-sensitive data.

#5197086 Freemium and Whaling

Posted by Ravyne on 08 December 2014 - 09:36 PM

Most of the thinking today around freemium monetization is such that whales and "chum" (as I like to call Freemium freeloaders who won't participate in the ecosystem) are a sort of natural consequence of the way in which the developer tunes their games. In short, developers tend to take the simplistic view that their sole goal is to increase revenue without consideration pf what share of that revenue comes from a certain amount of people. To their models, earning more revenue means the average player is more happy, even if all increases in revenue were due to whales. Its not a very realistic picture of the health of the game, and I find it pretty cynical, but its what they do. These games don't have a flatter revenue spread because they don't consider optimizing for it.


Given the dearth of "free" entertainment available today, you will always have people who are unwilling to buy into the entertainment they consume -- they'll grind forever if it doesn't cost them anything, or they'll just move on to the next thing. You'll never generate any revenue from them except from advertising. However, because of the need for a large, immediate user-base to penetrate the top-apps list where you need to be to make real money, they are necessary to the success of your app. The typical freemium titles use them to gain placement, which in turn draws whales to the game -- that's why I call them "chum".


Likewise, you'll always have whales who will buy every transaction available, either because they really enjoy the game or because of their own compulsions. The trade-off of relying on whales is that most games encourage whales by making high-end items exclusive, scarce, and/or powerful so that they can charge a high premium to an exclusive clutch of players. This has obvious effects on game balance, and also impacts who the developer will prefer to keep happy as the game changes and evolves -- a move that would alienate whales will never be considered, even if it would make the average player happier at a rate of 100-1.


I don't think eliminating the whales or the chum is the point, but I do think that a healthy game would have a strong "middle-class" of players who have spent something and that you'd see a gentle slope from people who have spent the least to those who have spent more, but are not whales. I also think that you'd make the most revenue by establishing such a middle-class of gamers and then focusing on raising the average revenue generated from them, its just that most games haven't figured that out. League of Legends is one that approaches that, so is TF2 -- both games do so by deliberately choosing to do so -- for example, in Leage of Legends, you can't really buy your way to victory because consumable buffs tend to affect the entire match rather than a specific player, which increases the enjoyment for everyone and encourages all players to participate in that economy. TF2 achieves it by making their entire economy of in-game stuff tradable, and through their crate-system which randomizes loot such that its not only the whales who have the best stuff. This is counter to a whale-based economy where exclusivity and scarcity drive revenues.