Katie

Don't start founding companies yet. You'll just spend all your time doing paperwork and not enough writing code. Seriously; you have NO IDEA how much paperwork the inland revenue can throw at you. PAYE takes either a lot of doing or a lot of paying accountants to do. You can avoid it by not operating payroll, but then you just have to constantly have arguments with HMRC about how you're "not allowed" to do that (you are, but they don't like it) and that chews up time as well.

Get on with writing code. When the games are running and saleable, THEN you can go do the company founding thing.

Sampling textures is something that GPUs are very specifically designed to be good at. It's cheaper than computation in a lot of cases. It's WAY better than conditionals on SIMD architectures; you're better off doing samples and multiplying by zeros at the end than making jumps which cause a bunch of pipelines to be parked and run later. Basically at each decision, one path is taken. All the pixels in the current batch which would go the other way are parked and will be restarted when the chosen path has finished. You can see how decisions are expensive.

On MIMD GPUs, there are usually massively specialised pipelines for doing texture fetches. The individual latency isn't great on these. But you don't care. You've got millions of pixels to paint. You don't care about the latency on each paint, you care about the total pixel throughput; and that can be insane. It's not unusual for 100 or 200 pixels at a time to be doing texture fetches... each one takes 200 cycles to complete, but one completes every cycle if you can keep the pipeline loaded..

Seriously; make the fetches efficient is what keeps GPU designers awake at night, so you don't have to.

"basically, I want my item system and inventory system to work 100% like runescape."

Why not aspire to be better? If people want to play Runescape, they know where it is...

"you could use something like java's/c++ instanceof opperator"

This is exactly why virtual dispatching was invented. So you don't have to look at the types of the objects. You create an interface for doing this and your object types implement it and then you simply call through the interface.

Rule of OO design; if you're using instanceof or dynamic casts or similar monkey business, you've gone wrong in your OO design somewhere. You must find the error and either describe it accurately in the documentation or fix the problem.

Your abstract object needs to specify a way to populate a list of possible command names and actions; probably takes a pointer/ref to the object instance instance (the language object which represents the game object which is of this game type). The names are displayed. When the user picks one, the action is executed. It's probably going to be some simple interface like Java's Runnable or a C++ function object taking no parameters. (The object to apply the work to is encoded i the function object by the menu item factory)

The actual game-object-type classes implement this interface, providing suitably configured command objects as the second part of their pair.

This way, later, when you tire of implementing objects in a hard programming language you can start doing them in softer ones.. like say Lua, and writing the list populator so it fills in command names and Lua function objects and the just dynamically load lumps of Lua instead of having a build/debug cycle.

This also allows objects to change their command structures depending on the world around them. If you're in a suitably magical place, 'wield' becomes an option for the wand. If you're near a river 'deploy' becomes an option for the canoe. That sort of thing.

And since just copying another game is dull, we can think of improvements...

Provide importance ordering on the commands, and now you can float different commands to the top of the display lists (so now the appearance of 'wield' is more obvious to a player).

If you allow things to return non-executable commands, the menu for 'hat' can contain a non-selectable option saying 'already wearing a hat'. And if you remove that hat, this object will change that to a 'wear' command which does work. Now the player knows why an option might become available.

Yes.

Because otherwise, you will spend the rest of your life looking at job adverts for really cool jobs. Jobs that everyone else wants as well. And which hence have a "must have computer science degree" pre-filter on them. 

And you can rail about how it's unfair or try endlessly to convince gatekeepers that you're just as good as someone with a degree...

Or just go and get the degree.

It's expected you get it. Google has only just stopped regarding with suspicion people who didn't stick around for the doctorate. And even those people who will interview you will ask why no degree and you'll need a good story for that. And "couldn't be bothered" won't cut it. And you'll have to tell that story every time you go job hunting until you're 60.

" it's worth mentioning that I have a full-ride scholarship to my University"

And you're thinking of not taking that up? If you don't take an opportunity like that, you're an idiot.

Other reasons to go to uni;

• Everyone else you work with will have. So if you don't, you'll always be the lone one who didn't and doesn't have stories from that time to share.
• You'll meet interesting people. Where do you think Sergey met Larry? FB started on a campus. I met my husband at uni. I met people who I hired a decade later, I got hired by people I've known since uni days. It's a massive networking opportunity.
• You'll learn a lot more than you think you will; including the ability to study OTHER subjects. Take those opportunities because they'll make you a more rounded person.
• You'll get to do random stuff. I helped run the student cinema. I failed the technical test as a projectionist, but I did learn how to manage a door team and how to do crowd control. And once again, that's building a character. And free movies for years.
• You'll be at work for long enough. If you can put it off for three or four years of good times, do so.

" Like if you had an inventory, do you use a class?"

So a useful way to start thinking about this is to do what's called verb-noun analysis. Write some short sentences about things in your world. If you have a thing in your world which has a noun for a name, then it should be a class. It'll then have verbs attached to it, and hence they're methods on it. So; "I want to show the user an INVENTORY. I want the user to be able to SORT their INVENTORY. And that gives you a class Inventory with a sort() method.

Eventually you get used to this enough that you can just sort of see the classes without doing the analysis or you can switch to more sophisticated techniques, but it's a good way to get started.

I can't see anything obvious in the host portion of the code -- certainly if that stuff works on the other phones I'd say there's no problem there.

Are you sure the shader compiles/links/uses? That's a pretty common cause of renders doing nothing. (And it's a step whose functionality differs between the different phone hardwares).  Can you run the shader through the Mali offline compiler? (Available from Arm's developer site)

It's unlikely to be the Mali 400 itself -- because it's definitely possible to draw things on the screen. I mean, really... what are the chances that someone's shipped a whole series of phones that can't render anything to the screen? Wouldn't someone else have noticed? Isn't a chip that used in a billion phones likely to have been a little bit tested?

Isn't it more likely that it's your application?

If you post the source, we could have a look at it for you.

Don't use GLUT -- use the appropriate GL toolkit for your platform (GLX, wGL etc) and just don't create a windowed context.

"This is another one reason as to why we don't see any AAA-titles on Java"

Minecraft is written in Java, Minecraft is not a "AAA" title. But I suspect that doesn't bother the now-multimillionaire author.

Java is plenty fast enough to write all sorts of games. Someone who's been playing with languages for a couple of months isn't writing a AAA title anyway. They're writing Tetris. And Java is a good choice to learn to write Tetris in.

I miss the days of Basic. When you could just turn the machine on and Basic was waiting for you. Didn't have all this crap about what languages and frameworks to use, everyone just used the Basic on their machine and moved onto using bits of machine-code when they were ready. And so people learned how to write game-loops and how to manage state and how to do collision detection and how to make a game actually fun without having a long debate on the internet about what tool to use because there was only one to hand.

"If you want to code, code.

If you want to draw, draw."

And if you want to design games, design games.

Design board games. Write an RPG system and give it away. Design a CCG, print it out using a POD business-card printer. Playtest the things, am-publish them. Just get on with it. Bloody hell, this forum is constantly full of people whining that they don't have the resources to do games when the world is awash with print on demand houses and games components sellers. Design wargames -- that's how I got one of my games development gigs. I can code AND I understand how to simulate tank combat.

Games are games -- understanding what makes a game fun and how people interact with games and with each other while playing them is the experience you need. Want people to let you see what you can do with their $10M-a-month dev team? Might be worth demonstrating you can design a game with $50 of random components first. Because the guys who already ARE running those teams definitely can; Molyneux, to pick an example, apparently designed Populous as a boardgame to start with (using Lego for the modifiable landscape).

What better way to get hired than being able to send the company one of your games that you know is fun and letting them find out that you can make things people want to play. And if you can't do that, why would someone give you millions of dollars a month?

Seriously -- if you can't look a pile of parts and figure out how to make a game from it, you're not a game designer. Because games designers don't NEED a bunch of coders and artists to make something that entertains people. The medium is not the skill. And if you can't afford marble yet, sculpt in clay until you can.

" actually wanting to do the job is worth far more than just the prospects of landing the job."

I don't know -- I've spent my professional life wanting to be a good software engineer. In general, that's only ever led to tears because although they always say they want good software engineers, almost all employers actually want;

• software engineers willing to do a bodge job in half the sensible time
• engineers willing to avoid the actual useful tools or the right way of doing things for what amount to religious reasons. (Eg; here's a copy of Excel. Please implement a database system in it... because we don't want to buy a database system because it'll be too complicated)
• engineers who are willing to put up with using substandard components "because they're already written" which is kind of like asking people to design aircraft around engines which are known not to work but have already been assembled or purchased...
• engineers who are willing to "program down" to the level of the least skilled person the company hypothesises they might hire.[1]
• engineers who are willing to actually lie to clients about the safety, security or correctness of software
• Some or all of the above in combination.

It's dull constantly being asked to under-perform, especially when you're actually good. To be honest there are days (often many of them) when I wish I'd become a lawyer or an accountant. I'd never be brilliant at a career like that, but at least I'd only be as mediocre as people expected me to behave rather than constantly having to tone down something I enjoy being good at to a 4 or a 5 on the dial.

[1] You would be AMAZED at the kind of companies that do that.

"Accelerated C++: Practical Programming by Example", Koenig.

Followed by other books from the same series when you need them.

Also, I particularly recommend "Beyond the C++ Standard Library: An Introduction to Boost" by Karlsson. It's a really good guide to the less hairy parts of Boost[1] and how to practically apply them to improve your coding.

[1] Boost is a set of utility code, some of which has recently been rolled up into the language standard. They provide a lot of helper functions/classes.

" Steel even contains Limestone, if I recall correctly."

Limestone is added to iron as it's smelted in order to combine with acidic impurities and make them solid; at which point they float to the surface and are either skimmed off before pouring or are just left behind if the iron is tapped from the bottom.

"Should I put all vertex data to a single VBO?"

Whereever possible, yes. It means the whole vertex will be pulled into a cache at the same time. By having multiple VBOs, you're using multiple memory units which means multiple caches need to be loaded. Each will contain the vertex data for more vertices, but that's not necessarily useful; if you use the coords for a vertex, you'll use the normal data and probably quite soon, so the memory effort in loading it is useful.

If you have multiple memory units loading many verts into their cache, their effort may well be wasted -- touching vertex V implies nothing about when or even whether you will need the data for vertex V+1.

"If a group has, say 4000 polygons (which could happen for the player models), is it advisable to call glDrawElements once for the whole chunk, or should I cut it into pieces?"

Do the whole thing. Reason; let the driver do the optimisation work. It knows what shape the hardware is, and you don't. Don't try and second guess it unless you have a known crap driver you're trying to work round. Some drivers, for example, may take the min/max vert index and transform everything in that range and then bin the unused values. If you unchunk the data, they'll obviously waste more time on unused nodes. For the same sorts of reasons, try and make sure all the verts in a chunk are adjacent in your VBO.

You're also likely to transform verticies on the split boundaries more than once, whereas as one draw, they'll likely only be done once.

High budget funding, but you don't know how to setup a company? You go to a company formation agent and buy one and rename it. 200 quid.

"They will be needed to sign an NDA but is there any other neccesary paperwork we should look at."

Um. Yeah. You're going to need an employment contract. And some HR policies. And you'll be wanting to get an employment lawyer to look at all this.

" I have consulted with some lawyers but most are not familiar with the technicalities of making game oriented companies along with game copyright and trademarks."

That's because you're thinking they're something special, but they're not. Just go find a proper business lawyer. Not a high street solicitor, an actual firm with a business group.

Are you really sure you're the right person to be handling this sort of thing? This is the noddy end of running a business and you're already resorting to asking internet forums. What's going to happen when you have to fire some of the staff and do it legally? Or work out what the implications are of ditching a publishing contract? Or the really complicated decisions like at what point in a dev cycle to start working on a second product...