Jump to content

  • Log In with Google      Sign In   
  • Create Account

Ravyne

Member Since 26 Feb 2007
Online Last Active Today, 09:32 PM

#5187551 DLL-Based Plugins

Posted by Ravyne on 16 October 2014 - 07:56 PM


I put the try-catch block there in case there is an exception because I don't want the Editor to crash if the Game DLL causes an exception. Would this be considered as exception handling across binaries?

 

It would. If you were to stick to native plugins and DLL architecture, one approach is to marshall exceptions across the DLL boundary. A simplistic way of doing this is to surround your plugins in a catch(...) so that no exception leaks from the DLL (you can also catch and handle specific exceptions in the same place) -- then, just have your DLL function log the exception data as a dump, and pass back an integer value that indicates the type of the exception. Your client can look up the error code and present the user with a basic description of the exception, and point them to the log for more information -- if necessary, certain error codes might mean for your client to throw the indicated exception itself, as a means of propagating the error to where it can be handled correctly.




#5187546 DLL-Based Plugins

Posted by Ravyne on 16 October 2014 - 07:45 PM

I think, though, what everyone is trying to warn you off of, is that native DLLs aren't straightforward. Its not easy like implementing an interface -- its like that, except that the interface *also* consists of a dozen or three sort-of-hidden settings and dials that all have to be exactly in sync -- the right calling conventions, the same ABI, the same behavior settings for floating-point code (potentially), the same data packing on shared structures (or a mutually agreed upon serialization). A dozen compiler settings you probably never think to touch suddenly become critically important. In general, I'd stick my neck out as far as saying that native-code DLL plugins are largely out of favor -- people will put up with it where performance is a necessity, but it seems like too much trouble when its not.

 

[EDIT] I realize now that the post above was probably in response to nypyren, and that you weren't justifying sticking to native DLLS in the face of my previous post. I'll leave this here for posterity, but apologize that the tone might be a bit harsh in retrospect.




#5187540 What a web I Weave !

Posted by Ravyne on 16 October 2014 - 07:22 PM


Tabs = bad. There is no justification for them (IMMHO).

 

Tabs to indent, spaces to align. Tabstops of 8 are hideous though, 4 is plenty in curly-brace languages, and you can get away with just 2 if you're not a braces-on-their-own-line programmer.

 

3 is heresy, of course, because all programmers know that powers-of-two are faster tongue.png




#5187539 DLL-Based Plugins

Posted by Ravyne on 16 October 2014 - 07:17 PM

As others' are pointing out these difficulties, it might well be the better long-term solution to have such 'plugins' in the form of scripts. You could package such plugins -- resources, code, configuration, manifest -- inside a .zip file to keep it all together. That's basically what Visual Studio's .vsix extensions are, except they use .net dlls for code.

 

Scripting should be fine for UI extensions performance-wise, but it does introduce a dependency that you wouldn't have otherwise. Lua would probably make a good choice.




#5187516 How do you ace the interview?

Posted by Ravyne on 16 October 2014 - 05:12 PM

I don't know if you can expect to find unity-specific examples of interview questions anywhere. In general, the team will probably put you through a few design or thought exercises, have a technical discussion with you, and probably have you do some whiteboard coding or code critiquing. Advice for all of this, as per general, is relatively well known -- listen, repeat, clarify before attacking a solution, think out loud, and do not hesitate to change directions on your solution if it seems you've got stuck -- I've failed one interview by looking for a log-N solution that I was sure existed (and it did) but was more complex than I imagined, and because of complexity was actually no faster than the linear solution that was obvious. If you think you need to backtrack, its actually an excellent time to bounce ideas off your interviewer -- "I went this way because X, but now I see Y. That makes X hard, but maybe Z is a better solution. What do you think?" They're not going to give you the solution, or probably even tell you whether they'd choose X or Z, but they will almost certainly help you puzzle things out some more, and its not the kind of thing they'll dock you for if you are going about it intelligently. They aren't looking for people who know the solution to every problem cold, they're looking for people who can find solutions to problems they maybe haven't seen before.

 

Practice questions -- even or perhaps especially the non-technical ones. The goal isn't to come up with a script, but ask yourself the questions and write down the answers. The goal is to simply bring relevant information from your experiences to the top of your mind. You don't want to wake up the next morning regretting that, under pressure, you failed to recall that really great story you have about solving a similar problem.

 

And as per usual, I will recommend you to buy and read "Programming Interviews Exposed" -- its in its second edition last I looked, and the best $30 a programmer can spend. It covers everything from resume tips, to typical soft and hard questions, to thought exercises, to how to dress, to how to negotiate a salary. Buy it now.




#5187479 Lack of Production From Team Members

Posted by Ravyne on 16 October 2014 - 02:40 PM


You are the lead coder, but not a leader... Often motivated, skilled people tend to fall into the 'I'm the only one who is skilled enough to safe our butt right now'...
This has a very high potential of destroying the team motivation!...If you want to motivate your team, you need to learn to hold back, to delegate challenges to other member, to accept, that others need to learn by failure, to support them, that a good team performes much better than a single, skilled individual.

 

QFE, don't discount this advice. In younger days I have been the perpetrator and the victim of this working style, and neither time was I very satisfied with the result. You cannot expect morale to remain high for the whole team when a minority of the team took ownership of the project early on. It is not their fault as much as it is not yours and as much your fault as it is theirs -- but nevertheless, there is now a situation where only you and the front-end person (people?) are invested in the project, and there seems to be no challenges left in the project for these others to find value in. They're probably thinking "At this point, I can coast through with a C by only doing enough to not get kicked out, or I can work my butt off doing the boring remnants and maybe get a B." I suspect you would not be motivated by that either.

 

Your problem is not productivity, its morale. Attacking it as a productivity issue will not solve the problem. Being older and wiser now, I would approach my past situations like this -- set aside any feeling of superiority or indignation, acknowledge that there is a morale issue stemming from a lack of ownership by all team members, cede some of your remaining *interesting* feature work to them or find new features for them to own, split documentation and other "boring / busywork" tasks across the team.

 

Remember that in this setting there is no hope of promotion, which is usually what enables people to endure more menial tasks in their professional career -- here, to keep the team happy and productive, members have to share in both the interesting and menial work. 




#5187001 Golden era of the RPG

Posted by Ravyne on 14 October 2014 - 01:28 PM


What? No. Not at all. What you get is to do what before you just pretended to be doing. That's a pure win for me.
 
Complexity isn't always a good thing. And dice roll mechanics, albeit complex if you want to make them complex, are as shallow as there can be.

 

I'll stick my neck out and disagree -- for me, there's almost nothing more insufferable in modern games than the lock-picking mini-game. I find it tedious, and unfulfilling. I'd much rather have some kind of lock-picking stat and just be done with it. And why are we picking a lock that looks like Its barely holding together through some miracle chemistry of rust and cockroach feces, anyhow? In real life you'd be loath to touch the thing for fear of tetanus or worse, and just smash the thing apart with the but of your rifle. But I'm probably biased, honestly I don't really like CRPGs to begin with; the massive number of stats, piles of loot, and the like just seem like too much tedium to me. jRPGs are more my speed.




#5186092 anyone have experience of selling Android game?

Posted by Ravyne on 09 October 2014 - 06:45 PM


now that's something interesting :-D
sure to be a great starting method if I have some bucks to spend

 

I wouldn't recommend you follow their lead. I mean, they write the expense off as marketting, but the practice isn't endorsed by the marketplaces, can get your app penalized or banned, and what's more, doesn't guarantee success.

 


I don't think it was easier.
Back then, getting the equipment to develop was much harder. We didn't have the internet to learn how to make games, so we needed books etc.
I recommend listening to some of John Carmack's words on the days of Wolfenstein 3D actually for this. You'll notice that those that ended up developing games back then were taking huge risks (such as a lawsuit that would take over a decade to settle!).
 
It is easier to make games now, which means there are more games, but it doesn't go to say there wasn't any volume of luck back then, or that great titles didn't make it. It was a challenge then, and it is a challenge now!

 

An interesting dynamic is that the barriers to entry -- equipment, know-how, reach -- have been pushed down so far, especially where people begin. All you need is a PC, which you probably already have, a mobile device which you might already have, and $100 to get your app on the store. Knowlege is freely available if you have the time and ability to grok it. The rest is your own creativity and gumption.

 

The result is that almost no one fails before they hit the market, and combined with the apps gold-rush, one could only expect to see the kind of over-saturation and market dynamics that exist today. There's no natural forces keeping those doomed to fail out at an earlier stage (to be clear, I'm not advocating that the previous Plutarchy was "better" but it definitely was different, and those that actually made it to market had a better shot at meaningful success). This leads to rather few people making money at what's become a very large but rather dysfunctional market.




#5185677 If you ever used a vector in c++ could you show...

Posted by Ravyne on 07 October 2014 - 09:02 PM

Figuring out what tiles are where is highly unlikely to be your bottleneck in any event.

 

That said, to be maximally efficient, I would create a vector, or possibly a std::array, with dimensions Width, Height, Depth, where Depth is the 3 layers you describe. I would walk all of (the visible portion of) layer 1 in row-order, then the same for layer 2, and for layer 3. With proper declaration of the vector or array, that will be as efficient as possible.

 

The declaration would look like this for std::array:

std::array<std::array<std::array<TILE_STRUCT, Width>, Height>, Depth> tiles;

 

Or for vector:

std::vector<std::vector<std::vector<TILE_STRUCT>>> tiles; // then populate the vectors appropriately, using reserve() to pre-allocate memory.

 

 

That's for a somewhat niave "I'm just going to carve out a square of this to draw" approach. If I were really needing efficiency (say, with significantly more than 3 layers, or a variable number of layers) I would then organize the data into a 2D grid of map sections a few tiles on a side (probably between 4x4 and 16x16) where the idea would be that I would only ever load the sections I had to draw. The section itself would be a linked-list to another 2D section containing the next layer up, and you could add as many layers as you needed.

 

Then, when rendering I would find all the sections that are in view, including their layers, then walk all of that per-layer building up a draw list, adding an appropriate Z-depth based on the layer. Build the list from the upper-most-layers to the base to take advantage of early-z rejection on the GPU.

 

The declarations would look something like this:

 

typedef std::array<std::array<TILE_STRUCT, 4>, 4> tiles_section; // create a type of a section of tiles that's 4x4;

 

std::array<std::array<std::forward_list<tiles_section>>> map_base_sections; // I'm going to hand-wave here, you can use things other than forward_list, and you need to figure out where you want to store your upper sections, and also how you'll manage lifetimes (e.g. with unique_ptr or scoping, etc).

 

 

But that's if you really need the speed -- almost certainly the 'naive' way is sufficient for most uses.




#5185665 If you ever used a vector in c++ could you show...

Posted by Ravyne on 07 October 2014 - 07:51 PM


I guess this explains why performance might take a hit using vectors. Hopefully my game won't suffer accessing a list of a few hundred at a time.

 

xeyedmary's post might have been a bit misleading -- for sequential reads, vector has the same performance characteristic as an plain old, C-style array. Random reads pay a single extra indirection which is going to be swallowed up and hidden by any modern CPU. The only performance issue that you can get into with a vector is when you grow it by adding extra items to it. Even then its the same cost you would pay to grow an array (except that native arrays don't support growing themselves, you have to relocate and copy, which is what vector knows to do), but vector, when it grows, grows extra so that it doesn't have to reallocate and copy every time. What's more, whenever you know how much room you're going to use, you can ask vector to reserve that amount of memory ahead of time, so that it never has to reallocate and copy while you are adding items. Long story short, vector is no slower than a plain-old-C array unless you're doing something evil, stupid, or ignorant, and since it does all that *and* allows you to grow it *and* handles all the dynamic memory management for you, there's no reason* not to use it.

 

* If you know the exact size you need, and you don't need to grow it ever, prefer std::array (which is an even thinner wrapper over an array than vector is, and like an array it can't grow). For simple storage and lists, prefer std::array and std::vector by default, unless A) you need to insert items at the front or in the middle (then look to std::list, std:deque) or B) you have a different kind of problem altogether, like something suitable to std::queue, std::map or std::set in all their variations. See http://www.cplusplus.com/reference/stl/ for the list of containers you can use.




#5185343 anyone have experience of selling Android game?

Posted by Ravyne on 06 October 2014 - 12:50 PM


The bar nowadays is ultra high. You need to be a truly innovating Quantum Physicist who knows how to create a 1nm transistor to still matter.

I don't think that's necessarily true. I was at a startup conference a few weeks ago, and it was interesting, despite my being a fish entirely out of water there. The crowd-favorite was a startup called Shipster -- basically, think of it as Orbitz or Travelocity, except for shipping cargo internationally (specifically, shipping containers across the sea). Just like Orbitz puts together a package including your flight, hotel, rental car, insurance in one self-service package, Shipster does for your cargo -- over-land shipping to and from the port, customs, shipping, documents, etc. all in one self-serve package. They likened it to when, just 20 years ago when you wanted to take a trip you went through an expensive travel agent, in shipping, the norm today is to go through sometimes shady shipping brokers who charge high margins and disappear when there's a problem.

 

The thing that struck me about it most was that, having solved the problem 20 years ago for people, basically no one had thought to do the same for shipping cargo in all that time. And its a good idea, shipping is a billions-of-dollars industry, and yet it was a hidden opportunity for two decades.




#5184838 Is upper division Linear Algebra a good idea or necessary?

Posted by Ravyne on 03 October 2014 - 03:10 PM

They're all useful. Number theory tends to be a little more essoteric, but is useful for understanding things like the minimum number of bits needed to store (complex) information, or, in understanding how much accuracy you can rely on maintaining through a series of floating-point operations (and strategies to maximize accuracy by ordering operations differently).

 

Linear algebra will have the most direct application to geometry transformations used in rendering and physics. Diff Eq. and Calculus will be more in the realm of physics, statistics, with applications also in AI and graphics.

 

The more math the better though. Plan to learn all 4 if you can, and take now what will serve you best and most immediately, or in better shape to pursue the others later. If you're in college there's no rule against taking more classes than you need, it'll only cost you money and time -- be careful about keeping minimum grades up though, if you intend to take a heavier course-load than usual.




#5184832 anyone have experience of selling Android game?

Posted by Ravyne on 03 October 2014 - 02:53 PM

Basically all of the open mobile platforms are economies with a very long tail -- In other words, a relative handful of the most popular apps make "real money" and revenues fall off exponentially from there. Without having actual figures to back it up, my impression based on experiences and studies I've read are that 98% of developers are making "pizza money" at best -- $100 US a month, or less. There are millions of developers and millions of apps -- hundreds or thousands of new apps each day.

 

Even good, high-quality games fail to find a market every day in these economies, for whatever reason. They maybe lack marketting, or launch against other software that grabbed all the mindshare the morning they launched. Less scrupulous publishers hire shadowy firms to inflate their initial download numbers so that they can raise into the public's conciousness, in hopes of cracking the top-10 list where the real money is.

 

 

All that is not to say that success is impossible, but it certainly is improbable. There are still success stories, but the biggest among them tend to be games that have 'gone viral' like flappy birds -- the polish and appeal of such games play a part in starting the viral reaction, but its not really something you can design to influence. Flappy Birds could have ended up making no money at all, had the winds simply been blowing a different direction that day. Frankly, I would *plan* on not making any money to start, and take your first games as a learning experience. You might get lucky, but more likely you'll establish a small but growing fanbase who will have an increasingly large back-catalog of your games to buy and recommend to their friends. Over time this can grow into a sustainable business, but under almost no circumstances today are sustainable businesses springing forth from a single game launch.

 

Also, a 'box price' (where you buy the game up-front for a set price) is a complete non-starter on mobile in general and on android specifically. The ease with which (cracked) games can be side-loaded on android means there's a vibrant android warez community who simply never pay for the software they use, and even among the more honest android users, the ecosystem provides 10s or hundreds of free alternatives in nearly any category, no matter how niche. Instant, meaningful success on these platforms has almost nothing to do with the quality of your product -- although a quality product is a minimum barrier to entry -- and everything to do with factors you can't control, like getting some good organic publicity or serendipitously stumbling onto a top-10 list on the back of viral forces.

 

The easiest way (most easily grafted into any kind of game with minimum effort) is to build your game to support adds and have it be completely free, then, as an in-app-purchase, offer an item that disables adds and sell it for $1. Crackers will even remove the adds, probably, but usually people will just take the official free version with adds rather than risk whatever other malware a cracked copy might contain. So, you'll get a trickle of revenue from anyone who plays your game, and you'll have the opportunity to make sales to those who like your game enough to want to skip the interruptions. Another idea is to simply give away the first few levels or hours of content entirely free with no adds, and then sell the remaining content via in-app purchases -- that's essentially how iD software established their business back in the day with Wolfenstien3D and Doom using the then-common shareware business model; of course, the shareware markets of the day were much less crowded, your only competition were the other floppy-disks sharing the wall at your local radio shack or mom-and-pop computer store.




#5184447 Can I design & develop a game with a sub $500k budget?

Posted by Ravyne on 01 October 2014 - 06:30 PM

The first question is where and how you plan to get your $500k budget, and the first-first question (because really you should have an idea before spending $500k) is how do you plan to make it back, and then some?

 

 

A seasoned programmer probably expects in the neighborhood of $100k/year salary, give or take $20k, with benefits like healthcare and 401k on top of that. plus there's equipment and facilities if you plan to work in a central location. All told, $150k/year for a developer is about right at the lower end. You can probably pick up a reasonably bright recent graduate or someone with maybe one game under their belt for maybe $70k-$75k salary, so call it $100k all-told. That's half your budget.

 

For another $200k, or perhaps a bit more, you can probably find 1 seasoned artist a promising artist who's recent grads or wanting to break into the industry, and a level designer. That's 90% of your budget, at least.

 

Whatever's left can probably buy you a decent soundtrack, foley, voice-recording, and a reasonable level of production on those, if you don't need a ton of individual pieces. That's all of your budget.

 

That doesn't include a marketing budget, or any budget for project management, game design, or marketing, or any pay for yourself whatever role you intend to play. It bought you about a year's worth of burn time to get your project done, or at least to a stage where you can seek additional funding.

 

That's just one example configuration that I think would be reasonable.

 

I don't think the coding would be that much work, especially if you used an engine like Unity. You could probably get by with just one programmer if they are seasoned and well-rounded. They might cost a more per head, but less than a senior programmer + one that's more-junior. It might free up enough for another level designer, a project manager, or some marketing.

 

 

But at any rate, it sounds vaguely like you're lining up several carts in front of one very and increasingly anxious horse. If you're seriously considering financing this somehow, you should really develop the design more fully, do some market analysis, project sales, and build out a prototype on a much smaller budget.

 

Of course, all of that is the route of throwing money at it to make it happen. If you can succeed at selling your vision, this kind of project is not beyond accomplishing with a few years time from some dedicated hobbyists. Easier said than done, of course, but possible.




#5178368 Programing language for 3D games

Posted by Ravyne on 05 September 2014 - 12:32 PM


I really wish we would stop using this description, as it is not actually correct.
 
C++ is flexibly and low level.  

 

I agree entirely with the thrust of your post -- in particular that we do newcomers a disservice by giving them the impression that C++ is simply the logical choice while white-washing its difficulties and learning curve.

 

But--and perhaps you and I are playing semantics between 'powerful' and 'flexible'--I think its apt to describe C++ as being powerful -- almost uniquely powerful. Really, the only languages that can compete in that arena are C++ and its kin C, D, or Rust, but the first of those three offers less in the way of abstraction and library-building, and the latter two, both of which I find imminently interesting, are effectively babes-in-arms -- too new, still evolving. Practically speaking, this makes C++ uniquely powerful (and also uniquely tempting, and uniquely dangerous); as a single language it can touch hardware on the very lowest levels and also build fantastic, high-level, generic libraries.

 

Of course, the trouble is that many people read about the potential benefits of C++, and its widespread use in the games industry, and parrot the story to newbies to the point where its become something of a cargo-cult: Everyone *knows* that C++ gives you the best performance, but rather few know how to get it, and fewer still know how to get it without creating a horrible mess for themselves. Worse, some in this cult continue to spread active misinformation to newer generations -- giving them the impression that coding 'to the metal' is what makes C++ performant without a care for who the audience is. For an experienced programmer, "the metal" is a sort of dangerous place where she knows she can go to find performance, but which she knows well enough not to stick around more than she has to; to the inexperienced programmer, he's told "the metal" is a magical playground where sun-ripened performance grows on every tree, bush, and park bench -- he looks forward to going there, and no good sense of when he should leave. That's the myth the cult sells.

 

I love C++, but I'm cautious of its mythology and I try not to pass it down to new generations without qualifying it. There usually are far better uses of your time -- indeed, better optimizations that can be understood from a higher level -- than simply worshiping at the alter of "the metal".






PARTNERS