Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 12 Mar 2005
Online Last Active Today, 01:08 PM

#5248822 Planning to write an OpenSource FPS Network lib - Design Considerations Welcome

Posted by frob on 25 August 2015 - 12:19 PM

What do you hope to offer that existing, high-quality, vetted and debugged libraries don't already offer?  What I see there is even less than what is offered by non-game RPC libraries.


What makes this better than the competition?  What do you hope to offer by building this? Or is it a project for you to learn from?

#5248818 Legal dangers for small indies

Posted by frob on 25 August 2015 - 12:00 PM

You don't need to worry about this until you have a saleable game product.
Not always.  Depending on details it can be more important to get a lawyer involved earlier rather than later.


Working alone is far less risk than working with a group. When you've got a group of people you need a lawyer involved up front to ensure continuity of the project. Without proper agreements in place everyone's work is owned by the individual, so if someone leaves for any reason (move, loss of interest, death, dispute) the combined work enters a kind of legal limbo where it cannot be sold or transferred or used until the ownership of the missing person is resolved.  You need proper written agreements to assign the work to a person or to a legal entity.  People involved also may need to have employment agreements or collaboration agreements in place in the event of a dispute.


Working as an individual there are concerns with contracts and agreements you make. Are you signing as a person, or are you signing as a corporate entity? While it probably doesn't matter, it could make a difference if agreements are in your name or your company's name. 


Any time money is involved tax law kicks in, and that's somewhere it is important to have legal and tax advice. Depending on your location and the amounts of revenue, details about how the money is collected are important, details about tax collection and turning tax money over to the government are important. If the money is going to you as a person, or if the money is on paper going to a corporate entity first and then going to you as a capital withdrawal, that can make an enormous difference.  Money changes hands for many services long before you have a product for purchase. 


Depending on your location on the globe, you probably want to register your copyright and trademarks with the appropriate government groups so you can enforce your rights if necessary. In the US, copyright registration is just $35 and can be done in under a half hour. 


When you build your website there are law you want to respect, usually in the forms of a Terms of Service page and a Privacy Policy, but some locations on the globe have laws that you must display a cookie policy or age verification. Others have requirements that you retain logs of web requests for a minimum amount of time. Others have requirements that certain data must meet data security rules.



It gets worse as you grow.  When small, people often won't take action because you don't have resources. As the business grows it becomes more valuable of a target, people assume they can invest a few hundred or thousand dollars worth of time threatening or attacking and get more than that out of you. You'll get crazy C&D orders and settlement offers for all kinds of crazy claims.  I've seen "settlement offers" stating that my small business was violating ADA requirements for customers even though it is just me doing moonlighting work, claiming they will settle and agree not to sue even if I don't correct issues in my bathrooms, kitchen areas, walkways, and doorways.


Once they reach large enough status companies get a continuous barrage of legal threats. Threats that a newly announced game was stolen from someone's idea. Threats that someone once posted an idea similar to that on a forum that one time and it clearly predates the successful product. Threats that a person once submitted an unsolicited idea to someone at the company so clearly the company stole it. Threats that they're violating a patent over WiFi and can settle out of court for a low price.  As you grow the risk and legal costs grow considerably.

#5248656 Creating a fancy weapon slot system for my game

Posted by frob on 24 August 2015 - 07:05 PM

How about grenades? Knives? Spears?

Most game engines I've worked with handled it through data, not code.

Things that can be held have a named mount point in the model. Models have multiple mount points that can be used for different things.

A tiny pistol, a rifle, a shotgun, a rocket propelled grenade launcher, they've all got different details. Most of those details can be addressed through data, not through subclassing.

Data can specify that model X mounts on mount point "long_gun_slot", has a set of named animations for pickup, drop, carry, and shoot, has a data value that shows where the reticule is supposed to be, and more.

All of that is data, not code.

#5248654 Portfolio/Resume Review

Posted by frob on 24 August 2015 - 06:57 PM

Just one of thousands of search results show consistently the same thing: It should only include experience for which you were paid. This includes full-time work, part-time jobs, self employment, internships, and projects for which you were a part of temporarily. It doesn’t include volunteer jobs, or any other type of unpaid, charitable work. If you do feel there are unpaid experiences that the hiring manager should know about, the information should go in its own section. Label it “Relevant Experience” or “Other Experience.” Write it the same way you will the work history.

Did they hire you and pay you at milestones, or regularly every few weeks? Or perhaps did you help start the own business, registered it as a business, operated as a business, with workers signing contracts of employment with employment terms but paid on ownership shares or some other contractual payment? Or was it a group of like-minded people doing something for fun?

Based on what little I've read it was a group of fans building something on their own for fun. If there were formal employment contracts in place and payments made, with some degree of supervision and accountability then it is employment experience. If not, it is not work experience and belongs in a separate section.

#5248597 What need to learn gpp?

Posted by frob on 24 August 2015 - 01:17 PM

Gameplay programmer, gameplay engineer, or similar title is one of the most common type of programmer in games.  The role is not to build an engine or build tools or technology; they start with an enormous list of objects and then make all the things.  Anything that can be interacted with, anything that can be used in any way or anything that does something, that is something they program.


While it helps to know things like the rendering pipeline, it is not necessary for most daily work.  If your goal at the moment is to make a game, by all means start with an existing major engine. That is exactly what you'll be doing if you get a job as a GPE. The company has an engine, you hook up all the parts.

#5248577 C++ | Fixed Byte Size

Posted by frob on 24 August 2015 - 11:42 AM

In short, C/C++ are horrible languages, which are deliberately underspecified (in past to support now obsolete platforms, later to allow compiler writers to get better benchmark stats irregardless of risk of producing broken code) and we'd be better off if K&R had just correctly implemented BCPL or all people would have ignored C and instead used Pascal?


That's a bit over the top with hyperbole.


C was written to be portable, as an abstraction from assembly languages, but it was minimally specified on purpose.  The original standard library was tiny, and it has grown in ways that work nicely.


I've worked with both C and C++ on a variety of embedded systems and older hardware.  It works not just on the 8-bit bytes that are common today, but also 7-bit bytes, 9-bit bytes, 12-bit bytes, and even 32-bit bytes I've worked with on one FPGA.  The language works with 32-bit pointers, 42-bit pointers, 16-bit pointers, 8-bit near pointers, 48-bit pointers which are the size of physical addresses on modern x86-64 machines, 56-bit pointers, 64-bit pointers, and more.


In short, the languages provide an amazing abstraction that works on a diverse collection of hardware environments. 


In the 1960s where they were working there was an enormous variability of hardware. Programmers today generally see a monotonous landscape of nearly identical processors. While it appears homogeneous if you limit your views to desktop computers and the big chips, if you expand your view to include all the little chips, all the signal processors and FPGAs and CMOS processors and assorted other microcontrollers, you'll discover a wide variety of processors, many of them are radically different from the x86 family you may be used to.

#5248458 Portfolio/Resume Review

Posted by frob on 23 August 2015 - 11:33 PM

Reading your resume, the most critical thing is to show, don't tell.  You have some good things in there, but they are not obvious.


Education says you graduated this year. Great. That puts you firmly as an entry level worker. Very clear you've got a BFA in sculpture (rather than digital arts or something game related, but that's okay I guess), and an associates degree in visual communications. You might consider adding some bullet points about notable work you did in school, assuming you've got some. Now I know what jobs you might work out for.


Skills.  Most of this is telling.  You state you have sketched and made concepts, you state you've worked with unspecified level editors, you state experience "designing major gameplay systems" that are unspecified. You state that you can use Photoshop, InDesign, Illustrator... which are fairly basic expectations considering a BFA. You made timed sketches, like everybody else who has ever had a sketch or drawing class. You state you've got experience with materials in 3D works, which again should be obvious from the whole "sculpture concentration" above.


Cut that whole "skills" section.  You'll be reusing some of it by SHOWING what you did, give examples of specific projects and how you used them. They are useful details, but not out of context like that.


The Experience section shows a gross misunderstanding.  "Experience" is a single word shortening of "Work Experience", or "Professional Experience". If you did not get a paycheck for the task, it does not belong under "Experience". I notice you list both your associates and bachelors degrees as "experience", they are not; if you want to call out any work done as part of your education they belong as bullet points under education.  


You don't get to list Mechwarrior:Living Legends under "level design experience" unless you actually worked at a paid job and your job title was "Level Designer".  If you built a mod or maps you need to list it under a "hobby projects" area or similar that doesn't represent paid work experience.  You should also call out details of what you did specifically versus what others on the team did.


You don't get to list "CryEngine 2" design experience unless you worked for Crytek, or worked at a company using CryEngine and your job title was "Level Designer".  If you built some maps or mods, again that goes under "hobby projects", not "Experience".


You don't get to list "Boy Scouts" as a 10-15 year old under job experience, but you might be able to put it in a  "hobby project" or "Other life experience" area. It doesn't have much to do with game development, but if you're struggling with content on an entry level resume it shows you did stuff without being too much of a filler or rejection-inducing material. My guess is you don't need it.


Cassano's Pizza King as a delivery driver... This CORRECTLY BELONGS under Experience.  It shows you an hold a job for five years, show up to work every day, take instructions and follow them.  That is a good thing.


Boosalis Baking also CORRECTLY BELONGS under Experience.  You can hold a job, show up to work, take instructions and follow them.


You hid those in Experience. You may think it is embarrassing because it isn't game related, but employers know you are an entry level worker.  Once you've got a few professional jobs you can let them roll off the bottom of the page. But for now they are critical because they show you can keep a job long term, can work while in school, and more. 


Freelance Graphic Design work June 2015-Present... Sorry, doesn't count as experience yet.  If you have some regular and repeat contracts and you can list who you contracted with, then it may eventually be appropriate for Experience. Unless you've got at least six months or so of regular paid experience, it stays under "Hobby Projects".


Your awards are GOOD.  Keep them, but group the details together.




I'd restructure with this format:




Visual Communications

Academic projects included:

 * Project 1, something you did solo and the tools you used, what made it awesome with keywords like InDesign or Illustrator.

 * Project 2, something you did with a group and the tools you used, what made it awesome with keywords like Sony Vegas or AVID Editing.

 * Project 3, some other project, what made it awesome with keywords like Flash or Papyrus or Typography.


Hobby Projects:

 * Mod of the Year 2009 

  > Gushing details, link to award web site

  > Link to project

 * Crysis Mapping Competition

  > Gushing details, link to award web site

  > Link to project

 * Other Hobby Project

  > Details about your hobby project

  > Link to project


Work Experience

  * Boosalis Baking - shows you picked up a day job while still finishing school

  * Pizza King -- you held a job for five years, plus kept it as a night job with the one above while still in school. Shows you can work hard if you have a mind to.



Assuming the Mod of the Year was entirely or mostly just your work, you could probably get picked up pretty quickly as a level designer... except for the fact that level designer jobs are extremely rare.  They exist and you should apply if you find any, but you'll need to be doing a lot of hunting, primarily through word-of-mouth and finding friends-of-a-friend, to find that rare opening.


After that I would probably focus on any art position you feel qualified for, probably modeling and concept art based on what I see on paper.  There are far more openings and once inside you can keep your eyes open for opportunities to design levels in addition to your primary artwork role, then transition over when the rare opportunity appears.

#5248319 C++ | Fixed Byte Size

Posted by frob on 22 August 2015 - 09:25 PM

It's not even _possible_ for this to be fixed in C, portably, for all CPUs. Most CPUs have an _alignment_ requirement for data types. That means that you _cannot_ simply map a 16-bit integer to some arbitratry address in memory, but rather that it must map to a 16-bit aligned address.

I've seen this true of SIMD instructions, my memory is hazy but I seem to recall byte addressability for standard instructions at least on x86.  What architecture are you thinking of?

The x86 integer alignment design decision is a historical oddity. Very few processors allow misaligned data, near universally processors use a separate opcode that reads or writes a potentially unaligned value and operates much slower. In x86 programming it has caused no end of grief since it was introduced in the 1970s, as chip designers need to handle values that span cache lines, sometimes spanning multiple levels of cpu caches.

Other processors could enjoy having a separate instruction, effectively a "fast load" and a "slow load", a "fast store" and a "slow store". But Intel needed to add logic to all their loading and storing opcodes, adding a bit of complexity to most of the opcodes.

By the time the late 1980s rolled around they realized the magnitude of their decision, and going forward all new data types have required proper alignment. Even so, I wonder how many work-years have been spent by those hardware engineers as they need to go through every micro-op in the processor and maintain circuitry to handle both aligned and unaligned versions of them.

#5248100 Memory management

Posted by frob on 21 August 2015 - 12:38 PM

memory usage increases by 5mb per switch.

The fact that it is growing every call indicates you've probably got a leak of some kind where you create objects but don't properly clean them up. 


5 megabytes is a lot of memory. It should be easy enough to track down where new objects are being created, drop breakpoints and ensure the old objects are cleaned up at the right time.



void StateManager::changeState(std::unique_ptr<State> state) {...}

I'm pretty sure this isn't doing what you expect it is doing.


The smart pointer wrappers (unique_ptr, shared_ptr, weak_ptr) are about ownership. 


Passing a unique_ptr by value means you are transferring ownership. The function becomes a sink, consuming the old smart pointer. Is that your intent? Do you mean to consume the state, making it inaccessible and dead to other locations in code?


It seems what you are describing is more an issue of lifetime management.  Decide the lifetime of the objects, when it should be created, who should create it, when it should be destroyed, and who should destroy it. Everything else follows.


Do you understand the lifetime of your objects? If you do know those details you should be able to jump directly to where they are supposed to be destroyed, drop some breakpoints, and validate that they are or are not being called. Then you can backtrack through the object's lifetime to find where the defect happened.



As for smart pointers, some people tend to forget what they are for.


Smart pointer wrappers are a way to communicate and enforce ownership, to ensure objects are created and destroyed in an expected time and manner.  Use unique_ptr to indicate a single owner; it is owned and managed by a single source, and any time you copy it -- even to pass it by value as a parameter -- you will change the owner and remove it from the previous owner. With unique_ptr there should be a strongly defined source and sink; a source generates the object, a sink destroys the object.  Use shared_ptr when you have a source for objects but no clearly defined sink; you know what generates the things, but there are many different ways the ownership and lifetime can end and during design you honestly have no idea where that will be. In practice, I've found these are fairly rare in big games since in big games object lifetimes are strictly managed. Next, weak_ptr is like a temporary shared ownership from a shared_ptr, basically saying you will hold the pointer for a time but you don't own it and might be gone before you get around to using it, but you only know this because you understand object lifetimes. And finally, in cases where object ownership is not a concern and the object is guaranteed to far outlive the immediate use within a function, nothing is wrong with passing a raw pointer. 


Depending on the nature of your State object, it may be better to pass them as references or const references. It may be better to pass them as pointers or const pointers.



You don't give enough code to show why a 5 megabyte chunk of memory gets leaked, perhaps your destroy() function is missing some deeper cleanup, perhaps the destructors are missing some cleanup, perhaps there are other resources you forgot, perhaps your init() function is making too many things and not cleaning up temporaries, or perhaps there is something else entirely.  


Fortunately that's a distinctive enough change you can easily track it, and with a divide-and-conquer approach you should be able to find the operation in short order.

#5248086 App to make Action RPGs on iOS: seeking views

Posted by frob on 21 August 2015 - 11:54 AM

Not really a For Beginners topic.  That is a place for beginners to ask questions without fear, not a place to ask questions to beginners.


Moving to Mobile section.



I tend to second the concerns. I've worked on a lot of systems where they try to make mobile editors that generate mobile systems over the years.  That includes editors on Newton for Newton apps, editors on Palm for working with Palm apps, and so on. Often it is a bad fit, the devices are generally too constrained to do anything well.


It might work out on larger tablets where you've got a 10 or 11 inch screen, but on a little 5 inch touch screen it tends to be quite difficult to do anything but the simplest actions.


Of course if your app happens to solve that problem, if it feels like a joy to use your editors and you can build and run the final application on the devices, then by all means go for it. Those are hard problems, and if you've got a good solution then I hope you enjoy rewards of success.

#5247891 C++ | Fixed Byte Size

Posted by frob on 20 August 2015 - 09:48 AM

I as well have never seen it documented anywhere that...


When it comes to what the compiler MUST do, the only authoritative source is the language standard, not other documentation, books, or web sites.


I've always felt it was odd how few programmers even know about the C and C++ language standards, and how even fewer of them have ever read them.

#5247791 Programming base engine for mobile game? choose from a few

Posted by frob on 19 August 2015 - 10:38 PM

And just to make things more interesting, there are even more popular engines in the Mobile forum FAQ.

Unity and Unreal are not expensive until you start making money, and then your investment is a fairly small amount compared to whatever revenue you earn.

Really every engine, every tool, they all have their own style, their own feel, their own list of pros and cons. For a tetris style game of falling 2d blocks probably some of the 2D engines will work, as would the 2D graphics libraries that are not engines.

I don't really have much experience with most of those you listed to say if they are particularly suited (except perhaps Unity, which could handle it with the 2D systems although tetris isn't a perfect fit), but the ones in the FAQ link are fairly popular.

#5247788 ByteBuffer[0].asFloatBuffer() issues

Posted by frob on 19 August 2015 - 09:16 PM

I'm not proud to write this but it turns out...

No need to be embarrassed.

Those two items -- buffer overruns and null pointers -- are among the most common programming bugs.

Any veteran programmer has run across them thousands of times over their careers.

The harder part is tracking them down and fixing them. No need to be embarrassed in asking for help looking for them, sometimes entire teams can spend months looking for the source of various data corruptions and bugs. Every project I've been on has had at least one "nemesis bug" that haunts the team for weeks or months, with everyone hunting for that elusive flaw.

#5247765 C++ | Fixed Byte Size

Posted by frob on 19 August 2015 - 04:36 PM

How do I ensure, that WORD is always 2 Bytes and DWORD always 4 Bytes across diffrent hosts?

I've been taught that diffrent CPU-architectures define different sizes for the data types.

So, how can I ensure having the right size of the variable?


Just to be clear, they're not talking about different cpu architectures like going from a windows machine with an Intel processor to running the same program on an AMD processor.  That is talking about going from an x86 family processor (like your PC) over to an ARM family processor like your cell phone.  Or potentially they're talking about moving from a 32-bit compiler to a 64-bit compiler.  You have to actually change architectures, which means a whole lot of things change.


If you are running the same executable on all the different machines the sizes will be the same.


The other thing to consider is padding inside the structure. Just because a field is 32 bits or 16 bits does not mean they are packed the same. Padding inside structures is an implementation detail in this language, but must be a specific spacing for file formats.  They could all be aligned on byte boundaries, or 2-byte boundaries, or 4-byte boundaries, or 16-byte boundaries, or whatever else the compiler feels like doing.  There are compiler-specific commands to adjust that.


Endian-ness will be another concern if you are going cross platform. While the values are the same as far as your code is concerned (the value is 12345678) the actual encoding of the byte pattern can be different. On one platform a 16 bit value may be encoded as AB, on another it is BA.  For a 32 bit value it may be ABCD or DCBA or on some middle endian hardware potentially BADC.


These concerns don't really apply if you are talking about staying on a single architecture, such as building a program that only runs on 32-bit windows, or only runs on 64-bit windows.

#5247759 Different Resolutions

Posted by frob on 19 August 2015 - 04:17 PM

I don't really understand the problem with aspect ratio because there is none.


There can be a problem.  Here's a picture with four different screen sizes and aspect ratios.  (1440x900, 1200x800, 1280x800, 800x600)




The difficulty is that each person gets a different view.


It is not something that can be easily solved with scaling, since different aspect ratios mean that one player will be able to see more to the sides or more to the top and bottom.


In some games there is no particularly advantage or disadvantage to being able to see a different size field of view. If you are playing a turn based game or a single player game, or if each player's view makes no real difference, then feel free to show whatever fits on the screen.


In other games, like the example in the picture, more screen real estate means a big advantage in what you can select or activate. The player with the smallest screen (red) can only see a few units and will be surprised as more come on the screen. The green and purple players can select a bunch of buildings while seeing the same area as the red view, each has their own slightly different size; it is only 80 pixels difference, but if that means seeing units on the edge of the screen 80 pixels earlier, that is an advantage. And the lucky player with the full view of the area can see not only the battle and select all the buildings, but gets an even bigger advantage of watching other units walk in from the edge long before anyone else.


Some games use the dreaded black bars, although that isn't always bad.  Go back a decade or two and games like the Warcraft series (the thing the "world of" was based on) drew a beautiful decorative trim around the screen that was used for the UI buttons, no matter their screen sizes everyone was shown exactly the same view of the world that was potentially scaled.  Several of Westwood's RTS games back in the day had a similar technique to keep it fair.  The physical size could vary, but all players had exactly the same opportunity to view the same logical size view of the world.


If the size of a view port becomes something that provides a real advantage to certain players or a disadvantage to others, it is something that needs to be considered.