What language should i use to make little games? like a language that is easy to make games for.
Printable View
What language should i use to make little games? like a language that is easy to make games for.
Depends on what you mean by "little games".
Text-based games? Almost any language will do, although a simple scripting language or something that offers a nice text manipulating library would probably be nice.
Perhaps 2D games? This is personal preference depending on a few things. If you're not very good at memory management and never remember to free() what you malloc() or delete/delete [] what you new, a languague like Java might be easier to work with if you're interested in focusing on concepts as opposed to language details. Java, though, suffers from a lot of setbacks, so it's trade off.
If you can take care to clean up memory, and pointers and such are not a hard concept for you to understand, then both C and C++ are well able to do what you need, although I would recommend using some library like SDL or Allegro if you go that route.
Why would you ask this on a board devoted to the C/C++ language?
Perhaps you already know the answer.
Experiment around with different languages until you find one you like. That's what I did and why I picked C++. I just couldn't get used to any other language.Quote:
Originally Posted by roobert
If you have some programming experience but not much, but would like to create a game simply and quickly. Then Java is a good place to start, as it will allow you to get into programming and hide some of the complexity like memory management. Although you can play about with the garbage collector or force it, but that’s not important to you. I re-created the Mega-Drive computer game Streets of Rage 2 in Java, work great. Did it for my final year project at UNI. Plus java is fun.
Most common:
[Language] C++/Delphi/Pascal/Python [Library/Technique] Console/DirectX/OpenGL/SDL
Plus mostly for web:
Java
Flash
You can't force the GC, at best you can hint it (and doing so is usually counterproductive in that it forces the GC to (if it runs on the hint at all) perform a full GC cycle rather than an incremental GC cycle, consuming unnecessary CPU cycles, and can be forcibly ignored through JVM configuration).Quote:
Originally Posted by mmarab
Just about the only time you may want to do that is when you have an application that you know will require a lot of memory for a longrunning operation. Just before consuming that memory you might want to try and get the GC to run so you have as much free RAM as possible, hopefully reducing GC overhead during that expensive operation.
It is, and productive as well.Quote:
Originally Posted by mmarab
Indeed. I have software I'm developing in Java that I wanted to take advantage of some.... -- perhaps I could call them "bizarre features" since they might be better implemented in a different way -- that require garbage collection. I find it annoying that I can't manage memory myself in Java, and I can only ask for the cleanup to possibly, maybe, perhaps, be attempted.Quote:
Originally Posted by jwenting
If Java had a way to manually delete an object, that would be nice.
I have to say, though, everytime I've asked the system to perform a garbage collection, it's appeared to work, and the necessary objects/classes appeared to be unloaded. I know this should not be relied upon, but I figure if it works... hey it works. If it doesn't, then it doesn't.
Example of kind of forcing garbage collection but using runtime: But i agree, using something like System.gc() is just a hint, and it does not guarantee immediate action, but actually it could slow your app down. :(
Code:/*
* This Java program shows you how to force garbage collection
* Author: Megh Thakkar
*/
public class CollectGarbage {
int ASIZE = 1000000;
void useMemory() {
int[] intA = new int[ASIZE];
for (int i=0; i<ASIZE; i++) {
intA[i] = i*2;
}
}
public static void main (String[] args) {
CollectGarbage gct = new CollectGarbage();
// Get a Runtime object
Runtime r = Runtime.getRuntime();
// Collect garbage at the start of the program
r.gc();
// Let's see how much memory we have at the start
long availMem = r.freeMemory();
System.out.println("At program start we have : " + availMem + " bytes");
// Let's use some memory
gct.useMemory();
// Let's see how much memory is left
long availMem1 = r.freeMemory();
System.out.println("After running the program,
we have : " + availMem1 + " bytes");
// Collect garbage
r.gc();
//Let's see what we have now
long availMem2 = r.freeMemory();
System.out.println("After collecting garbage
we have : " + availMem2 + " bytes");
long freedMem = availMem2 - availMem1;
System.out.println("Garbage collection
freed : " + freedMem + " bytes");
}
}
I've been working professionally in Java for almost a decade and never missed the ability to explicitly handle memory...
The reason why calling Runtime.gc() slows down your system (usually momentarilly) is the heavy operation it triggers (if it triggers anything of course).
When letting the JVM do its own thing it runs at a constant trickle in the background, consuming only spare CPU cycles when it can and not pushing itself into the limelight unless it has to.
You can do the same under C++. You just either have to find a garbage collector library or code your own.Quote:
Originally Posted by mmarab
http://www.hpl.hp.com/personal/Hans_Boehm/gc/
http://www.devarticles.com/c/a/Cplus...r-C-plus-plus/
but why go to the trouble when Java has one built in as standard that just works? :)
use macromedia flash, it has an OOP oriented IDE and such, blabla. :-) tons of tutorials, etc etc... most games around the net are flash or shockwave so you see it's popular.
ActionScript is pretty much JavaScript just OOP and added language features.
It's far simpler than doing such a project with the same potential in c++ without the extra work. Flash can hand all sorts of audio files for you, and all that mess. You really just focus on game logic in Flash, you also should be patient with flash, it has a learning curve as well.
flash also has 3d capabilities, so you can display models and adjust the camera, etc....
Java won't look or work as nice as flash apps right away*, both java and c++ applications will require an obscene amount of "messaging" just to -render- the graphics as flash already does.
in flash you just worry about putting all the resources together, and as i said, game logic.
I agree. I've seen many simple flash games.Quote:
use macromedia flash,
if you look at modern games like forza motorsports 2 on the 360. what language is that made in, does anyone have any ideas
it really doesn't matter too much what language a game was made in... you can recreate it in any other language. just saying.
(in some cases with very varied results... but yea)
If you cannot manage memory:Quote:
If you have some programming experience but not much, but would like to create a game simply and quickly. Then Java is a good place to start, as it will allow you to get into programming and hide some of the complexity like memory management.
- You shouldn't be programming
- You shouldn't be programming a game
So many want to skip the fundamental steps and just jump right into game programming or just programming in general. Skipping steps like memory management may get the job done faster but in the end you are still clueless and have not become anything close to a good programmer. Don't short circuit the learning process by selecting a language that allows you to get away with murder or get used to extremely bad habits. I don't even think Java was designed for people looking to get away from the idea of memory management but sadly that has been it's main attracting point.
It's like driving a car down the road. Yes you can drive from A to B but if anything goes wrong with the car you are absolutely clueless as to how to fix it. This is fine if you are just interested in driving the car. When you are programming you are NOT the driver. You are the mechanic. Do you want a mechanic who is clueless working on your car? Do you want a programmer who is clueless programming your next game?
Memory management is an absolutely essential skill for game programmers. A game is all about data and tons of it. If you cannot manage the data efficiently then you don't have a game - you have a really cool slide show that will eventually crash.
Not true. You can attempt to recreate the game in another language but you will not get the same exact results because not all languages are alike. And languages are designed to address very different programming concerns.Quote:
it really doesn't matter too much what language a game was made in... you can recreate it in any other language. just saying.
(in some cases with very varied results... but yea)
More than likely these are coded with C/C++ combined with native assembly language for the 360. Memory management on these types of systems is so crucial that the manager probably gets a very good dedicated programmer for this task. Memory is not as abundant on these systems and hard drives are not as fast as they are on the PC - and perhaps the DVD drive is not as fast as some on the PCs. Due to these constraints you will find very few games that are exactly similar to their PC counterparts. This is also good marketing since the PC owner may already own the game on the PC so why would he/she buy it for the console? By changing the story lines or changing the gameplay the game can be enjoyed both on the PC and the console.Quote:
if you look at modern games like forza motorsports 2 on the 360. what language is that made in, does anyone have any ideas
Which in the end leaves you clueless about actually programming a game. I've not seen any flash games that I was all that impressed with. Most look like fancy versions of old Atari 2600 games. Not anything to write home about.Quote:
use macromedia flash, it has an OOP oriented IDE and such, blabla. :-) tons of tutorials, etc etc... most games around the net are flash or shockwave so you see it's popular.
ActionScript is pretty much JavaScript just OOP and added language features.
It's far simpler than doing such a project with the same potential in c++ without the extra work. Flash can hand all sorts of audio files for you, and all that mess. You really just focus on game logic in Flash, you also should be patient with flash, it has a learning curve as well.
flash also has 3d capabilities, so you can display models and adjust the camera, etc....
Java won't look or work as nice as flash apps right away*, both java and c++ applications will require an obscene amount of "messaging" just to -render- the graphics as flash already does.
in flash you just worry about putting all the resources together, and as i said, game logic.
The memory footprint for the JVM is absolutely insane. So essentially what you are saying is that Java frees memory when and if it wants to? Not exactly good inside of a pre-emptive multitasking system eh? Java is good for what it was designed for. It is caca for games.Quote:
I've been working professionally in Java for almost a decade and never missed the ability to explicitly handle memory...
The reason why calling Runtime.gc() slows down your system (usually momentarilly) is the heavy operation it triggers (if it triggers anything of course).
When letting the JVM do its own thing it runs at a constant trickle in the background, consuming only spare CPU cycles when it can and not pushing itself into the limelight unless it has to.
If you want to program games then use C/C++ and a graphics library of your choice. Excuses like 'C/C++ takes so many lines of code to do this or that...' are just not valid in my book. So you want to program games but you don't want to code a lot? Laziness is a horrible reason for choosing a language or not choosing one.
Which is your book?
He/she wanted to make a little game!! That is easy to make games for!!! Dont make everything so serious Bubba! Its supposed to be fun!Quote:
Originally Posted by roobert
Easy little games eh. Ok.
1. Games are not easy programming.
2. If you are looking for easy, don't program games.
I don't like the quick fix attitude and while this may work for tic tac toe....it won't work for other projects.
I agree games are complex to program and its not an easy task. I'm not disagreeing with you.
All I’m saying is that some people don’t wont to code the next Halo or Forza Motor Sport etc. They just want to have a bit of fun and make some simple little games. If they then in the future want to get more serious about it, they will need to learn the hardcore stuff. But don’t make it sound so serious; games are fun, that’s why people play them. Even if it is Tic Tac Toe.
Playing them, yes. Creating them is not always 'fun'. The end result should be fun but creating them and the algorithms that power them is not always super uber 'fun.' Sometimes it's downright difficult and frustrating.Quote:
But don’t make it sound so serious; games are fun, that’s why people play them.
Hell there are times when I don't even want to touch my game code because it's not always 'fun.' More like 'work.'
learning it is fun.
And I visit a site of simple games created with flash and the like that are really well made and could easily be ported to XBLA or PSN, and some of which were made in a deadline for contests and such, so I don't dismiss small games just because they aren't as hard to make as easy ones. check out jayisgames.com. Some people only ever program games in flash, and look at all the sites that are dedicated to them. I like big adventurous and epic games, but in my long history in playing games they don't always work out, leaving the developers unheard of until their next iteration which may or may not do better. Hell, look at David Jaffe's example. He left Sony to start a small games company because his games he felt didn't match up to the effort put in them.
Quote:
Which in the end leaves you clueless about actually programming a game. I've not seen any flash games that I was all that impressed with. Most look like fancy versions of old Atari 2600 games. Not anything to write home about.
ok bubba, maybe the point is to write simple games, and yes you learn OOP programming and it's easier to use than any other language especially for someone who doesn't really care about anything but writing *simple games*.
on top of all this you obviously don't know much about game programming if you think a game has to look like real life to be worth making... learn some game theory. all games are based on mathematical models which can be implemented in ANY WAY.
old atari games have persisted to today, just new skins and new looks. no game is bad because of its simplicity.
and just because 90% of flash developers suck doesn't mean flash sucks for making games, what you see and what is possible are two different things. flash is fine especially when you create client side executables, it works just fine. maybe not on linux.
but maybe you missed the part where the thread starter isn't very experienced, and even a simple game -comparable- to flash would take SO MUCH LONGER to make. the point is he wants to make games, not spend his life as a c++ programmer, that's what I got from him anyway.
flash is perfectly ok, trust me, don't listen to the guy that doesn't know what he's talking about. unless you have a -specific- interest in learning c++, go to flash. it's a perfectly OOP oriented programming language capable of doing what ever you want. with limits at comparing to major industry games, but even those are more involved than your obviously looking for.
you can learn all the c++ and graphics programming in the world, yet you can still be *clueless* about making games. TRUST me.
http://en.wikipedia.org/wiki/Game_theory
there's a science to everything don't spout lies!
flash doesn't require the IDE to create anything, you can write actionscript files which flash compiles, and make entire games from scratch, with a language that has MANY high level features FOR game programming.
game programming is VERY fun, and I LOVE discovering formulas to describe the relationships between events, and to write algorithms are GREAT! Bubba's experience and opinion != everyones.
You are the one's talking about making a game but forgetting silly little things like oh...memory management.
You might get away with that with other languages but eventually you will have to learn how to manage memory.
Try to program these 'simple' classic games without doing memory management or that god awful thing called programming:
- Asteroids
- Space invaders
- River raid
And yet strangely this is a C/C++ board and you are talking about flash and everything else except C/C++. I find that a bit odd. This is a game programming board as it relates to C/C++. Not VB, Java, HTML,Flash or anything you guys can cook up.Quote:
flash is perfectly ok, trust me, don't listen to the guy that doesn't know what he's talking about. unless you have a -specific- interest in learning c++, go to flash. it's a perfectly OOP oriented programming language capable of doing what ever you want. with limits at comparing to major industry games, but even those are more involved than your obviously looking for.
If you want to use a different language to program a game that is your choice. If you want to talk about it here on this board then obviously you want to program in C/C++ Dummy me but I thought the answer to which language to use on a purely C/C++ board was sorta obvious. If you want to use a diff language then go to that board and talk about it.
Since you have no idea who I am or how I feel about games I suggest we probably ought not to head down that path. Simplicity does not mean ignoring fundamental concepts which most of this thread is encouraging.Quote:
old atari games have persisted to today, just new skins and new looks. no game is bad because of its simplicity.
Why should we trust you? Being clueless about making games is all about avoiding those concepts that help you make the game....as in this whole thread.Quote:
you can learn all the c++ and graphics programming in the world, yet you can still be *clueless* about making games. TRUST me.
If you want to make a game..simple or not...learn to program. Do that first and when you can finally program in C/C++ then you can begin to make simple games. Until then I'd recommend diving into some C/C++ books and doing a lot of programming. Games are hard enough when you know C/C++ much less if you don't have a clue about it.
If I were the OP I'd bail out of this thread and head over to gamedev.net to get a wider perspective. Bubba's special :D He was kidnapped by programmer vikings and forced to conquer and pillage through programs, which is why he has such an unforgiving view on such topics. gamedev.net forums will probably tell you the same things, but in a different way.
In the end my opinion is that if you really want to program games, learn to do it right the first time. If you want to program in flash, seek out flash game programmers and ask them tips on how to do it correctly, then learn, the create games. I don't know if flash has much by the way of memory management but there are great flash games, some that rival even larger games by way of fun factor. Making a great game probably requires more creativity and intuition than pure programming skill, but if you have the idea, learn how to program in the language correctly.
C++ isn't the only way, but bubba is right in that you have to learn what constitutes a good program in any language, because if it's badly programmed, no matter how great it is, who is going to play it?
Am I the only one who -actually- read this?Quote:
What language should i use to make little games? like a language that is easy to make games for.
Does this sound like a curious itch to understand the fundamentals of software development? NO.
Even programmers should know what the -appropriate- response is... not -everyone- is like you or me.
Fact: You don't need to know memory management to make a game. - Proof: Flash.
Tell the kid the TRUTH! He can do it the easy way, just not to expect much of it!
I'm just as stubborn, I'm just not ridiculously irrational about understanding the intentions of human beings.
And just because I provide an easy answer, doesn't mean I don't respect or follow the 'hard path.'
Don't making assumptions. Give them the honest truth and let him make the choice, you know damn well no one has to learn any deeper than they want. This person is obviously only a little curious, he doesn't want to be a damn assembly programmer, that much is apparent by his lack of communication in his initial post.
Why do I get the feeling I'm the only sane person alive.
When someone really cares about something, they elaborate, when they're only a little interested, they make one lined comment.
ROFLMAO :D Hehe. If that wasn't so long I'd use it in my sig. Nice. Very nice.Quote:
Bubba's special He was kidnapped by programmer vikings and forced to conquer and pillage through programs, which is why he has such an unforgiving view on such topics. gamedev.net forums will probably tell you the same things, but in a different way.
Yes I am unforgiving on topics like this because so many want the easy way out which means they have the wrong attitude from the word go. If you want to learn and are willing to work at it then I'm not such a bad fella to deal with. But always insisting on taking the easy road to avoid the hard stuff is one way to get me a bit um....testy.
C/C++ is not the only language to program games in. However we are currently on a C/C++ board so perhaps going to other boards would be a much better option in this case.
I don't know if gamedev will be more forgiving or less. It all depends on who answers the thread. Some of them over there are more hardcore than any of us here. We know this because we often get people who have been flamed or rejected over at gamedev for having attitudes similar to this and then try to come here and do the same. Normally we are on par with what gamedev says albeit we each say our piece a bit differently.
This is the best piece of advice in this thread. We have the C/C++ perspective here which is not the only perspective there is. But we have to maintain focus here or the board will degenerate into 'any language will do'.Quote:
If I were the OP I'd bail out of this thread and head over to gamedev.net to get a wider perspective.
...well...Quote:
But we have to maintain focus here or the board will degenerate into 'any language will do'.
I was working on compiling SDL myself (for performance purposes), but games were crashing. I wasn't getting much feedback, so I decided I'd try to debug one. Frozen Bubble, if you've ever played it. Well, I fired up gdb, told it to go, and gdb promptly told me "No executable file specified." After a couple misguided attempts, something made me open Frozen Bubble in vim. Something that I thought wouldn't work, until I saw this:
Quote:
# Yes it uses Perl, you non-believer :-).
probably used perl to clean up the .cpp file ;b
j/k
I don't see why not knowing memory management would keep you from developing a game. Scorched Earth 2000 is an online version of SE that uses Java for both client and server. It performs pretty well and last time I tried it was pretty much bug free. Also I would consider it a bit more complex than asteroids or space invaders.Quote:
Originally Posted by Bubba
Personally I don't have anything against garbage collectors. And I especially don't see how using them automatically makes you a bad programmer. The main thing I like about C++ is that you can choose whether or not to use a GC. In fact you can even code your own and have it behave like you want it to behave.
No one said bad programmers or good programmers. But trying to program a game in any language without learning the language is bad. That is essentially what is being discussed here.
The simple point is if you cannot program then don't program a game. Learn to program and then program a game.
Not in theory, but in practice it's quite obvious that Flash sucks, period :)Quote:
and just because 90% of flash developers suck doesn't mean flash sucks for making games,
Hardly, it works quite well.Quote:
So essentially what you are saying is that Java frees memory when and if it wants to? Not exactly good inside of a pre-emptive multitasking system eh? Java is good for what it was designed for. It is caca for games.
And preemptive MT has nothing to do with it. If garbage collection didn't work in a multitasking environment I think we'd have found out by now, with over a decade of Java running multibillion dollar systems and a decade of Smalltalk before that (plus all the other systems using garbage collectors).
The GC frees memory when it can, running in a background thread. If you do something stupid and code a thread at a priority which preempts all others from running, that's your responsibility as an idiot, not the responsibility of the JVM (or any system employing garbage collection).
Not to undermine anyone here, but I go to Full Sail currently, which is a video game development school, and we focus on C++ here. Yet time and time again we have been told that unless you are truly working on a professional title, C++ is not worth it. The development time required outweighs the possible benefits. Flash is your best bet if you're looking for a language to pick up and make a game.
Now, with that said, if you wanted to "graduate" past small games you're probably going to want to take up another language. In that case I would say to jump into C++ headfirst, and like Bubba has said, time and time again, you need to know how to program, before you can learn how to make games. Making a game is a task that can test even the most experienced of programmers, and leave them curled up in a ball in the corner. If you don't have a strong foundation in the fundamentals of programming, memory management being PARAMOUNT for gaming, you can't hope to get very far.
Just my 2 cents...
Your input is more than welcome but please don't bump old threads.