Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 12 Mar 2005
Online Last Active Today, 07:25 PM

#5247263 How can this code be refactored to be more proper OOP?

Posted by frob on 17 August 2015 - 03:51 PM

Sorry, missed this one and it was just asked about in a private message:

For this code, isn't there a better way to represent or refactor it out of the code completely?


If your goal is to expose the values, that is no problem.


What you've got there works just fine, especially in a header file. That is, in c++ those function calls can vanish completely thanks to the optimizer's magic, with the values accessed directly from memory without any indirection or function call overhead.


But if you are working with systems, it may not be as good. If you have a set of systems that handles position then the object itself probably doesn't have the x and y coordinates, it probably has a reference to its location in the spatial tree. Similarly the health component might be a reference to another health system.  That might be handled with a single indirection:  void SetAlive(bool status) { myHealth->SetAlive(status); } or it might be more involved if you have custom processing to do.


It really all depends on how your system is organized and designed.


The recommendation to play with existing major engines is still there. Once you've been exposed to better engines it can help you think more about how to reuse and how to work with systems rather than focusing on the smaller pieces.

#5247258 Time Based Movement: NPCs Spawning Too Slow when Framerates are High...

Posted by frob on 17 August 2015 - 03:33 PM

Fix your timestep, your graphics frame rate should have absolutely nothing to do with your simulation update rate.


Consider that with almost no effort you can adjust your monitor frequency. Many support update frequencies as low as 30 Hz, some support frequencies as high as 200 Hz. If the player takes further steps to disable vsync they may be able to reach radically higher framerates, potentially into the thousands per second.


If the two are related I can easily exploit your game. I may reduce my screen refresh rate to artificially slow down the game, or I may speed it up so I can get that many more updates to speed it up.

#5247251 Different Resolutions

Posted by frob on 17 August 2015 - 03:20 PM

In that case, moving to Mobile & Console.
There are several questions about it, enough that I'm thinking I should add it to the FAQ. 
There is no universal ideal method.  You need to figure out what specifically works for your game.
In addition to those Norman mentioned above, a common method is to have several different aspect ratios and scales, to do UI layout based relative to key points, and display the game in a way that best fits your game.
You might have a small 6" display with a small number of dots, or a large 11" display with a large number of dots. You might have a small 6" display with an enormous number of high resolution dots, or a giant 11" tablet with a small number of dots. You might have something in between. There are small phones that have over 500 pixels per inch; there are large tablets with under 90 pixels per inch. Your display may be portrait, or landscape, or even square.
For UI elements, the first thing to figure out is how big a finger touch is. For your game and your controls a UI element on a specific screen might be anything.  Consider that if you're on a Droid Turbo you've got 565 pixels per inch on a 5.2 inch screen. But on a 10.1" tablet with 800x600 resolution you've got about 90 pixels per inch.  So in those cases the small screen icon needs to be about five times bigger than the big screen's icon in order to take the same physical space.
Once you've figured out how big you need the icons, you need to figure out where to put them. Fixed layouts are easy, but often dynamic layouts are better for the player.  It is common to start in one of several key areas and spread out from there.  For example, starting in any of the four corners and then traveling horizontally or vertically out.  Or starting in the bottom center spreading out horizontally. You need to take care to avoid overlapping. If you're going up from the bottom left, try to not also go down from the top left.
Then you've got to do something to keep the game fair for the playing board.  In single player games it doesn't make much difference, but multiplayer games being able to see a bigger view of the field can be very important.  You need to decide how to make it fair when one person has a 640x480 screen and another has a 2560x2480 screen, playing against each other.  One player has more than 20 times more dots, do you show them 20 times the playing field? Or do you scale the playing field so they both see about the same number of items?  One player has a 3:2 display, another 4:3, another 16:9, is your game best by showing black bars, or is it better to show the content in that direction? The choices are highly dependent on the type of game you are playing.  
The questions are basically the same for each app, but the answers variable by project:  Do the touchable things need to be a certain physical size (such as fingertip sized) rather than a certain pixel size? Do the UI buttons need to be in an absolute position or a relative position? Do the players need to see the same count of items, or the same quality of items? When screens are different, do the players need to have the same amount of content visible?

#5247239 Does in game advertising work?

Posted by frob on 17 August 2015 - 02:52 PM

Several of those single-choice options should be multi-choice.  There may have been multiple products in the game.  Your survey has a choice between posters/billboards, static objects, interactive objects, integral characters, and audio should not be radio button, I may have encountered several of them.  You ask for "the most critical factor" but none of those appear as the critical factor to me. 


It looks like you are pursuing an interesting research line, but I'd beware of garbage in, garbage out, with a badly written survey.

#5247224 How does game engine logic work?

Posted by frob on 17 August 2015 - 02:30 PM

Usually there are interrelated systems.


They generally have a rendering system that handles all the manipulation of graphics and displays it on the screen. These typically involve graphics models and textures.


They generally have a spatial system, often coupled with a physics system, that handles where things are and how things move. Note that physics models are often different than graphics models.


You have a simulator system that contains game objects and simulates them.  Game objects often have references to their graphics representation and their spatial representation, but not always. 


There are often many other systems, all loosely related.  Large established engines invest a lot of effort to allow reuse of items within systems. These days that means building small components and then attaching them to logical objects.  You might build a collection of AI components that can be attached interchangeably to many other objects, you might build different physics components that attach interchangeably, and a collection of steering components that attach interchangeably. 



Systems are best designed when you think in general terms and broad verbs. For example, "MoveVertex" is very specific and only applies to some things, "PlayAnimation" more broad and can be applied to almost anything.


Building good systems requires experience.  Experience is gained by building bad systems and making mistakes.  So don't worry very much about doing things right at this point, go gain some experience.

#5247220 A request for advice

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

Trying to get back to your questions, the answer to all of them is basically the same:



Use what you've got, and do anything.



1) Yes, flash has been trending downward for several years.  But that doesn't mean it is dead.  It isn't dead, and even on present course it likely won't be dead for at least ten years.  There is an enormous amount of old stuff on the Internet, and dropping flash means upsetting a lot of people. 


HTML5 + JavaScript has been trending up for years. It is still a frustratingly difficult path, and in spite of companies claiming to do all they can to maintain compatibility this software needs to be continuously rewritten. We've got a long list of bugs flagged "Chrome 45" even though it is in beta, and an enormous list of bugs flagged as "Edge". Every browser does its own thing, and there are so many standards that they've each chosen different sets to be compatable with, plus their own custom options besides.


Using existing engines like Unity and Unreal means you're hitting a separate platform that is moderately stable and somewhat under your control, and both of these are going to be around for many years as well.


You don't even need to go with modern tools.  You can find old legal copies of systems like Delphi from the late 90s, blow the dust off the box, and use that if you really want to.  Use what you've got.


For a beginner, the choice of which one to use is less important that the choice to actually get started.  Pick whatever language you want, whatever tool you want, and try building stuff.  You are not in a position to build a blockbuster AAA game, but you are in a position to do something fun and creative.  The popular game 2048 was a clone made over the weekend done as a learning experiment for the platform. There are many quirky little fun projects that are fun because they aren't trying to be everything.



2) For which platform to use, pick the platform you have.  If you've got Android devices don't chose Apple.  If you've got an iPhone and iPod don't chose Android. If you spend most of your time on a windows PC don't go for mobile or for Linux or Mac. If you spend your days on linux machines don't bother with Windows. Target yourself first. Use what you've got.


Use what you've got, don't worry about there being a wrong platform. The right platform is whatever you've got.



3) For scoping projects, a good recommendation is to try to do one thing every month. If you don't accomplish it after the month is over, don't fret.  Don't keep working on it since that tends to lead to paralysis, just dump it and pick a new project of the month.  Repeat with a new "project of the month" every month, and you'll quickly discover what you can do in a month and what is too big.  Your first few projects will be too big, and that's okay. Next month, start with a smaller project; you know more than you did before, and the project is more achievable.


By doing a project per month many will be bad, but by the time school is over and you're ready to enter the work force for real, you'll have a great collection of small projects and demos you can show to prospective employers.



So repeating as I started, at this point don't worry about doing things wrong.  Tinker, practice, use what you've got, and spend your time just doing anything.  You are starting out and exploring, as long as you are moving somewhere there is no wrong direction.

#5246842 How can this code be refactored to be more proper OOP?

Posted by frob on 16 August 2015 - 12:30 AM

The reason some people say to not put getters and setters in is the tell-dont-ask-principle.
It is there to prevent unrelated objects from mingling with the guts of your object. If you have getHealth and setHealth anyone can just look inside and change it.
If you instead have applyBonusHealth, receiveDamage, receiveHeal, isAlive the Enemy object can have all related validation and logic which belongs into it.

Excellent example. That is thinking in systems as well.

You have a health system that does operations with health objects.

Usually a game object acts like a container for multiple system's objects. A game object has a health status. A game object has a physics object. A game object has a texture and model reference.

Objects are nouns, functions are verbs. You can make the verbs very specific like "moveVertex", but you are often better with broader verbs like "playAnimation"

#5246831 How can this code be refactored to be more proper OOP?

Posted by frob on 15 August 2015 - 10:48 PM

Depends on the details.

The reason that usually works so well in C++ is that these non-virtual functions can be inlined if you implement them correctly by placing them in the header and feeding good compiler options. Thanks to the magic of optimization the data can be read directly with a single cpu instruction instead of actually calling a function, passing parameters and return values, or doing other work.

It works less well in situations where the compiler cannot do that. If they are virtual it still requires a virtual dispatch as well as a function call. If they are placed in the implementation file rather than the header the tools usually won't optimize the call away requiring a full function call.

All the work of passing parameters and return values, function call setup/teardown, and potentially virtual dispatch can turn a direct load -- potentially a fraction of a nanosecond -- into an full call -- potentially several hundred nanoseconds. Multiply all those nanoseconds by tens of thousand or hundreds of thousands of calls and very quickly you're talking about a big chunk of processor time.

But that optimization of inline accessors and mutators isn't the big thing here. Usually 'object oriented' means thinking about systems and how objects move through them. Rendering objects move through a rendering system. Game objects move through a game simulator system. Networking objects move through a serialization, data transfer, and deserialization system.

Thinking in terms of systems, the textures tend to fit within a graphics system, positional information tends to fit within a spatial and physics system, AI tends to fit within the simulator system. Often it can make sense to have a game object link together multiple systems through composition. The object has a reference to its spatial representation, it has a reference to its graphics representation, it has a reference to whatever else it needs.

#5246580 Code generation vs. Framework

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

The variant I'm considering trying first is kind of like your option 3, only inverted. The plan is for the generator to spit out a template where the programmers can then fill in the hand written parts. The generated and hand written code would be separated by some kind of special comment markers.

That's a dangerous road, but can work out.


The first two immediate difficulties are that if you change the generation tools you'll need a smart way to modify all the previously generated code without seriously damaging the changes, and second that anyone making changes outside those regions could have some seriously bad problems the next time the tools were modified.


My preferred method for that type of system is to have the generator run only once. The output is posted to version control and then treated like any other source code.


If tool changes that require modifying previously generated code become necessary, whoever submits them will need a massive change list touching all the generated files to get them into compliance. Most changes will be minor and can use a copy/paste, but the developer and tester working on the change would need to manually verify that all of them still work. 


It is often best to not build such generation tools until you've done the non-generated version many times, the problems have been worked out so the pattern is extremely solid, and you know exactly what boilerplate needs to be created.  Otherwise chaos and confusion are probable as the system grows and gets modified. Those are not guaranteed to happen or be problems, but they can happen very easily, especially on large projects.

#5246576 What exactly do I send in packages?

Posted by frob on 14 August 2015 - 04:04 PM

See the the links in the Forum FAQ item #12.

#5246331 Fresh libgdx test project errors when running on Android

Posted by frob on 13 August 2015 - 05:30 PM

Out of curiosity, is that the name of your project? Did you name all your packages correctly, or modify them after they were first configured by your tools?

My guess from the error message (class does not exist) is that they don't match.

#5246153 Code generation vs. Framework

Posted by frob on 13 August 2015 - 01:21 AM

Both, either one, or neither.

The route of your generated code isn't too terrible, that's what languages have been doing since the invention of programming languages. You take one source definition, process it, and come out with a useful output. That output may be a game level file, a zip file, a runnable executable, a movie, or another source code file, to name a few. The tool serves as an abstraction. It takes repetitive pieces of functionality and gives it a more accessible interface. If that abstraction helps you think about your process or build things faster or more efficiently, go for it.

The route of a code framework is a similar abstraction, you are taking pieces of functionality and giving it more accessible interface. The big difference is that it is less transformative. You are sticking within the same set of tools and languages rather than a tool that maps your scripting into generated source.

Generally I prefer to stick with a framework since I can do the work inside existing tools. But sometimes it does make sense to build your own tools, some custom grammars and interpreters and generators. Whatever works for you.

#5246018 Unity Asset Store license

Posted by frob on 12 August 2015 - 10:55 AM

Please be careful to note that the license is about the store, not the contents in the store.



Reading it carefully, that document allows buyers and sellers to use the site as a marketplace. It is an agreement that lets buyers come in, read the product labels and share reviews. The agreement also lets sellers come in and put their products up, even with a possible cost of zero.


That is not the license agreement for the individual products. The products have their own licenses, some better specified than others. 




Written differently:  Those are the rules to be at the bazaar generally, the rules of conduct for the semi-public area with thousands of others. They are not the terms of sale with individual vendors at the bazaar, which are likely different.

#5246009 Unresolved External Symbol

Posted by frob on 12 August 2015 - 10:17 AM

An unresolved external almost always means you forgot to link to your library.


An 'external symbol' is a name used in your program. In C++, that's usually a class declaration or function prototype.


The build process has several steps. During compilation, the compiler makes a little placeholder that says "Go to a function with this name, but I don't know where it is yet." Then during linking, all the modules and libraries are examined and those values are looked up across the modules; the linker resolves all the names and inserts the proper objects in the right places in the code.


When you see the error, it means the linker opened up all the different libraries and cannot find a name that match. The lookup was "unrsolved", not found.


So to fix it, make sure you are actually linking to the library that includes the code.

#5246005 Using the Shared Preferences and Its impact on the multi-stage games security

Posted by frob on 12 August 2015 - 10:10 AM

I understand that the data stores in a xml file and using the emulator we can access to the xml file and this is bad for applications security.

Yes, it can be. So don't store security information -- like passwords -- in there.

when the player want to close the game and then when the player want to launch the game, the player should do the game from the same level.

That is game save data. It is not security information. Store it wherever you like.

But the problem is if in Shared Preferences data stores in a xml file and they are visible by emulator, as the result the game levels are permeable easily.
That is not a problem. Running in the emulator they can do anything they want. They can pause the program, debug it, look for values to cheat with, modify routines, and otherwise do whatever they want with the program.


That is not a thing you can change. You don't own their machine.

Are there alternative solutions? How can I create multi-stage games?
You build your games and store the data somewhere.  


You stop freaking out that other people can make changes or see ahead or otherwise poke and prod at your system.


If you are making an online game, you do things slightly differently. You build a protocol of commands and events that represent what goes across the network. Then you tightly control access to that critical data, giving only the information they need to render the game. The other content is kept on the server, never to leave the hardware you control.