Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 31 Oct 2012
Offline Last Active Today, 06:13 AM

Posts I've Made

In Topic: Starting Point For Game Development as a Career

02 May 2016 - 06:54 PM

I would suggest just making games. Test your skills with those tools to make a small game from start to finish; focus on the aspects that you'd want to showcase to an employer (do you want to be an artist? make the art stand out!).


Each position you apply for is going to want different things, but most of them don't want just "experience with x", they want "experience developing with x" (meaning working on a project as a whole, and often time shipping the project).


The absolute most surefire way (that may be an exaggeration) to find out what you need to do to get a job in game development is to look at job-postings (there are a lot of game-dev jobs posted on job boards on the internet) and look at what they want.

In Topic: Help with game loop time control

28 April 2016 - 10:10 AM

A common method of achieving constant-rate logic updates (independent of rendering speed) is the fixed-timestep gameloop. This is an effect you can also achieve by enabling vsync (though this is generally not recommended).


In C#, to get the precise timing you'd want to implement a fixed-timestep you're probably going to have to use System.InteropServices to import some dlls to enable you to check the cpu tick-rate.

In Topic: Implamenting a code

28 April 2016 - 06:43 AM


What have you tried? Using a popular search-engine I found this set of tutorials (first thing it returned) for, what appears to me, your exact dilemma, but if you want to figure it out with a little less guidance, then asking more specific questions and telling us what has and hasn't worked for you is going to help us best help you.


For starting out, and for creating a simple game like Pong, it is best if one doesn't directly go for tutorials.

He should instead spend at least some hours on pen/pencil and paper trying to figure out how his game would work.


I didn't mean to imply that following a tutorial was the best idea. I was just providing options (and suggesting that there are existing answers to a lot of questions).

In Topic: Implamenting a code

27 April 2016 - 03:31 PM

What have you tried? Using a popular search-engine I found this set of tutorials (first thing it returned) for, what appears to me, your exact dilemma, but if you want to figure it out with a little less guidance, then asking more specific questions and telling us what has and hasn't worked for you is going to help us best help you.

In Topic: My understanding for developing a video game, can I get some insight?

27 April 2016 - 11:07 AM


Both western languages, countries pretty much next to each other, should be alright.

Now try to translate a language of the Eskimos to a language near the equator, say Mexicans. Eskimos have a huge number of words for 'snow' https://www.princeton.edu/~browning/snow.html A concept alien to Mexicans. Already in English, you'll have major trouble doing the translation, as you simply cannot express every subtlety of the Eskimo snow words.
No matter how hard you try, it won't fit. In addition, any English reader will fail to understand the meaning that an Eskimo intends. The reader simply does not have a matching conceptual frame.

Computer languages are not different. Prolog can only reason about facts and relations, how to put an imperative object-oriented program in there? The concept "assignment" is already alien in it.
I don't see how that counts as "easily transferred".

Similarly, Lua has co-routines, how are you going to "easily transfer" that to assembly language?

I am not saying it can't be done, but I doubt that in general you can make easy transfers. If you can you're lucky, but it's equally possible that the semantic foundation of two languages are so different that it is better to start anew rather than trying to transfer your original idea.


So how do you think these languages work? Each language translate to what the computer understand. I'm not saying noise is language instead when you imply rules to noise you could create language because the rules would transform into some meaning. Every language is translatable that doesn't mean its a one to one translation. One concept that will blow your mind is the ideal that subtraction can be done with just add operation. The ideas are basic things you want to convey. You can should be easily able to translate. Also you mentioned Functional vs OOP here you going on a tangent OOP is not a language but the rule on how to use a given language same with Functional. For instance Procedure vs OOP, C is procedural and C++ is OOP but if one looks closely one can see that you can still implement the same program in any of the two languages. However, C++ might make it easier for some problems. Functional languages are built around solving a problem on the ideal of functional tuning. This isn't to say that procedural programmer can not learn the language and not be able to solve the problem procedurally. They could also learn an opposite program tackle it from another prospective. Prospective is what you having problems with and that is common because some people can see the smaller points and not the larger picture. If you study language you will soon see the whole picture of both small sub parts and large parts. As human continue to invent one must say how was it done in the past. We see that we hardly ever invent thing that bring new concepts not tried. We have cell phones but we can trace back to telephone then telegram and so on.


I'm going to say that a library is not the language you miss understanding what is language and what is created by the language. The language is the things that is allowed to be correct. the statements, the creation of variables, and other features.


CFG is how the language is parsed while this is what the compiler does but what else does the compiler do? It translates. CFG stands for context free grammar not all language are context free. But the cfg will make up the language. Lets look at English what constructs a simple sentence? Subject verb object. But you should ask what makes these parts different and there lies things called grammam rules.


On the one hand, I think that you're more or less correct, that you can technically write a program in one language and approximately port it to another language (there are probably exceptions to this, but it's not something I've looked deep into, so any clarification or examples of exceptions would be appreciated). BUT that does not mean that it will work in the same way or have anything resembling a similar layout or architecture. I think if you consider it more close to translating between a language like English and a tonal language like Mandarin, such that one phoneme can have multiple meanings based on the intonation. Yes, you can technically translate between the two, but the translator must have a mastery of both language-styles (tonal and... atonal?) to do so. As such, this is a non-trivial task.


You originally suggested that the translation from one language to another is primarily syntactic, which is where you are less correct. While syntax does differ between languages, many other aspects differ to an equal or greater degree. To assume that rosettacode can substitute practice and experience with a given language is farcical.


Edit: what happened to selective quotes?