-
Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.
Indie Game Development Discussion Thread | Of Being Professionally Poor
- Thread starter chubigans
- Start date
- Status
after you!
That's a neat moment.
Nothing's final yet, these screens were just to showcase the behavior more than anything else, we're doubtful this final game mode will even feature too many enemies at once. We're going for a relaxing vibe, not so much the twitch fest that was geometry wars.
I still need to go in an polish all the enemies up, we have a few that animate so we might go that direction also. Thanks for the feedback!
LSauchelli
Member
after you!
Always nice seeing more gifs from this game. Just posted a few of these on a group in facebook, hope you don't mind.
One question, not just to you Jobbs, but to most developers here, are you thinking about internationalization when you make your game? I don't mean that you have five languages for your game on launch day, just if you think ahead and make the game easy to translate?
Thanks \o/
The game is about a pilot of a hovertank destroying enemies
Here is the vid: http://www.youtube.com/watch?v=DmFLEHE5Mn8
And demo is available on Steam: http://store.steampowered.com/app/96200/
Well, from my experience, it's better to make English version first, release it and then based on response translate it into other languages. I made localization for Steel Storm right from the start and not only it slowed down the development, but also created bunch of technical issues we had to deal with.
Plus, I didn't design the system, and left that task to the former programmer. We ended up with pretty rigid system :/ (meaning it's really hard to add new strings to the game without overhauling old strings)
If you absolutely sure you want (and have resources) to do localization in the future, design localization system to be flexible, and then later you can always do the translations. I like how idSoftware did it in idTech 4 and up - it's a text file with strings, referenced by the number or an identifier. The order of doesn't matter at all, so it's pretty flexible and yet simple.
One thing for sure - you will still get more sales for English version. Pretty much anyone who play video games knows some English
Well, from my experience, it's better to make English version first, release it and then based on response translate it into other languages. I made localization for Steel Storm right from the start and not only it slowed down the development, but also created bunch of technical issues we had to deal with.
Plus, I didn't design the system, and left that task to the former programmer. We ended up with pretty rigid system :/ (meaning it's really hard to add new strings to the game without overhauling old strings)
If you absolutely sure you want (and have resources) to do localization in the future, design localization system to be flexible, and then later you can always do the translations. I like how idSoftware did it in idTech 4 and up - it's a text file with strings, referenced by the number or an identifier. The order of doesn't matter at all, so it's pretty flexible and yet simple.
One thing for sure - you will still get more sales for English version. Pretty much anyone who play video games knows some English
Talking about localization systems, does anybody know if there's a way to add unicode text and font support to Unity so it's possible to load and display stuff in languages such as japanese?
After a rather rubbish day at work I get the urge to improve my programming ability and live the big indie dream. I can make stuff in Gamemaker of medium complexity but I need to accelerate my learning - anyone have any suggestions for intermediate tutorials? Most I see are either beginner or advanced.
Though by "game logic" most people would probably expect the PC to fall faster and overtake. I cannot wait to play this once you're done.
That's cool, but also physically impossible - objects fall at the same speed, independent of their respective mass and weight. Only things like wind resistance would cause a disparity between fall speeds, but as the creature is a ball it wouldn't be an issue.after you!
Though by "game logic" most people would probably expect the PC to fall faster and overtake. I cannot wait to play this once you're done.
I don't know anything about Unity, but, if the engine already doesn't support UTF8 for ttf/otf fonts, maybe you could make use of bitmap fonts?
We went from image based menus and graphics to text so we can easily translate down the line. There were issues finding similar fonts and styles but we eventually got it.
Son, this is vidja gamez
(No disrespect to missile's unbelievable physics simulations)
Your question is noted, and the answer is "video games"!
that's cool, I appreciate you posting it.
re. internationalization.. wow.. haven't even thought about that. the game will be fully voiced, so the extent of it would probably be subtitles. honestly I haven't even thought about it at all yet. naturally when it's done I'd like to have as many options out there as possible.
Son, what if the ball creature was trying to slow down and you couldn't tell?
In the past I was on a project where the team intentionally came up with easy to understand symbols for navigating the UI in the place of text. Naturally that's not going to work with every type of game, but it's worth trying to do if it fits.
That tends to work on a limited scope, since you'll soon enough run into issues such as the way Japanese people use "O" for accepting and "X" for cancelling, while other countries use "X" to accept stuff (as if they were checking a box), and I think the same issues would happen with shapes (ie: stop signs don't have the same shape in every region) and some colors.
If what I've been thinking about actually works, I'd like to let players choose from among eight symbols and colors for marks they can manually place on their maps, rather than having all doors, events and pick-ups marked beforehand.
I'd say making a game that requires no localization is possible, as long as you use tactics such as Braid's, that kind of avoids using GUI elements except for button prompts or the pause menu. I'd like to do that kind of thing someday if I manage to find the right game for it.
Might as well drop the cash for a GTX 680. You can write it off! Maybe.
Edit: Jobbs, let me know if you need help casting your game. I got the hook up in Los Angeles, yo.
Damn boy whaaaaat
I do not know to what this refers
Ronald Jenkees got you the voice over hook up? Or other hook ups?
Diablohead
Member
Been slowly working on cave level tiles, really need to pick up the pace again this weekend.
Aha I see. Nice!
Ahh ok, thought you guys were near towards the end of developing the game.
So what's the current state of the game; alpha, beta, gamma, delta?
It is possible that the main character may overtakes the turtle like in the
video shown if he rotates faster. If so, it can be assumed that the flow
near the skin of the character is faster as well (= higher momentum, m*v) due
to the pulling effect caused by the skin friction of the characters' suit.
Since the flow near the skin has a higher momentum, it is much more likely
that the air follows the path of the main characters' shape much more closely
before separating away, which essentially will leads to a smaller pressure
difference and as such to a smaller retarding/drag force. Just saying... xD
Holy shit, you're Nocturne. I hate your ults.
Assuming the thing gets funded, it'll be a while before we actually have to record all the VO. That's a late in the process thing for me, I'd think. I don't have a super specific plan yet, but I've seen some good talent online and I know a person or two who may also be a good fit. I was also considering doing one of the supporting roles myself to save on money/time if I could manage an acceptable performance. I'm determined to get the VO done and on point, even if it means I have to be really scrappy/cheap/creative to do so. For some of the smaller roles I could probably cast friends/family/whatever and just do so many takes that I get what I need. There are a couple roles that require some range and thus require people who can really act. Those'll be the most challenging to cast.
I'd say we're around Beta, once we get our music guy to write us a contract we'd be just about ready to launch. Once we nail our point system, I'll go in and tweak every effect to my liking, including choosing final colours for our enemies!
DARRKKKNNNEESSSSSSSSS
I have a lot of friends who would probably do it extremely cheap or free, and still pretty well. And I'd be willing to contribute to a GAF project, of course, for free. = D Just let me know!
Dynamite Shikoku
Congratulations, you really deserve it!
I'd love to donate my design skills for any gaffer also
What kind of design do you do?
Popped in to say I just retweeted. And are those damage numbers I see? <3 Damage numbers.
Will be backing you (yes, my first ever backing) on Monday.
Thank you!
And the answer is yes, the damage numbers are there to help you determine the effectiveness of your given weapon vs. the given enemy. There are some incidental specific case differences, as well as more sweeping differences -- For example, the rail shot is particularly effective against organic targets, and the ionic blast is particularly effective against anything mechanical.
There are also incremental damage modifiers/upgrades to be found, and you have a crit rate, all that stuff. I enjoy teaching people that an area might not be the place to go yet not always by there being a door you can't pass, but maybe there's an enemy you can barely dent. Certain types of enemies I've set it up so that if your damage rating is below a certain threshhold, you get an additional damage penalty against them. The idea being, conceptually, your damage rating doesn't just represent some even curve, but some kind of overall proficiency as well.
The bigger orange number is a crit.
Manabanana
Member
Jobbs that looks gorgeous! Can't wait for the kickstarter.
FranXico
Member
The air resistance is proportional to the contact surface area - I suppose it will be believable if the "ball" is bigger.
Jobbs, all those gifs look beautiful. Nice work.
It's been a long time since I posted in this thread. I've made a few small games since then, working on a puzzle game right now. Pretty simple, given two silhouettes on the left and right, you have to build the 3D structure that projects those two shadows.
The build I'm working on right now is still kind of messy, and my latest public build is really old. hope to get something playable (and recent) up here within a week. I'd love to get people to test it out, especially if they've got a low spec computer. I want to see just how low I can reasonably get.
screenshot:
gif of paradoxes:
It's been a long time since I posted in this thread. I've made a few small games since then, working on a puzzle game right now. Pretty simple, given two silhouettes on the left and right, you have to build the 3D structure that projects those two shadows.
The build I'm working on right now is still kind of messy, and my latest public build is really old. hope to get something playable (and recent) up here within a week. I'd love to get people to test it out, especially if they've got a low spec computer. I want to see just how low I can reasonably get.
screenshot:
gif of paradoxes:
Real A.I. codez:
Fuck comments
Code:
for (i = 0; i < soldiers.Count; i++)
if (soldiers[i].following == -1)
for (j = 0; j < soldiers.Count; j++)
if (soldiers[j].following == -1 && i != j)
if (soldiers[i].getDestination() == soldiers[j].getDestination())
if (Utility.getDistance3D(soldiers[i].transform.position, soldiers[j].transform.position) < 2)
if (soldiers[i].pathDistance > 0 || soldiers[j].pathDistance > 0)
if (soldiers[i].pathDistance < soldiers[j].pathDistance)
{
soldiers[j].following = findTrailer(i);
if (Utility.getDistance3D(soldiers[soldiers[j].following].transform.position, soldiers[soldiers[j].following].getDestination()) < 0.5f)
soldiers[j].setDestination(soldiers[soldiers[j].following].transform.position -
0.5f * Utility.makeUnitVector3D(soldiers[soldiers[j].following].actualOrientation));
else
soldiers[j].setDestination(soldiers[soldiers[j].following].transform.position);
}
else
{
soldiers[i].following = findTrailer(j);
if (Utility.getDistance3D(soldiers[soldiers[i].following].transform.position, soldiers[soldiers[i].following].getDestination()) < 0.5f)
soldiers[i].setDestination(soldiers[soldiers[i].following].transform.position -
0.5f * Utility.makeUnitVector3D(soldiers[soldiers[i].following].actualOrientation));
else
soldiers[i].setDestination(soldiers[soldiers[i].following].transform.position);
}Fuck comments
I have a question to the programmers out there.
I've been a web developer for a number of years now, starting from classic asp and moving onto VB.net. After a year of feeling very bored and unfulfilled where I am at the moment, I've decided to take the plunge and expand my skill set and indulge in my life long dream of make my own game.
I originally considered Unity as my first framework, but decided in the end to go with XNA. Both use C# and I thought working with XNA would be a good stepping stone to work with before I move onto Unity.
So before I get to the actual question I have in mind, could I have someone's opinion on this? Despite doing computing at college and taking a web development course at Uni, I've never really had proper training in OOP. When I moved from asp to vb.net it was quite a high step for me, from a skillset POV, but I think I managed to understand most of the concepts and get on with my job. Does anyone think that a lack of a deeper understanding of OOP will hinder my attempt to make games?
Now, the actual question!
There has been a couple of games that has really inspired me into attempting to make my own game. Mike Diskette, from 5 Lives studios and the awesome pledgers over at Syndicate wars helped me, but 2 games really stood out for me. Bro Force and HammerWatch (both of which I have preordered). Both of those games has inspired me to make a 16bit style shooter (from the perspective of say Cannon Fodder), so I've been looking into tutorials on developing a 2D shooter.
Could someone tell me if I am going down the right route here: Now I'm just getting my head around the concept of a spritesheet and I'm trying to figure out in my head about how I would build a level with assets from a sprite sheet.
Obviously, you load the spritesheet into memory as a Texture2D object. 1st question, each time I refer to an element on that sprite sheet does it take up more memory in addition to the memory used when I loaded the spritesheet into memory? So if I refer to an element on that sprite sheet at say X=0, Y=40 and use it 20 times, would that take up 20 x the memory? I'm guessing it depends on how I use it?
2nd question, would it make sense to break that spritesheet up into a dictionary object? then I can quickly access each element on that spritesheet? Thinking this would be something that could be implemented from a level builder point of view.
Apologies if these are fairly basic concepts I should know, but going from a data driven programming background to developing a game appears to be a bigger leap than I originally thought it would be.
I've been a web developer for a number of years now, starting from classic asp and moving onto VB.net. After a year of feeling very bored and unfulfilled where I am at the moment, I've decided to take the plunge and expand my skill set and indulge in my life long dream of make my own game.
I originally considered Unity as my first framework, but decided in the end to go with XNA. Both use C# and I thought working with XNA would be a good stepping stone to work with before I move onto Unity.
So before I get to the actual question I have in mind, could I have someone's opinion on this? Despite doing computing at college and taking a web development course at Uni, I've never really had proper training in OOP. When I moved from asp to vb.net it was quite a high step for me, from a skillset POV, but I think I managed to understand most of the concepts and get on with my job. Does anyone think that a lack of a deeper understanding of OOP will hinder my attempt to make games?
Now, the actual question!
There has been a couple of games that has really inspired me into attempting to make my own game. Mike Diskette, from 5 Lives studios and the awesome pledgers over at Syndicate wars helped me, but 2 games really stood out for me. Bro Force and HammerWatch (both of which I have preordered). Both of those games has inspired me to make a 16bit style shooter (from the perspective of say Cannon Fodder), so I've been looking into tutorials on developing a 2D shooter.
Could someone tell me if I am going down the right route here: Now I'm just getting my head around the concept of a spritesheet and I'm trying to figure out in my head about how I would build a level with assets from a sprite sheet.
Obviously, you load the spritesheet into memory as a Texture2D object. 1st question, each time I refer to an element on that sprite sheet does it take up more memory in addition to the memory used when I loaded the spritesheet into memory? So if I refer to an element on that sprite sheet at say X=0, Y=40 and use it 20 times, would that take up 20 x the memory? I'm guessing it depends on how I use it?
2nd question, would it make sense to break that spritesheet up into a dictionary object? then I can quickly access each element on that spritesheet? Thinking this would be something that could be implemented from a level builder point of view.
Apologies if these are fairly basic concepts I should know, but going from a data driven programming background to developing a game appears to be a bigger leap than I originally thought it would be.
1) I don't think you'll hit problems with Unity3D on PS4
2) 7870XT / 7870 MYST or 7950 3GB (More wiggle room with VRAM). 7970's are surprisingly cheap now.
3) Or buy nVidia and get a 760 4GB (Again to mess with VRAM, though honestly 2GB should be plenty). GTX 770 if you really want.
You are a generation behind Feep. Shamefullllll. Go back to making video games.
I don't run a hyper-comprehensive build-your-own PC thread, BRO
If you're rolling 2-D, you absolutely made the right choice.
It's helpful, but a little overrated, IMO. Just be clean with your code. XNA takes care of a lot of messy stuff for you.
No, references are free! Well, free in terms of additional memory space, mind you. C# will go in and garbage collect anything you create and aren't using anymore.
A Dictionary might be useful. You should at least make a helper function that automatically "grabs" the correct element from a simple integer. Something like
Code:
public Rectangle getRect(int tile, int tileWidth, int tileHeight) //Example SpriteSheet is 4x4
{
return new Rectangle((tile % 4) * tileWidth, (tile / 4) * tileHeight, tileWidth, tileHeight);
}Ubersnug, it has been a long time since I programmed in XNA (or C# for that matter) but I am pretty sure that point of the spritesheet itself is that when you repeat a pattern on screen, because it references the same object, it will not take n times memory (where n is the number of times the fragment is used).
So basically, the structure is this:
a. Source file, which you load - the spritesheet
b. Individual game objects or a single background object with an array of data
c. The draw function drawing to the picture from the single source file you gave to it, drawing regions specified by the objects (b.) or the background object.
The only memory cost that increases if you keep adding objects to the foreground/background, but they will still only reference your a., object, not create duplicates, copies or even new objects.
To the second question: yes, dictionaries will help you (I am using dictionaries for specific areas in JS for spritesheet-based drawings as well).
You have a huge picture, full of stuff, and for every type of object, and for every possible animation state of that object, you specify what region it will draw from. I have different dictionaries for all the different objects, all still referencing their own sheets or one sheet if you go that way. It is more managable that way.
So basically, the structure is this:
a. Source file, which you load - the spritesheet
b. Individual game objects or a single background object with an array of data
c. The draw function drawing to the picture from the single source file you gave to it, drawing regions specified by the objects (b.) or the background object.
The only memory cost that increases if you keep adding objects to the foreground/background, but they will still only reference your a., object, not create duplicates, copies or even new objects.
To the second question: yes, dictionaries will help you (I am using dictionaries for specific areas in JS for spritesheet-based drawings as well).
You have a huge picture, full of stuff, and for every type of object, and for every possible animation state of that object, you specify what region it will draw from. I have different dictionaries for all the different objects, all still referencing their own sheets or one sheet if you go that way. It is more managable that way.
bumpkin
Member
hahaha. Yeah, you say that now. Wait until a few months (or even weeks) after you walk away from the code to work on another part, and have to go back for some reason or another.
I like New Awareness to death! Totally awesome. Can you send me a hifi (raw)
version?
Isn't the code supposed to be the comment? xD
Man, you better start coding. Most of the things will unfold as you go.
Dynamite Shikoku
Congratulations, you really deserve it!
I like New Awareness to death! Totally awesome. Can you send me a hifi (raw)
version?
Hehe really? I'll put the raw version on my google drive later on for you.
Pretty much everything, from web design to art direction
Reminds me of the Perl code I wrote to make a Pokemon Online Battle Simulator when I was a teenager. No or few comments, variables named j, jj, k, l, etc. My code was horrifying.
As someone who now spends a lot of his life maintaining or extending old code, I respectfully recommend you reconsider your variable names, code, and/or lack of comments, but I suspect either this is test code or you don't want to. If you're the only programmer, you're only hurting yourself at any rate.
... No or few comments, variables named j, jj, k, l, etc. My code was horrifying.
As someone who now spends a lot of his life maintaining or extending old code, I respectfully recommend you reconsider your variable names, code, and/or lack of comments, but I suspect either this is test code or you don't want to. If you're the only programmer, you're only hurting yourself at any rate.
I agree with this from my personal experience. It's worth spending the extra effort to do things well the first time both for the stability of the program and your sanity in the small term.
One of the biggest deterrents to well named functions and variables is pure laziness typing things out. Even with autocomplete (VisualAssist yay!) it just feels easier to type "i". My current habit is to just use the i, j, k, etc naming and then as soon as the block of code is completed use the rename variable refactoring tools that almost all IDE's have now. Lets you lazy type and write self-documenting code simultaneously. For more complex multi-dimensional indexing scenarios it also serves as a good sanity check to examine the usage of the index variables to make sure you are indexing correctly
I am old school where variable name length actually hindered performance. Lol I still catch myself abbreviating things I shouldn't.
anyway I have been doing some testing on how well html5 ( sans web gl) really is in being able to create games.
There has been a few hurdles to over come but I've got some pretty good results I hope to share soon.
One horrible aspect is the differences in how different browsers run java script and cache images.
JavaScript runs horribly on IE and fire fox .. Chrome and safari are the best.
Also some browsers don't actually cache images until they are used. Which means you have to do more than just load them.
anyway I have been doing some testing on how well html5 ( sans web gl) really is in being able to create games.
There has been a few hurdles to over come but I've got some pretty good results I hope to share soon.
One horrible aspect is the differences in how different browsers run java script and cache images.
JavaScript runs horribly on IE and fire fox .. Chrome and safari are the best.
Also some browsers don't actually cache images until they are used. Which means you have to do more than just load them.
- Status