I've just started using Unreal Engine 4, but whenever i choose Object as parent class for my new blueprint, i don't have any constructor (like Construction Script function for Actor)
How can i make a constructor?
I don't want to use Actor becaue the class is storing the equipment data for my character.
Thanks!
I'm afraid it's not possible. Technically Construction Script is not Constructor as you know it from C++. It's somewhat misleading name.
Technically C++ equivalent for Construction Script is AActor::OnConstruction(), not class Constructor.
You must also consider the fact that UObjects are not replicated by default. In future if you would want to make your inventory replicated, you would need to either switch to Actors (which is not that good idea), or write it in C++, where you can explicitly tell, which UObjects should replicate as part of Actor or ActorComponent.
https://github.com/iniside/GameInventorySystemPlugin
Here is Inventory Plugin I'm developing. It's still WIP, but basic functionality is now implemented and it should work with 4.6 version of engine. Right now it's combination of C++ and Blueprint. I also recommend rebuilding it from source if you want to try it out, since default binaries are build against source version of engine.
It should give you nice starting point, to either see how things are done, or just straight to use it.
Related
The package org.lwjgl.opengl contains a whole bunch of packages named from GL11 to GL44 - one for every version from OpenGL 1.1 to OpenGL 4.4.
What exactly does this mean? Does each of these packages contain a separate, working version of OpenGL, or does each package contain only items that were introduced in that version? How do I figure out what things are where?
It certainly looks like each class contains only the newly added values/methods. For example the GL44 class contains only a fairly small set of entry points matching new features added in OpenGL 4.4.
Adding a new interface for each version does have advantages:
Existing interfaces are not modified. It is mostly desirable not to modify interfaces once they were publicly exposed. Having various versions of the same interface can be problematic.
It makes it easier for programmers to target a specific OpenGL version, because you can tell which version each entry point is supported in based on the class name.
The downside is that you need to know (or look up) the version where each call was introduced, so that you know which class to use for the call.
I'm surprised that they did not establish an inheritance hierarchy between the classes. That would seem to give the best of both worlds:
Existing class interfaces are not modified when new versions are introduced.
Easy for programmers to target a specific maximum version by using that class.
No need for programmers to take into account the specific version where a call was introduced, as long as it's included in their target version.
This also make conceptual sense, because each version is an extension of the previous version, which matches a subclass relationship. The OpenGL ES Java bindings in Android uses this approach. GLES30 derives from GLES20. Therefore, if you're targeting ES 3.0, you can call all the entry points on GLES30, even the ones that were already present in ES 2.0.
Cocos2d-x 3.0 alpha was released for some time now. What was improved over cocos2dx-2?
The features list is quite important, but in terms of performance are there new limitations/improvements?
Have you noticed real improvements in performance, development patterns, APIs and support?
I've been using it recently and from what I've noticed the main differences are that everything is namespaced now, so you don't have to deal with the prefixed names that came from the objective c patterns, so cocos2d::Point instead of CCPoint (especially for enums, (Texture2D::PixelFormat::RGBA8888 instead of kCCTexture2DPixelFormat_RGBA8888)).
Also some of the event stuff now has support for c++11 lambdas.
A more complete list of the changes can be found here: http://www.cocos2d-x.org/wiki/Release_Notes_for_Cocos2d-x_v300
but for the most part of using it myself, it's just made to feel more like C++, instead of like objective-c.
I have switched and am finding it pretty stable. The main advantages so far ...
Real buttons, instead of menus
Real-time spritesheets
SpriteBatchNodes are no longer recommended and I did see a drop in draw calls where I not optimized
less objective C patterns.
more modern. namespaced instead of 'CC'. C++11.
more platforms supported
Main disadvantages for me:
EventListener pattern. I can't figure out how to get touch input to affect any objects other than the Node that triggered the event.
We use a lot of text-only buttons for debugging and they are hard to lay out :)
Lack of documentation and example code. For example, I could not find any documentation of how to use the Layout class anywhere.
It is a lot of work porting, but for us we had to decided to risk it since we would end up maintaining an out-of-date code base. It took about 5 person-days to port our game over. The game is now stable and we did not run into a single bug in cocos.
I think its C++11
auto
lambda
And it has no unnecessary use of prefix CC
One of the changes that happened between Cocos2d-x 2.1.5 and 2.2 was the removal of templates for projects in XCode (I do not know if project templates existed in VS, etc).
The new build system creates projects under the Cocos2d-x installation (at least on Mac) and that is where the project files appear to reference them. This makes it very difficult to move the project without hand tweaking. It also makes configuration management more painful, depending on how you set up your system (e.g. a root/tree like svn or a "drop it anywhere" like git).
Also, the Cocos2d-x library is built as that, a library. In previous incarnations, it was placed directly into the project. On one hand, if you don't alter the root library code, this makes good sense. On the other hand, if you occasionally tweak things for a specific project, you have altered all your projects that depend on it. Yin/Yang.
I'm still very positive on Cocos2d-x. I have not upgraded to 3.0 or 2.2 yet. When it matures a little more, I will switch over, regardless the changes. For what I need, I'm pretty sure it will still get the job done (well).
what is the meaning of this interfaces? even if we implement an interface on a class, we have to declare it's functionality again and again each time we implement it on a different class, so what is the reason of interfaces exist on as3 or any other languages which has interface.
Thank you
I basically agree with the answers posted so far, just had a bit to add.
First to answer the easy part, yes other languages have interfaces. Java comes to mind immediately but I'm pretty sure all OOP languages (C++, C#, etc.) include some mechanism for creating interfaces.
As stated by Jake, you can write interfaces as "contracts" for what will be fulfilled in order to separate work. To take a hypothetical say I'm working on A and you're working on C, and bob is working on B. If we define B' as an interface for B, we can quickly and relatively easily define B' (relative to defining B, the implementation), and all go on our way. I can assume that from A I can code to B', you can assume from C you can code to B', and when bob gets done with B we can just plug it in.
This comes to Jugg1es point. The ability to swap out a whole functional piece is made easier by "dependency injection" (if you don't know this phrase, please google it). This is the exact thing described, you create an interface that defines generally what something will do, say a database connector. For all database connectors, you want it to be able to connect to database, and run queries, so you might define an interface that says the classes must have a "connect()" method and a "doQuery(stringQuery)." Now lets say Bob writes the implementation for MySQL databases, now your client says well we just paid 200,000 for new servers and they'll run Microsoft SQL so to take advantage of that with your software all you'd need to do is swap out the database connector.
In real life, I have a friend who runs a meat packing/distribution company in Chicago. The company that makes their software/hardware setup for scanning packages and weighing things as they come in and out (inventory) is telling them they have to upgrade to a newer OS/Server and newer hardware to keep with the software. The software is not written in a modular way that allows them to maintain backwards compatibility. I've been in this boat before plenty of times, telling someone xyz needs to be upgraded to get abc functionality that will make doing my job 90% easier. Anyhow guess point being in the real world people don't always make use of these things and it can bite you in the ass.
Interfaces are vital to OOP, particularly when developing large applications. One example is if you needed a data layer that returns data on, say, Users. What if you eventually change how the data is obtained, say you started with XML web services data, but then switched to a flat file or something. If you created an interface for your data layer, you could create another class that implements it and make all the changes to the data layer without ever having to change the code in your application layer. I don't know if you're using Flex or Flash, but when using Flex, interfaces are very useful.
Interfaces are a way of defining functionality of a class. it might not make a whole lot of sense when you are working alone (especially starting out), but when you start working in a team it helps people understand how your code works and how to use the classes you wrote (while keeping your code encapsulated). That's the best way to think of them at an intermediate level in my opinion.
While the existing answers are pretty good, I think they miss the chief advantage of using Interfaces in ActionScript, which is that you can avoid compiling the implementation of that Interface into the Main Document Class.
For example, if you have an ISpaceShip Interface, you now have a choice to do several things to populate a variable typed to that Interface. You could load an external swf whose main Document Class implements ISpaceShip. Once the Loader's contentLoaderInfo's COMPLETE event fires, you cast the contentto ISpaceShip, and the implementation of that (whatever it is) is never compiled into your loading swf. This allows you to put real content in front of your users while the load process happens.
By the same token, you could have a timeline instance declared in the parent AS Class of type ISpaceShip with "Export for Actionscript in Frame N *un*checked. This will compile on the frame where it is first used, so you no longer need to account for this in your preloading time. Do this with enough things and suddenly you don't even need a preloader.
Another advantage of coding to Interfaces is if you're doing unit tests on your code, which you should unless your code is completely trivial. This enables you to make sure that the code is succeeding or failing on its own merits, not based on the merits of the collaborator, or where the collaborator isn't appropriate for a test. For example, if you have a controller that is designed to control a specific type of View, you're not going to want to instantiate the full view for the test, but only the functionality that makes a difference for the test.
If you don't have support in your work situation for writing tests, coding to interfaces helps make sure that your code will be testable once you get to the point where you can write tests.
The above answers are all very good, the only thing I'd add - and it might not be immediately clear in a language like AS3, where there are several untyped collection classes (Array, Object and Dictionary) and Object/dynamic classes - is that it's a means of grouping otherwise disparate objects by type.
A quick example:
Image you had a space shooter, where the player has missiles which lock-on to various targets. Suppose, for this purpose, you wanted any type of object which could be locked onto to have internal functions for registering this (aka an interface):
function lockOn():void;//Tells the object something's locked onto it
function getLockData():Object;//Returns information, position, heat, whatever etc
These targets could be anything, a series of totally unrelated classes - enemy, friend, powerup, health.
One solution would be to have them all to inherit from a base class which contained these methods - but Enemies and Health Pickups wouldn't logically share a common ancestor (and if you find yourself making bizarre inheritance chains to accomodate your needs then you should rethink your design!), and your missile will also need a reference to the object its locked onto:
var myTarget:Enemy;//This isn't going to work for the Powerup class!
or
var myTarget:Powerup;//This isn't going to work for the Enemy class!
...but if all lockable classes implement the ILockable interface, you can set this as the type reference:
var myTarget:ILockable;//This can be set as Enemy, Powerup, any class which implements ILockable!
..and have the functions above as the interface itself.
They're also handy when using the Vector class (the name may mislead you, it's just a typed array) - they run much faster than arrays, but only allow a single type of element - and again, an interface can be specified as type:
var lockTargets:Vector.<Enemy> = new Vector.<Enemy>();//New array of lockable objects
lockTargets[0] = new HealthPickup();//Compiler won't like this!
but this...
var lockTargets:Vector.<ILockable> = new Vector.<ILockable>();
lockTargets[0] = new HealthPickup();
lockTargets[1] = new Enemy();
Will, provided Enemy and HealthPickup implement ILockable, work just fine!
I have a class: DatabaseService.as This class creates a local sqlite connection and creates tables if they do not exist. Connection link will be used by several other classes. Some classes will be called on startup others on user interaction.
"DatabaseService" class dispatches event when database connection is opened. Other classes initialise "DatabaseService" class and awaits for "DatabaseReadyEvent".
This works great but what can I do when I need to call a function/method from the same class several times?
Example:
I create an instance of "PrefService" class in mxml component. "PrefService" creates a new "DatabaseService" class in it's constructor. It then waits for "DatabaseReadyEvent" and executes sql query(this works fine). but then I also need to call "addDir" method (and few others) in "PrefService" class and the sqlConnection property is not set yet causing an error. How can I deal with this? I am new to OOP so I am probably missing something quite simple...
What I've tried / My ideas:
I could check if if sqlConnection exists in "PrefService" class but I think this would be poor practice and still require a delay mechanism of some sort.
I could also create a new instance of "DatabaseService" class for each method and add a new event listener but this would be very cumbersome with 2 functions for each method call not to mention events.
What is the best option in this scenario?
The hate for Singleton is well-deserved. I'd suggest not ever getting in the habit of using it, so you don't have to break that habit when you find how horrible it is to maintain.
Your biggest mistake is having your View creating and executing your service. Unfortunately, this is encouraged by how the FB service generation code works. What you want, instead, is something more like MVCS (Model-View-Control-Service) of the type encouraged by Frameworks like Robotlegs.
To walk through how to go from a tightly-coupled architecture to a loosely-coupled one, start with this example. Note that the Service is a static Class, which pretty much has all the issues as a Singleton as far as encouraging tight coupling. Even though there is only one Class using the Service, imagine what would happen if you have a large project where tens or hundreds of Classes are referencing it. Now imagine something needs to change. Ick.
Now look at the project, refactored so that the View is simply generating an Event that results in calling the service. The service is still static, but in this
case there is exactly one thing that knows about it (Mate), so if you want to make that not static or sometimes use a different service, you easily can, now.
In fact, you can change things around so easily that this is the project, refactored to use Robotlegs. You don't necessarily have to use a Framework, as I did--you can see that the basic structure involved in the core Classes doesn't care a bit about how the Event is being handled or how the data gets into the Views. If you're not comfortable using a Framework, handle it your own way. But Frameworks have been around a while, and they've worked out a lot of issues you haven't thought of yet.
It's tricky to advise without seeing any code, but it might be worth considering making the DatabaseService class a Singleton and initialising it (and the database connection) once as part of your start-up routine (ie. before the classes which use it are instantiated). This would ensure that the classes which use the DatabaseService all share a single connection link to the database, and that the link is available when they come to use it.
Singletons in ActionScript generate a fair bit of debate because in other languages the pattern relies on the ability to set the access modifier of the class constructor as private (which you cannot do in ActionScript 3.0). However, you could choose from a couple of approaches detailed here.
Also, Singletons in general generate a fair bit of debate which might be worth understanding before you use one in anger (since you state you are new to OOP I am assuming you have not done so before).
After reading the nice answers in this question, I watched the screencasts by Justin Etheredge. It all seems very nice, with a minimum of setup you get DI right from your code.
Now the question that creeps up to me is: why would you want to use a DI framework that doesn't use configuration files? Isn't that the whole point of using a DI infrastructure so that you can alter the behaviour (the "strategy", so to speak) after building/releasing/whatever the code?
Can anyone give me a good use case that validates using a non-configured DI like Ninject?
I don't think you want a DI-framework without configuration. I think you want a DI-framework with the configuration you need.
I'll take spring as an example. Back in the "old days" we used to put everything in XML files to make everything configurable.
When switching to fully annotated regime you basically define which component roles yor application contains. So a given
service may for instance have one implementation which is for "regular runtime" where there is another implementation that belongs
in the "Stubbed" version of the application. Furthermore, when wiring for integration tests you may be using a third implementation.
When looking at the problem this way you quickly realize that most applications only contain a very limited set of component roles
in the runtime - these are the things that actually cause different versions of a component to be used. And usually a given implementation of a component is always bound to this role; it is really the reason-of-existence of that implementation.
So if you let the "configuration" simply specify which component roles you require, you can get away without much more configuration at all.
Of course, there's always going to be exceptions, but then you just handle the exceptions instead.
I'm on a path with krosenvold, here, only with less text: Within most applications, you have a exactly one implementation per required "service". We simply don't write applications where each object needs 10 or more implementations of each service. So it would make sense to have a simple way say "this is the default implementation, 99% of all objects using this service will be happy with it".
In tests, you usually use a specific mockup, so no need for any config there either (since you do the wiring manually).
This is what convention-over-configuration is all about. Most of the time, the configuration is simply a dump repeating of something that the DI framework should know already :)
In my apps, I use the class object as the key to look up implementations and the "key" happens to be the default implementation. If my DI framework can't find an override in the config, it will just try to instantiate the key. With over 1000 "services", I need four overrides. That would be a lot of useless XML to write.
With dependency injection unit tests become very simple to set up, because you can inject mocks instead of real objects in your object under test. You don't need configuration for that, just create and injects the mocks in the unit test code.
I received this comment on my blog, from Nate Kohari:
Glad you're considering using Ninject!
Ninject takes the stance that the
configuration of your DI framework is
actually part of your application, and
shouldn't be publicly configurable. If
you want certain bindings to be
configurable, you can easily make your
Ninject modules read your app.config.
Having your bindings in code saves you
from the verbosity of XML, and gives
you type-safety, refactorability, and
intellisense.
you don't even need to use a DI framework to apply the dependency injection pattern. you can simply make use of static factory methods for creating your objects, if you don't need configurability apart from recompiling code.
so it all depends on how configurable you want your application to be. if you want it to be configurable/pluggable without code recompilation, you'll want something you can configure via text or xml files.
I'll second the use of DI for testing. I only really consider using DI at the moment for testing, as our application doesn't require any configuration-based flexibility - it's also far too large to consider at the moment.
DI tends to lead to cleaner, more separated design - and that gives advantages all round.
If you want to change the behavior after a release build, then you will need a DI framework that supports external configurations, yes.
But I can think of other scenarios in which this configuration isn't necessary: for example control the injection of the components in your business logic. Or use a DI framework to make unit testing easier.
You should read about PRISM in .NET (it's best practices to do composite applications in .NET). In these best practices each module "Expose" their implementation type inside a shared container. This way each module has clear responsabilities over "who provide the implementation for this interface". I think it will be clear enough when you will understand how PRISM work.
When you use inversion of control you are helping to make your class do as little as possible. Let's say you have some windows service that waits for files and then performs a series of processes on the file. One of the processes is to convert it to ZIP it then Email it.
public class ZipProcessor : IFileProcessor
{
IZipService ZipService;
IEmailService EmailService;
public void Process(string fileName)
{
ZipService.Zip(fileName, Path.ChangeFileExtension(fileName, ".zip"));
EmailService.SendEmailTo(................);
}
}
Why would this class need to actually do the zipping and the emailing when you could have dedicated classes to do this for you? Obviously you wouldn't, but that's only a lead up to my point :-)
In addition to not implementing the Zip and email why should the class know which class implements the service? If you pass interfaces to the constructor of this processor then it never needs to create an instance of a specific class, it is given everything it needs to do the job.
Using a D.I.C. you can configure which classes implement certain interfaces and then just get it to create an instance for you, it will inject the dependencies into the class.
var processor = Container.Resolve<ZipProcessor>();
So now not only have you cleanly separated the class's functionality from shared functionality, but you have also prevented the consumer/provider from having any explicit knowledge of each other. This makes reading code easier to understand because there are less factors to consider at the same time.
Finally, when unit testing you can pass in mocked dependencies. When you test your ZipProcessor your mocked services will merely assert that the class attempted to send an email rather than it really trying to send one.
//Mock the ZIP
var mockZipService = MockRepository.GenerateMock<IZipService>();
mockZipService.Expect(x => x.Zip("Hello.xml", "Hello.zip"));
//Mock the email send
var mockEmailService = MockRepository.GenerateMock<IEmailService>();
mockEmailService.Expect(x => x.SendEmailTo(.................);
//Test the processor
var testSubject = new ZipProcessor(mockZipService, mockEmailService);
testSubject.Process("Hello.xml");
//Assert it used the services in the correct way
mockZipService.VerifyAlLExpectations();
mockEmailService.VerifyAllExceptions();
So in short. You would want to do it to
01: Prevent consumers from knowing explicitly which provider implements the services it needs, which means there's less to understand at once when you read code.
02: Make unit testing easier.
Pete