|
Thread Rules
1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution.
2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20)
3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible.
4. Use [code] tags to format code blocks. |
On May 28 2014 00:59 supereddie wrote:Show nested quote +On May 27 2014 16:29 Blisse wrote:
can't really post code (not allowed) so i'll try to explain it
basically trying to emulate the dispatching in a switch rather than using a long if statement. the input isn't user defined, but selected from a known dictionary, and the input is runtime dependent.
imagine in a commandline program you could type PULL to call a pullFunction and PUSH to call a pushFunction, while passing in arbitrary container objects. the function could then take the container object and because you called that exact function, cast the contents inside the container object to the proper type. so pullFunction(Container container) will have a method like var pullObject = container.Contents as pullObject. it then passed this object to another library and returns a variable container object with the results of that library call and the description of what the container contains.
i simplified things a bit, there is a lot more logic inbetween and 10-20 different inputs that should be handled. i could always just write an if-statement too, i don't have a specific reason between the two except that this runs faster and the mapping between "PULL" and "pullFunction" is enforced a bit more strictly and visually. So, what I get from this: 1. The functions that are available to the users are known to your program 2. Each function has one argument 3. The return value of each function is known and can be generalized (that is, made the same for all functions) Design an interface, create classes for each function that implement said interface, and create a factory class that creates the function classes. For example:
internal interface IFunction
{
string Execute(object parameter);
}
internal sealed class PullFunction : IFunction
{
public string Execute(object parameter)
{
MyCustomClassForThisFunction c = parameter as MyCustomClassForThisFunction;
if(c == null) return string.Empty;
// do stuff
// return result
}
}
internal interface IFunctionFactory
{
IFunction Create(string functionName);
}
internal sealed class FunctionFactory : IFunctionFactory
{
public IFunction Create(string functionName)
{
switch(functionName.ToUpper())
{
case "PULL":
return new PullFunction();
default:
throw new NotImlementedException();
}
}
}
// In your command handling code, find a way to inject the factory via constructor injection
private readonly IFunctionFactory functionFactory;
return this.functionFactory.Create("pull").Execute(arbitraryContainerObject);
Now you can get cutesy and still have a dictionary mapping a function name to a type in the Factory, without altering the rest of your code:
private readonly IDictionary<string, Type> functionMapping = new Dictionary<string, Type>
{
new KeyValuePair<string, Type>("PULL", typeof(PullFunction))
}
// In Create method
// be sure to check if the key exists etc.
return Activator.CreateInstance(this.functionMapping[functionName.ToUpper()]);
Sidenote: I've been making more factories lately and have become a fan
Be careful about being obsessed over design patterns. The factory pattern is not a appropriate fit for this problem, also the classic factory pattern is quite obtuse, have a look at how ODM's work, they use a much better implementation of the factory pattern.
You do not need a factory to create functions. Functions have their own logic, a factory is not smart enough to create the logic so all it is doing is creating an insertion in the dictionary, hardly useful. Factories are used to facilitate building complex stateful objects, such as instantiating models. You also have a switch statement, which makes the factory redundant. If you are going to use a case-by-case feature for your logic, then you may as well just remove the dictionary altogether.
What you need is reflection, this means you do not need a switch statement, you do not need a dictionary, and you can implement your logic as if it were a normal program.
If you want a good example of the factory pattern, have a look at factory_girl.
http://rubydoc.info/gems/factory_girl/1.3.3/frames
|
On May 28 2014 12:26 sluggaslamoo wrote:
Be careful about being obsessed over design patterns. The factory pattern is not a appropriate fit for this problem, also the classic factory pattern is quite obtuse, have a look at how ODM's work, they use a much better implementation of the factory pattern.
You do not need a factory to create functions. Functions have their own logic, a factory is not smart enough to create the logic so all it is doing is creating an insertion in the dictionary, hardly useful. Factories are used to facilitate building complex stateful objects, such as instantiating models. You also have a switch statement, which makes the factory redundant. If you are going to use a case-by-case feature for your logic, then you may as well just remove the dictionary altogether.
I only gave an example of how it could be done; I never said this was the only way. As always in programming, there are many ways to solve a problem. I just took one and gave some simplified sample code.
'Functions' do not exists, therefore you cannot create them. Everything is a member of some object. I merely moved the corresponding code to their own classes and gave it a common interface.
I think you misunderstand the sample I gave. It is about abstracting away instantiation of concrete types to the factory. The consumer then only uses the interface (as the consumer shouldn't care about the concrete implementation). This improves maintainability, testability, debugging and a lot more.
If you believe factories are only used to 'facilitate building complex stateful objects' and using a switch statement 'makes the factory redundant', you should read up about common OOP priciples, such as encaspulation and polymorphism.
On May 28 2014 12:26 sluggaslamoo wrote:
What you need is reflection, this means you do not need a switch statement, you do not need a dictionary, and you can implement your logic as if it were a normal program.
You don't need to use anything. Use whatever suits your purpose. In this case, I feel reflection is not the right tool. Simply because everything is already known. Therefore you can design your program better, to create a more maintainable, testable and predictable application.
That is just one of the many, many possible implementations of a factory pattern. In fact, it behaves more like an Inversion-Of-Control container than a factory. I see a lot of problems with that one page and it's implementation/usage.
Simply trying to create a unit test for a method that uses that 'factory' would be a pain.
Sidenote: I dislike static members as they can't be mocked for unit testing. Avoid static methods at any cost (but if there is a legitimate reason, go ahead).
|
If you use reflection to implement your factory that's fine. If you use reflection all over your code then that's awful. Reflection should always be tucked away into a vary narrow class. Your actual code should run on proper interfaces.
Also yay for disliking static.
|
Multi-threaded sorting problem;
Here is a working multithreaded quicksort for ArrayLists of Generic <T extends Comparable<T>>. Tested on ArrayList<Integer>s
+ Show Spoiler +
public static <T extends Comparable<T>> void quicksortm(ArrayList<T> list, int from, int to) {
if (list.size() < 90000) {
quicksort(list, from, to);
return;
}
ArrayBlockingQueue<quicksortTask<T>> taskQueue = new ArrayBlockingQueue<quicksortTask<T>>((to - from)/9);
ArrayList<quicksortThread<T>> workers = new ArrayList<quicksortThread<T>>();
int numberProcessors = Runtime.getRuntime().availableProcessors();
for (int i = 0; i < 2 * numberProcessors; i++) {
workers.add(new quicksortThread<>(taskQueue));
}
try {
taskQueue.put(new quicksortTask<>(list, from, to));
} catch (InterruptedException e) {
}
for (quicksortThread<T> worker:workers) {
worker.start();
while (taskQueue.size() < 1) {
}
}
for (quicksortThread<T> worker:workers) {
while (worker.isAlive()) {
try {
worker.join();
}
catch (InterruptedException e) {
}
}
}
}
public static class quicksortThread<T extends Comparable<T>> extends Thread {
ArrayBlockingQueue<quicksortTask<T>> taskQueue;
public quicksortThread(ArrayBlockingQueue<quicksortTask<T>> taskQueue) {
this.taskQueue = taskQueue;
}
public void run() {
quicksortTask<T> task = null;
while (!taskQueue.isEmpty()) {
try {
task = taskQueue.take();
}
catch (InterruptedException e) {
}
quicksortTaskPair<T> qstp = task.run();
if (qstp == null) {
continue;
}
if (qstp.a() != null) {
try {
taskQueue.put(qstp.a());
} catch (InterruptedException e) {
}
}
if (qstp.b() != null) {
try {
taskQueue.put(qstp.b());
} catch (InterruptedException e) {
}
}
}
}
}
public static class quicksortTask<T extends Comparable<T>> {
ArrayList<T> list;
int from;
int to;
public quicksortTask(ArrayList<T> list, int from, int to) {
this.list = list;
this.from = from;
this.to = to;
}
public quicksortTaskPair<T> run() {
if (from >= to) {
return null;
}
if (to - from < 17) {
insertionSort(list, from, to);
return null;
}
T pivot;
T temp;
int pivotIndex = from + (int)((to - from + 1) * Math.random());
pivot = list.get(pivotIndex);
swap(list, pivotIndex, to);
int left = from;
for (int i = from ; i < to; i++) {
temp = list.get(i);
if (temp.compareTo(pivot) <= 0) {
swap(list, left, i);
left++;
}
}
swap(list, left, to);
return new quicksortTaskPair<T>(new quicksortTask<T>(list, from, left - 1), new quicksortTask<T>(list, left + 1, to));
}
}
public static class quicksortTaskPair<T extends Comparable<T>> {
quicksortTask<T> first;
quicksortTask<T> second;
public quicksortTaskPair(quicksortTask<T> first, quicksortTask<T> second) {
this.first = first;
this.second = second;
}
public quicksortTask<T> a() {
return first;
}
public quicksortTask<T> b() {
return second;
}
}
public static <T> void swap(ArrayList<T> list, int i, int j) {
T temp = list.get(i);
list.set(i, list.get(j));
list.set(j, temp);
}
but when I try to switch it to work on int[] arrays, it will hang before it finishes sorting the array. I am not sure why this is so. I only changed ArrayList<T> to int[] and T types to int types where applicable.
Some debugging shows that for sufficiently large lists, all threads will start, many quicksortTasks will execute, but at some point, no quicksortTasks will continue to execute, despite the fact that the taskQueue is not empty.
+ Show Spoiler +
public static void quicksortmu(int[] list, int from, int to) {
if (list.length < 90000) {
sort(list);
return;
}
ArrayBlockingQueue<quicksortTask> taskQueue = new ArrayBlockingQueue<quicksortTask>((to - from)/9);
ArrayList<quicksortThread> workers = new ArrayList<quicksortThread>();
int numberProcessors = Runtime.getRuntime().availableProcessors();
for (int i = 0; i < 2 * numberProcessors; i++) {
workers.add(new quicksortThread(taskQueue));
}
try {
taskQueue.put(new quicksortTask(list, from, to));
} catch (InterruptedException e) {
}
for (quicksortThread worker:workers) {
worker.start();
while (taskQueue.size() < 1) {
}
}
for (quicksortThread worker:workers) {
while (worker.isAlive()) {
try {
worker.join();
}
catch (InterruptedException e) {
}
}
}
}
public static class quicksortThread extends Thread {
ArrayBlockingQueue<quicksortTask> taskQueue;
public quicksortThread(ArrayBlockingQueue<quicksortTask> taskQueue) {
this.taskQueue = taskQueue;
}
public void run() {
quicksortTask task = null;
while (!taskQueue.isEmpty()) {
try {
task = taskQueue.take();
}
catch (InterruptedException e) {
}
quicksortTaskPair qstp = task.run();
if (qstp == null) {
continue;
}
if (qstp.a() != null) {
try {
taskQueue.put(qstp.a());
} catch (InterruptedException e) {
}
}
if (qstp.b() != null) {
try {
taskQueue.put(qstp.b());
} catch (InterruptedException e) {
}
}
}
}
}
public static class quicksortTask {
int[] list;
int from;
int to;
public quicksortTask(int[] list, int from, int to) {
this.list = list;
this.from = from;
this.to = to;
}
public quicksortTaskPair run() {
if (from >= to) {
return null;
}
int pivot;
int temp;
int pivotIndex = from + (int)((to - from + 1) * Math.random());
pivot = list[pivotIndex];
swap(list, pivotIndex, to);
int left = from;
for (int i = from ; i < to; i++) {
temp = list[i];
if (temp < pivot) {
swap(list, left, i);
left++;
}
}
swap(list, left, to);
return new quicksortTaskPair(new quicksortTask(list, from, left - 1), new quicksortTask(list, left + 1, to));
}
}
public static class quicksortTaskPair {
quicksortTask first;
quicksortTask second;
public quicksortTaskPair(quicksortTask first, quicksortTask second) {
this.first = first;
this.second = second;
}
public quicksortTask a() {
return first;
}
public quicksortTask b() {
return second;
}
}
public static void swap(int[] list, int i, int j) {
int temp = list[i];
list[i] = list[j];
list[j] = temp;
}
|
|
|
I'm just throwing together the basis of converting my visual novel to OOP Flash AS3... If you're a Flash/OOP pro and have the time feel free to take a look and comment on this structure while I sleep.... 
+ Show Spoiler +![[image loading]](http://i.imgur.com/vb4kXyD.jpg) a) I have dialoguebox and textbox separate because i think i'll need them to act separately e.g. the dialoguebox doesn't close exactly the same time as the textbox will close. b) In the diagram i am not showing button functionality e.g. clicking on dialoguebox will progress the text/scene, clicking on options button will store the choice and progress the scene... i'm not sure if i'm supposed to show these things in this diagram? the nature of Flash is confusing me i think, coz these are like inbuilt functions..... how will i be doing these things? some scene attributes will be pre-set so i guess it will look like.....
displayScene(scene1)
scene1.displayCharacterLeft
scene1.displayCharacterRight
scene1.displayDialogueBox
scene1.displayDialogueText("Yuki: Hi, I'm Yuki")
scene1.displayDialogueText("Gendo: Hello Yuki")
scene1.displayOptionBox
scene1.displayOptions
eventListenerOnClick ->setOptionTrue, hideOptions, displayDialogueText("Nice choice")
endScene(scene1)
displayScene(scene2)
do i want to type out all my game dialogue in the main class rather than in a scene? (i think i do)
maybe someone can simplify the way i should think about this...
disclaimer: i would be doing some bloody flash youtube tutorials but my router broke in a storm and i can barely load youtube at 5k/s on mobile net
screenshot of the game (failed prototype version) ![[image loading]](http://i.imgur.com/4MrZF8G.jpg)
|
On May 29 2014 01:10 supereddie wrote:Show nested quote +On May 28 2014 12:26 sluggaslamoo wrote:
Be careful about being obsessed over design patterns. The factory pattern is not a appropriate fit for this problem, also the classic factory pattern is quite obtuse, have a look at how ODM's work, they use a much better implementation of the factory pattern.
You do not need a factory to create functions. Functions have their own logic, a factory is not smart enough to create the logic so all it is doing is creating an insertion in the dictionary, hardly useful. Factories are used to facilitate building complex stateful objects, such as instantiating models. You also have a switch statement, which makes the factory redundant. If you are going to use a case-by-case feature for your logic, then you may as well just remove the dictionary altogether.
I only gave an example of how it could be done; I never said this was the only way. As always in programming, there are many ways to solve a problem. I just took one and gave some simplified sample code. 'Functions' do not exists, therefore you cannot create them. Everything is a member of some object. I merely moved the corresponding code to their own classes and gave it a common interface. I think you misunderstand the sample I gave. It is about abstracting away instantiation of concrete types to the factory. The consumer then only uses the interface (as the consumer shouldn't care about the concrete implementation). This improves maintainability, testability, debugging and a lot more. If you believe factories are only used to 'facilitate building complex stateful objects' and using a switch statement 'makes the factory redundant', you should read up about common OOP priciples, such as encaspulation and polymorphism. Show nested quote +On May 28 2014 12:26 sluggaslamoo wrote:
What you need is reflection, this means you do not need a switch statement, you do not need a dictionary, and you can implement your logic as if it were a normal program. You don't need to use anything. Use whatever suits your purpose. In this case, I feel reflection is not the right tool. Simply because everything is already known. Therefore you can design your program better, to create a more maintainable, testable and predictable application. That is just one of the many, many possible implementations of a factory pattern. In fact, it behaves more like an Inversion-Of-Control container than a factory. I see a lot of problems with that one page and it's implementation/usage. Simply trying to create a unit test for a method that uses that 'factory' would be a pain. Sidenote: I dislike static members as they can't be mocked for unit testing. Avoid static methods at any cost (but if there is a legitimate reason, go ahead).
http://en.wikipedia.org/wiki/Argument_to_moderation
There is usually a best way of doing something. In this case, reflection makes the most sense.
The factory pattern you used is outright redundant. You are creating a whole new base class for something that can already be done very simply.
http://en.wikipedia.org/wiki/You_aren't_gonna_need_it
I don't think you understand design patterns, you wanna use the factory pattern because it is very simple and easy to understand, that doesn't mean its useful.
Look at factory_girl, that is how you should use the factory pattern, not the way the gang of four described, that is unless you want to work on legacy code in C++ and they are indeed creating complex stateful objects for a single class.
A better fit would be through the use of the double-dispatch pattern and strategy or adapter patterns. However these are still unnecessary when you have reflection. If you do not have reflection, you would use the strategy pattern. The double-dispatch would be used for the case-by-case with different models.
Encapsulation and polymorphism has absolutely nothing to do with this. I think it is you that needs to work on your OOP.
|
On May 29 2014 11:51 FFGenerations wrote:I'm just throwing together the basis of converting my visual novel to OOP Flash AS3... If you're a Flash/OOP pro and have the time feel free to take a look and comment on this structure while I sleep.... + Show Spoiler +a) I have dialoguebox and textbox separate because i think i'll need them to act separately e.g. the dialoguebox doesn't close exactly the same time as the textbox will close. b) In the diagram i am not showing button functionality e.g. clicking on dialoguebox will progress the text/scene, clicking on options button will store the choice and progress the scene... i'm not sure if i'm supposed to show these things in this diagram? the nature of Flash is confusing me i think, coz these are like inbuilt functions..... how will i be doing these things? some scene attributes will be pre-set so i guess it will look like.....
displayScene(scene1)
scene1.displayCharacterLeft
scene1.displayCharacterRight
scene1.displayDialogueBox
scene1.displayDialogueText("Yuki: Hi, I'm Yuki")
scene1.displayDialogueText("Gendo: Hello Yuki")
scene1.displayOptionBox
scene1.displayOptions
eventListenerOnClick ->setOptionTrue, hideOptions, displayDialogueText("Nice choice")
endScene(scene1)
displayScene(scene2)
do i want to type out all my game dialogue in the main class rather than in a scene? (i think i do)
maybe someone can simplify the way i should think about this...
disclaimer: i would be doing some bloody flash youtube tutorials but my router broke in a storm and i can barely load youtube at 5k/s on mobile net
screenshot of the game (failed prototype version)
Well its not really OOP, its much more procedural. That doesn't mean its a bad thing, but if you wanna do OO then you will have to think differently.
Basically when thinking about OO you have to think about the taxonomy. Each object must be responsible for itself.
For example, a scene will have many characters. Each character should be responsible for its own display method.
So rather than scene1.displayCharacterLeft
It should be, scene1.left_character.show or visible = true
The scene should be rendering all the characters at once, and the characters should on their own be able to decide whether to be rendered or not.
Same for the GUI components. While the scene contains the GUI components, it should not be responsible for handling the components themselves, the components themselves will have x/y coordinates and be visible or not on their own.
There should probably be an overlay component to contain all the UI, and the scene should be on its own underneath the overlay. Then you should have a controller which handles things like animation such as when the overlay needs to be hidden for specific scenes. The controller would take a list of actions so it knows how to do a full scene animation. Something like that.
|
Czech Republic4646 Posts
I was wondering how the encapsulation and polymorphism even came up as they have nothing to do with the issue you are discussing.
Anyway factory pattern seems completely unnecessary. Having 10 levels of useless abstractions is not always sign of good solution
Without knowing more specifics it is hard to propose ideal solution, but you can go the string -> function route, but then just have simple function with a switch, factory is of no benefit. Reflection is also easily possible, C# has good enough support for that. Invoke should solve the issue if I understood it correctly.
|
I've found the factory pattern quite useful in conjunction with the decorator pattern. Abstracting out the declaration of objects into one location where I'm free to extended with decorators is quite handy.
I would agree that having too many abstractions may not be necessary, but it's really useful in Unit Testing. Having everything abstracted allows you to mock everything you need to isolate a specific set of logic in a way that would otherwise be difficult with concretes.
|
On May 30 2014 00:45 enigmaticcam wrote:
I've found the factory pattern quite useful in conjunction with the decorator pattern. Abstracting out the declaration of objects into one location where I'm free to extended with decorators is quite handy.
I would agree that having too many abstractions may not be necessary, but it's really useful in Unit Testing. Having everything abstracted allows you to mock everything you need to isolate a specific set of logic in a way that would otherwise be difficult with concretes.
Again just be really careful about being overly obsessive about the gang of four design patterns. Saying "the factory pattern is quite useful in conjunction with the decorator pattern" is just a really strange way of thinking about programming. Saying your solution is to use the factory pattern just sounds really weird, because the factory pattern is a re-factorizing pattern, it can't actually solve any problems on its own.
Design patterns aren't silver bullets, and these days they are simply there to provide information. In the same way that you are trying to talk about "having everything abstracted" which is really just called functional or object decomposition.
So in that way, I would just tell the person to look at Dijkstra's principles of structured programming or responsibility driven design (for OOP). Its the same as when I tell someone to look at a design pattern, its so I don't have to explain the whole thing.
The main issue with your use of the factory pattern is that its not an abstraction, its just a class which holds the original class's constructor logic. This is why I showed you factory_girl, in that the gang of four factory pattern is not a very good example of the factory pattern and a lot of people get the wrong idea.
A real gang of four factory pattern is able to create a lot of different instances of the same type for a really complex stateful object which would be either really messy or even impossible to write in the constructor. Unless we are working with really old monolithic projects you should never see the factory pattern used in this way.
For smaller projects you want a really dynamic, reusable factory library, and because they already exist, if you want to use the factory pattern, simply use the libraries and save yourself (and everyone else) the pain.
Also be wary about creating abstractions which involve big vertical hierarchies, they will always cause a lot of headaches in the long run. Vertical hierarchies will always cause fragility, Java's stack class is a great example of why their old principle of inheritance was bad and why someone had the knee-jerk reaction of having lots of interfaces instead (which is just as bad).
There is nothing wrong about having lots of concrete classes. Decomposing your program into lots and lots of concrete classes is still abstraction and is much better than having lots of coupled classes layered over each other purely for the sake of "abstraction" and inheritance.
Doing things for the purpose of adhering to "patterns" and "proper design" rather than just solving the problem can often be a silly way of thinking and will often just make you waste time and make the program more fragile and harder to understand than intended.
|
|
|
On May 30 2014 11:49 sluggaslamoo wrote:Doing things for the purpose of adhering to "patterns" and "proper design" rather than just solving the problem can often be a silly way of thinking and will often just make you waste time and make the program more fragile and harder to understand than intended. While I agree with the part about doing things just because they're the accepted "pattern" or "proper design", that's not why I do them. Properly implemented, they do in fact solve a problem (to an extent): the problem of designing code that's maintainable, flexible, and scalable. But of course, there are any number of ways to do this. The Factory pattern is one way, and it's there for anyone to use if they think it makes sense for their program. If you think your way is better, that's fine. But I think it's a bit silly to dismiss it entirely.
|
for newbie programmers and for tutors
i'm half way through this tutorial on basic programming via demonstration in Flash AS3
its fucking BRILLIANT tutorial
you can start at OOP introduction 1 if you're familiar with programming concepts but will need to go back to the very start after that to get familiar with other basics in Flash
it first shows you how to construct a Flash button as a class and then instantiate buttons using your main document class
this is fucking brilliant way of explaining OOP by practical demonstration. its exciting because you know you can apply it to make your own games once you figure it out.
i cant wait to finish this tutorials!!!
http://code.tutsplus.com/series/as3-101--active-7395
ps: thanks for your comment earlier on my problem sluggaslamoo. as you can see i am looking at this tutorial which will help clarify a lot of things i was beginning to query e.g. what a button actually does lol. also as i go back in the tutorial and look at arrays it makes me wonder how i am going to present the mass of dialogue text in the game, whether i want to set it up so i can have lines and lines of
char1 says text
char2 says text
char1 says text
char1 says text
or if there might be a dif way like
print array1.1
print array1.2
print array1.3
idk i need to finish tutorial lol
i wonder if you can make a living making Flash rpgs (this is what i want to do with my life)
|
On May 31 2014 09:23 FFGenerations wrote:for newbie programmers and for tutorsi'm half way through this tutorial on basic programming via demonstration in Flash AS3 its fucking BRILLIANT tutorial you can start at OOP introduction 1 if you're familiar with programming concepts but will need to go back to the very start after that to get familiar with other basics in Flash it first shows you how to construct a Flash button as a class and then instantiate buttons using your main document class this is fucking brilliant way of explaining OOP by practical demonstration. its exciting because you know you can apply it to make your own games once you figure it out. i cant wait to finish this tutorials!!! http://code.tutsplus.com/series/as3-101--active-7395ps: thanks for your comment earlier on my problem sluggaslamoo. as you can see i am looking at this tutorial which will help clarify a lot of things i was beginning to query e.g. what a button actually does lol. also as i go back in the tutorial and look at arrays it makes me wonder how i am going to present the mass of dialogue text in the game, whether i want to set it up so i can have lines and lines of char1 says text char2 says text char1 says text char1 says text or if there might be a dif way like print array1.1 print array1.2 print array1.3 idk i need to finish tutorial lol i wonder if you can make a living making Flash rpgs (this is what i want to do with my life)
Here's an example.
In your scene controller, you would submit an "action list" to it.
An action List takes a list of actions.
An Action takes a character, delay, duration, animation, text, and character_frame. Any of these can be not set, which causes the scene controller to not bother with that aspect.
The character is the character instance so you can get the name and other fields you need, the delay is how long the action takes to begin, duration would be duration of the animation (with a default of 1 second lets say), animation is slide in slide out stuff, if text is there it will be shown, character_frame would correspond to a particular emote the character needs to use.
Your scene controller would go through the list of actions, from top to bottom. It would take both click and duration triggers to trigger the next action until all actions are complete and the scene is over.
|
ah man that is like describing sex to a virgin
get back to you !
|
nice now my mom is super pissed off coz i got drunk for the first time in 1-2 years
she is like U HAVE MANY PROBLEMS WHEN I COME BACK FROM HAIRDDRESSER WIE WILL HAVE TO TALK
r u kidding me i just want to sing some anime songs and go to sleep wtf jesus christ
|
On May 31 2014 17:00 FFGenerations wrote:
nice now my mom is super pissed off coz i got drunk for the first time in 1-2 years
she is like U HAVE MANY PROBLEMS WHEN I COME BACK FROM HAIRDDRESSER WIE WILL HAVE TO TALK
r u kidding me i just want to sing some anime songs and go to sleep wtf jesus christ
fucking parents man
|
On May 31 2014 09:23 FFGenerations wrote:
its fucking BRILLIANT tutorial
Make sure you don't read this one tutorial and then think you know everything. Learn from multiple sources and critically question each one. Internet tutorials are not something you should blindly depend upon. Neither is any other single source.
|
On May 31 2014 17:16 spinesheath wrote:Make sure you don't read this one tutorial and then think you know everything. Learn from multiple sources and critically question each one. Internet tutorials are not something you should blindly depend upon. Neither is any other single source.
What about college/university?
|
|
|
|
|
|
EPT
