Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Barzai

Member Since 20 Jan 2013
Offline Last Active Jan 29 2015 10:24 AM

#5071785 How on earth do I start a game?!

Posted by Barzai on 21 June 2013 - 08:49 AM

Well, I'm not an expert or anything, but here's how I did my first project:

 

Figure out how to put a box on the screen

Figure out how to make that box move based on keyboard inputs

Figure out how to make that box know when it runs into another box (harder than it may seem at first glance)

Figure out how to make a box move on its own

Figure out how to make a box move based on the position of another box

Turn that into pong

 

It's nothing pretty, but it taught me some pretty good basic stuff that you see all the time in games.  Now I can use that stuff when I try to write nicer games.




#5062852 Need advice

Posted by Barzai on 18 May 2013 - 01:18 PM

**Note--I looked back through this, and I'm way off topic for the purpose of this forum, which is breaking into the industry.  If you moderator folks feel I'm too far off, I can edit it all out if you'd like.**

 

Well, I may as well throw a couple of cents in here, hopefully they will also make sense as well.

 

I have an engineering degree, and I'm currently back in school in a post-baccalaureate program in computer science that Oregon State offers.  The reason is that I've found that I don't particularly enjoy the engineering work that I'm doing.  I do seem to really like programming, so I want to make that switch.

 

Don't get me wrong, the engineering work isn't terrible or anything, and it does pay pretty well.  The thing is, like with a lot of jobs I suppose, I spend a lot more time in meetings and shuffling paperwork about than I do actually designing test fixtures and setting up production lines and fun stuff like that.  Now, your mileage may vary, of course.  You could end up in a job in which you don't have as much paperwork overhead and you get to spend more time doing the fun part.

 

From what I can see, it looks like computer science offers a lot more flexibility in your day to day life than engineering does.  This may just be because of where I live (San Francisco bay area), but there is an absolutely huge demand for computer science.  The jobs pay very well, and they exist pretty much all over the place.  If there's a particular place you want to live, there's probably work there in computer science.

 

As far as engineering goes, mechanical would be a good choice because there is a lot of work available.  Electrical also offers a lot of work, and it has overlap with computer science.  When I look at job postings, companies actively attempt to recruit programmers from other areas, and are willing to pay them to relocate in some cases.  That doesn't tend to happen in engineering.  Also, the engineering jobs don't pay more than computer science jobs.  I can't speak to pay rates in game dev computer science jobs, since I'm not in that field, but if you're looking to get a high salary to eventually save enough to start your own business like you say, engineering is not more lucrative than programming.

 

In any case, I'm not sure from your last post whether you're still considering a CS major with a ME minor, or switching to ME entirely.  However, since you already program on the side, it seems pretty apparent that you enjoy it.  If you're looking to switch to ME entirely for the money, I'd reconsider it since it doesn't pay more than computer science.  If you're looking to do a minor, because then you get to learn more physics and engineering and such because it's stuff you really want to know, that sounds entirely reasonable.  However, as others here have pointed out, there's no need to decide that immediately.  You can get into school and experience the workflow there a bit before you really need to make that call.

 

One final note, if you do want to open a studio, there's actually a lot of other knowledge that would be very useful to you.  This is stuff that would happen in the future a bit, but getting an MBA would probably be a wise choice.  There's quite a bit involved in the business side of things that can be easy to overlook but can make your studio fail.




#5045131 appendChild() and removeChild() problems in JS

Posted by Barzai on 20 March 2013 - 09:55 PM

Wow, it's certainly an interesting idea.  I generally make a distinct game object, then use a variable that tells my other code which game object to use, similar to HappyCoder's suggestion, I think.

 

Out of curiosity, when you attempt the change from js1 to js2, exactly how are you doing it?  And, it may be overly simple, but have you tried just changing the newScript.src parameter to game2.js instead of adding and removing children?  Doing that may need some sort of document reload command, though, if it would work at all.

 

If you make this approach with the DOM work, please post your solution.  It would be interesting to see how you went about it.




#5041362 First Game

Posted by Barzai on 09 March 2013 - 09:04 PM

Howdy,

 

The farthest I got was level 9.  I enjoyed it.

 

A level display could help, to let people know how far they along they are.

 

Also, for level 3 you go for a long stretch without any real danger, so if you die later you have to repeat the long stretch without any danger.  Maybe add a ball or 2 early on.

 

Level 8, the background color can make it hard to see the player cube.

 

I like level 5 a lot.  Pretty hard, pretty fun.

 

Out of curiosity, how many levels are there?

 

All in all, a fun game.  I came back 6 or so times to see if I could get farther, so I was hooked obviously.  Good work, I'd say.

 

Cheers




#5039285 How to set a timer in JavaScript?

Posted by Barzai on 04 March 2013 - 07:39 PM

Well, there's one thing I would maybe try.  Your Jet() uses var i, and so does Jet.prototype.collision.  Using the keyword this may be invoking the var i from Jet() instead of the var i from Jet.prototype.collision.  I'd try renaming one of those var i to something else and seeing if it helps.

 

Javascript is kind of weird about scope.  The only time you get a new scope is with a function call.  Loops and other constructs using braces do not automatically generate a scope.  You have a function call which creates a new scope for the collision function, but then the keyword this declares a scope to be used (I think).  Thus, you may be using the Jet() scope var i.

 

I hope that helps.  Otherwise, hopefully one of the more experienced guys will know more.

 

Cheers.




#5035316 Javascript Closures vs. Prototyped Objects

Posted by Barzai on 22 February 2013 - 01:48 AM

So, I've been thinking about this a lot more, and I think I may have finally connected with a fundamental difference between objects and closures that for some reason just didn't click before:

 

Closures have 2 scopes to play with.  They have the outer scope that get closed on, which is the scope I focused on when I thought about them before, but the inner function also has a scope.  So when it gets used, it gets to play with 2 scopes instead of just one, and that allows the simplification of a lot of code.  This may not be exactly accurate (and please, point it out if it isn't), but it looks like using 2 scopes lets you set things that will act as constants at run time in a really simple, tidy way.  There are probably several other uses of having 2 scopes as well.

 

Rereading some of the posts up there, the two scopes thing seems to be implied.  I just didn't quite grab it until now.

 

Now, I've never read any definitions of closures put quite like that before, so I recognize that somehow I may well be getting this wrong again.  Does this, now, seem mostly correct?




#5034272 Javascript Closures vs. Prototyped Objects

Posted by Barzai on 19 February 2013 - 02:51 PM

I've seen a lot of vague stuff about closures in javascript, usually something to the effect of, "closures are powerful, you should learn them."  So, I've done some research into closures, and there's usually a pretty fancy phrase about maintaining a lexical scope after the function call has already returned.  In practical usage, though, it looks like you end up making a thing that has data members and functions that interact with those data members.

 

But wait, data and functions for that data: isn't that just an object?  I never see anyone state that prototyped objects are powerful though, and I've never seen a job listing say that they want applicants that can prototype objects.  As a result I'm trying to get a better handle on the two, and who better to ask than you folks here on gameDev who know a lot about this sort of stuff.

 

There's a post about it here:

http://c2.com/cgi/wiki?ClosuresAndObjectsAreEquivalent

 

Some of the folks oppose closures, but, from what I can see, that opposition doesn't apply to the javascript case.  They say that it creates an overly strong link between the 2 scopes.  However, in the javascript implementation the outer scope stops existing except for in the context of the closure, so it isn't an issue there.

 

 

In any case, from what I can see, It looks like the practical differences come down to this:

 

Closure advantages

 

They are the only way I know of in javascript to actually have private data members.

Javascript is really loose, so you have to pay attention to stuff you wouldn't in other languages, like scope.  Closures let you stop focusing on scope so much, because you define it expicitly when you create the closure.

 

Prototyped object advantages

 

They're faster.  I've seen a couple of references like this one:

http://blogs.msdn.com/b/kristoffer/archive/2007/02/13/javascript-prototype-versus-closure-execution-speed.aspx

Which show that making prototypes is faster than making closures, probably just because you don't have to make new copies of all the functions each time.

 

As a result, it looks like closures are better overall if object creation speed isn't a concern, and prototypes are better if it is.  However, I'm pretty new to this, so I'm probably missing a lot.  Does this analysis look mostly correct?  Are there other elements that come into play that I haven't thought of?  Any thoughts would be aprreciated.




#5034210 Help moving a picture with JavaScript

Posted by Barzai on 19 February 2013 - 11:35 AM

Also, if you'd like to read up more on the type of code that EmployeeNumber8 posted, that was a closure.  Javascript supports closures, and they're quite popular.

 

As far as making your bullets visible, unfortunately I can't help with that.  I haven't used canvas, so any input I give about it would be guessing at best.  I've been making my game images by stacking or arranging solid background color divs.  I know it's kind of silly, but it's a lot of fun so I'm going with it.

 

MDN may have more good input about HTML canvas, though.  It's worth a shot.




#5034015 Help moving a picture with JavaScript

Posted by Barzai on 18 February 2013 - 10:06 PM

When you make your object prototype, use the this keyword to store your passed in parameter as part of your object.  So, your bullet prototype would look more like this:

 

function bullet(startX, startY){

   this.x = startX;

   this.y = startY;

}

 

This link gives a general overview of how OOP in Javascript using prototyped objects works:

https://developer.mozilla.org/en-US/docs/JavaScript/Introduction_to_Object-Oriented_JavaScript

 

I find that MDN is a pretty good resource for javascript, so googling 'mdn javascript [insert whatever you're trying to research here]' gives me good results.

 

Good luck




#5030780 Which prefer layout would help my game canvas?

Posted by Barzai on 10 February 2013 - 01:00 PM

Here's a link to the layout tutorial that the Oracle folks made:

http://docs.oracle.com/javase/tutorial/uiswing/layout/using.html

 

They recommend just using netbeans.  I haven't actually used that yet, so I don't know how effective it is.  Otherwise they recommend grouplayout or gridbaglayout.

 

Personally I've had a lot of luck with BoxLayout.  BoxLayout tends to prefer to support the default sizes of components, so it doesn't do some of the weird resizing things some of the other layout setups do.  To get more intricate layouts, though, you have to make yourself a hierarchical box structure.  That's actually sort of the way I tend to set stuff up when I code javascript as well, though, so it flows pretty naturally for me.

 

Good luck

 

*Edit part*

I just had a thought.  It might work out well for what you're making to just move your UI display stuff into your canvas.  Then you wouldn't need to bother with the layout managers at all.




PARTNERS