Yeah, I might try to dirty the barrel down the road. Making it less "perfect". I noted it for the polishing stage
As for the text box, I am trying to find something that would fit anywhere. I hope to have one textbox model for the whole game.
-
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
Yeah, I might try to dirty the barrel down the road. Making it less "perfect". I noted it for the polishing stage
As for the text box, I am trying to find something that would fit anywhere. I hope to have one textbox model for the whole game.
The Technomancer
card-carrying scientician
Well it looks like I'm cycling back into a phase where I fiddle around with game programming. Uber-hobbyist here, bare-bones education in programming, but my brother wants to work on something together so I'm going to learn the basics of...looking like Flixel and Unity at the moment so we can just bash some stuff together and get a feel for game creation.
Okay so I want to take the plunge and begin developing some simple games, if mostly only to learn. I know some Java and C++, but not much at all to be honest.
What Engine should I go with? It seems Unity might be the best for me to start in, but UDK, CryEngine, and Source all looked pretty good as well. Thoughts? I am spending to long trying to figure out how to first get my feet wet as opposed to jumping in.
What Engine should I go with? It seems Unity might be the best for me to start in, but UDK, CryEngine, and Source all looked pretty good as well. Thoughts? I am spending to long trying to figure out how to first get my feet wet as opposed to jumping in.
BomberMouse
Member
Simple games? go with gamemaker.
Okay, I'll check that out. But I also wan't to start learning a 3D toolset and getting into level design and stuff. Really just to diversify my knowledge of game development as a whole. I know source is pipelined with Softimage. Unity seems really nice to publish stuff on though.
Mainly I'm looking for an engine that implements a Java or C# scripting language. C++ would be fine too, but I'd need to delve into learning that a bit.
BomberMouse
Member
Well if you start with something simple like GM you'll get to do the fun part of game development, which is actually designing a game and not fighting with a programming language. Also, you'll get a much better idea of how to implement you own engine later on.
Unity has C#, and GameMaker has GML which is easy enough to pick up if you're not scared of Java/C#.
UDK/Unity/CryEngine 3 would be fine for 3D stuff, just bear in mind that unless you've had some training, you may spend a good bit of time learning to create the 3D models, let alone use them.
(unless you go with simple models or reuse existing stuff)Mouse lag is basically inescapable if you are dragging things with vsync on, correct? If I use the hardware mouse cursor and show something dragged under the mouse, even with vsync OFF, should I expect the dragging to not be precisely locked to the mouse? I'm hoping I'm not missing something obvious.
My understanding is that you can't get around this and must use a software cursor, so that's what I will plan to do, but I wanted to make sure by asking first.
My understanding is that you can't get around this and must use a software cursor, so that's what I will plan to do, but I wanted to make sure by asking first.
I can't recommend Unity enough. It's a great development environment, and even better, it has an amazing community. Usually, if you have a question, it's already been asked and answered.
It integrates pretty much perfectly with external editors. You 'open' an asset from within Unity and it launches the associated editor. When you save and switch back to Unity it automatically updates. Magic!
And unless you want the high-end features, it's free!
I thought those were condom packages as I quickly scrolled past them lolI got business cards printed for Saturday's Indie Game Meet Em Up in London. I used beanprint.com and they arrived when they said they would, and they're pretty decent.
Happy
Same here. I've been using Unity for over three years now, and it's great for prototyping and making games if you aren't interested in low-level programming.
Unity supports C#, JavaScript and some Python variant called Boo, but I like C# the most, since it's an easier to use C++ (no pointers and automatic memory management unless you explicitly state it).
I've been working for almost two years on a game for my Game Design thesis (in a small and probably unknown college in Argentina), but I've mostly been doing it alone and on my spare time after work and other activities, so it's been progressing quite slowly. I'm currently overhauling the placeholder graphics and UI.
The game's a simple 2D platformer where your only means of movement is rocket jumping. Here're some screenshots from within the Unity editor (click on a thumbnail to see the full-sized image):
I'm also working on a simple localization system I've put in place to translate all in-game text (which I wrote in spanish so far), so I guess I could upload a localized demo soon.
snoopeasystreet
Member
How's 2D development in unity? Is it easy to do out of the gate or do I have to buy that add on?
I hear its not too good, though I don't have any first hand experience.
GayForMaster
Banned
Didn't know RPG Maker had a price. Would people really pay to make games on that engine? I enjoyed it but that was when I was a kid.
What's this, my mouse lag question wasn't answered since last night, MADNESS! ;p
Also, you know how I'm always warning people against feature creep? I'm the worst...I feel like each time I knock 2-3 things off my GUI development list I add 2-3 more. I'm trying to make sure I have a good base design, and then be able to pick other features as "This should be feasible, but I can put it off until I am making my GUI editor and add it then" instead of making generic GUI stuff forever.
I suppose making one's own GUI system from scratch is a great exercise, since that's a classic programming task over the last 25 years or so. >_>
Also, you know how I'm always warning people against feature creep? I'm the worst...I feel like each time I knock 2-3 things off my GUI development list I add 2-3 more. I'm trying to make sure I have a good base design, and then be able to pick other features as "This should be feasible, but I can put it off until I am making my GUI editor and add it then" instead of making generic GUI stuff forever.
I suppose making one's own GUI system from scratch is a great exercise, since that's a classic programming task over the last 25 years or so. >_>
I don't know what version you used, but the past few versions have had the game engine written in Ruby (technically a modified version of Ruby 1.81 with graphics/sound support), and included a code editor, while previous RPG Makers forced you to use a hard-coded engine. Due to this, it's become significantly less restrictive. The main faults now are Ruby being slower than languages like C++ and even Java (so games with complicated real-time stuff might run slowly), it's limited to Windows due to using a Microsoft graphics API, and you're graphically limited to 2D (without filtering for scaling/rotation at that). There have been some pretty cool 'mode 7' scripts if you want an authentic SNES-style RPG though!
RPG Maker XP is significantly cheaper than VX and Ace, and is nearly identical feature-wise (the main difference is the scripting language has a few extra functions, the mapping system is different, and the graphics/music are different). I actually prefer the system in XP to that in VX.
RPG Maker isn't really used for commercial games; it's mostly something for beginners to dabble with. That hasn't stopped games like To The Moon, though.
It was quite easy to do. All there is to it is making sure all objects share the same Z position (in this case, zero) and constraining all rigidbodies' position so they can't move along the Z axis, like this:
I haven't had any problems with this approach so far and it works quite well, mostly thanks to RigidBody constraints, which were added in a relatively recent update (previously, I had lots of trouble making it work, since I coded a hack to achieve it, andeven then there were some awful physics problems). I haven't tried a true 2D game so far, but guess it works best when you're using 3D objects and Unity's built-in physics system.
By the way, I'm using Unity free with all assets being hand-made by me, except for one shader I'm about to remove, which I got from Unify Community's examples and a placeholder texture that's still around. The game as I've designed it doesn't appear to need any of Unity's pro features, so I intend to finish it with the free version and release it that way unless I find myself forced to go pro for some reason (such as to removing the "powered by Unity" screen or using plug-ins).
So far, I've built and tested the game in PC, Mac, Web Player and Android, and it works well without any need of platform-specific code. The android version suffers from some framerate problems in lower-end devices, but I guess it's because of that one complicated shader I'm trying to replace.
Nope, Unity has no native way to recognize and use 2D sprites, sadly. All of my game's assets are actually [really simple] 3D models, and I don't even have to bother with any faces except the front ones because the orthographic camera would never show them.
If you used a pure sprite-based approach with no separate character parts, you'd probably have to code all physics and collision checking yourself, but you could always use a hybrid approach, such as:
- Having the sprite animate in whichever way you like, relying on a cube, sphere or capsule collider for physics checks. This method might lead to hitbox dissonance if the sprite's pixels and the collider's boundaries don't match up, but is really simple to implement.
- Creating sprites as 3D models by splitting their various body parts (as you would in Flash), skinning it with your 3D modeling program of choice and animating the character by moving the its bones and/or swapping textures on the fly, using primitive colliders for physics checks. This approach requires some mid to heavy programming to implement, but is a bit more robust and versatile than the previous one since, for example, you can move hitboxes rather than rely on static ones.
Those are just two implementations I thought up right now, which could or could not be useful for what you had in mind. You probably should look around unity forums and communities, because it's quite likely that someone has already made some sprite-based system already (even if it isn't as robust as paid asset packages). If you don't find anything useful, you could always try to come up with a tailor-made implementation of your own.
However, using a 2D game engine could probably be the easiest route, unless you really want or have to use Unity.
I think I would want to transition to using Unity if I was to do 3D game design, or publish a game. For now though learning is the biggest priority. So I think I will be dabbling in gamemaker, or perhaps XNA.
eot
Banned
Watching videos of Super Hexagon gave me an idea for a super simple iPhone game. I don't have any iOS devices but I decided to whip together a prototype anyway. I borrowed Captain Viridian from VVVVVV because it seemed appropriate. It actually turned out to be pretty fun.
A link in case anyone wants to try it (1mb download):
http://www.speedyshare.com/ExfNA/vbounce.rar
It's pretty self explanatory.
edit:youtube
A link in case anyone wants to try it (1mb download):
http://www.speedyshare.com/ExfNA/vbounce.rar
It's pretty self explanatory.
edit:youtube
Well, your game is running like a billion frames a second, so you're going to start hitting device specific limits I would think. Although, I've never noticed mouse lag before, so maybe you do have some sort of out of order update, so you're drawing the pointer where the mouse was last time...?
We did hit a problem where polling the keyboard at more than 500 frames per second resulted in no input at all. Stuff gets weird at high speed!
I'm pretty sure it happens whether it's 60 fps or 1000 fps. I thought the input might be an issue as well, and switched to direct Windows API calls to get the current mouse position -- still had the same result. So unless I'm getting 1-2 extra frames of lag purely from SFML, I think it's just the nature of hardware mouse cursor drawing.
If anyone wants to test this themselves, try making an application that simply draws a rectangle at the mouse cursor position (so the mouse cursor points to the top left corner of the rectangle). Then try slowly moving the mouse back and forth horizontally, and see if the rectangle stays perfectly locked to the cursor, or if there is elasticity.
I found a really neat sega genesis tracker called VGM Music Maker. I sent it to my music composer and here is the result!
TheFightingFish
Member
That's interesting info. I'd seen posts before that using 3D objects and just using orthographic view led to pretty unreasonable performance in 2D, especially on mobile devices. 's why I thought that so many of the 2D paid plugins using some type of texture atlas. Thanks for the info that you provided.
I'm not that familiar with how collisions are handled in Unity, I wonder how one would move around collision boxes / spheres on a per frame basis for an animating 2D component (like hit boxes for a fighting game).
That sounds tight!! Love it, sounds straight out of a Sonic game
OccamsBlender
Member
2.5D is piss easy out of the gate. They even provide a tutorial for it. But real 2D with sprites and all that?
Be prepared to pay for some Asset Store add ons like Sprite Manager or Rage Tools.
Hooray for floating point problems. I was experimenting further to make sure my update rate stuff was all stable and consistent...and found that when I cranked the internal update rate up to 900+ updates per second, certain enemies were flying much further than they should, compared to 60-120 updates per second!
Turns out that long ago I apparently included a + 0.5 operation in my "MoveInDirection" method for game actors, presumably out of some misguided idea about integer rounding. The funny thing is that it doesn't even seem to have been rounding, since it's assigning to a floating point (double) variable.
Long story short, I got rid of that, and now everything is consistent with both high and low update rates. I may some day end up fussing if sprites are drawn blurred because they are at non-integer locations, but I think at that point in time I'll just worry about adjusting the coordinates when they are drawn to force them to be at integer boundaries if I need to.
Turns out that long ago I apparently included a + 0.5 operation in my "MoveInDirection" method for game actors, presumably out of some misguided idea about integer rounding. The funny thing is that it doesn't even seem to have been rounding, since it's assigning to a floating point (double) variable.
Long story short, I got rid of that, and now everything is consistent with both high and low update rates. I may some day end up fussing if sprites are drawn blurred because they are at non-integer locations, but I think at that point in time I'll just worry about adjusting the coordinates when they are drawn to force them to be at integer boundaries if I need to.
SappYoda
Member
I finally decided to try Unity and well I am impressed.
It took me 3/4 of an hour to make something in Unity that took me days with Ogre and Physx...
I guess experience helped.
This Scripting tutorial is the best way to start: http://download.unity3d.com/support/Tutorials/2 - Scripting Tutorial.pdf
It took me 3/4 of an hour to make something in Unity that took me days with Ogre and Physx...
I guess experience helped.
This Scripting tutorial is the best way to start: http://download.unity3d.com/support/Tutorials/2 - Scripting Tutorial.pdf
Hooray for floating point problems. I was experimenting further to make sure my update rate stuff was all stable and consistent...and found that when I cranked the internal update rate up to 900+ updates per second, certain enemies were flying much further than they should, compared to 60-120 updates per second!
Turns out that long ago I apparently included a + 0.5 operation in my "MoveInDirection" method for game actors, presumably out of some misguided idea about integer rounding. The funny thing is that it doesn't even seem to have been rounding, since it's assigning to a floating point (double) variable.
Long story short, I got rid of that, and now everything is consistent with both high and low update rates. I may some day end up fussing if sprites are drawn blurred because they are at non-integer locations, but I think at that point in time I'll just worry about adjusting the coordinates when they are drawn to force them to be at integer boundaries if I need to.
For a consistent feel, I would advise you to pick a simulation rate and stick with it before you tune the way things move. Then interpolate positions of things for display.
Magic numbers are only any good for one update rate. If you double the rate, things feel subtly different.
Your update rate should be picked based on a technical consideration, such as maximum speed of things, and therefore how much they can, ahem, interpenetrate each other.
Experiment for yourself with low update rates, I think you'll be surprised how responsive things can be with a really low simulation rate, as long as the display is running fast and is interpolated!
The LOL of it is that Unity uses Physx
Doubly amusing for me, as I used to sit next to one of the programmers of Physx, when we worked at Sega. He did the heavy maths, I did the controls/feel of the handling for Sega Rally, (Revo). Small world!
Thanks for the response! I'm not picking a magic number as far as I know, aside from deciding the internal update rate itself. I just wanted to make sure things WORKED with different choices, and changing it revealed a couple of engine bugs so I'm glad I made sure it was consistent. I do have a feature for interpolating between updates for actors that want that, also.
I'm also making a strategy game rather than an action game, so I am not really to the point where I am tuning the feel of moving things in a final sense.
Regarding low update rates, I might have mentioned running very low update rates (e.g. 1 fps) as a test, and animation/motion do indeed seem to work smoothly with the 60 fps rendering and actor interpolation. However, since I am also doing input sampling inside that fixed-length loop (which may be a mistake, but I suppose was so that I don't do input processing 1000 times a second if running at a high framerate), running at 1 fps means keyboard/mouse input has a huuuuge lag. That's the main reason I'm keeping high internal framerate (120-240), to make the UI reasonably responsive, since mouse and UI input will probably be a huge part of my game.
Sorry for so many posts, but I wanted to follow up: I moved input-handling out of the fixed time step loop. I can't see any real reason why it should have been there, since input-handling is just looping through all available buffered SFML events and processing them.
So now each main game loop I process all input, do the fixed time step internal update loop, and then render a frame. With the guaranteed input processing every rendered frame, I feel like the mouse input is more responsive so I'm happy (aside from that weird 24/30 fps thing that happens every 5 days or so on my computer).
So now each main game loop I process all input, do the fixed time step internal update loop, and then render a frame. With the guaranteed input processing every rendered frame, I feel like the mouse input is more responsive so I'm happy (aside from that weird 24/30 fps thing that happens every 5 days or so on my computer).
eot
Banned
Sorry for so many posts, but I wanted to follow up: I moved input-handling out of the fixed time step loop. I can't see any real reason why it should have been there, since input-handling is just looping through all available buffered SFML events and processing them.
So now each main game loop I process all input, do the fixed time step internal update loop, and then render a frame. With the guaranteed input processing every rendered frame, I feel like the mouse input is more responsive so I'm happy (aside from that weird 24/30 fps thing that happens every 5 days or so on my computer).
Under what circumstance were you previously not polling input every frame? Did you exit your fixed time step loop if it exceeded its allotted time? The way I usually do things is just run the game logic once per frame and if it takes longer than it should then welp basically. I haven't made any games demanding enough for that to be an issue and even so, just letting the FPS drop is a safe way of doing it since it doesn't break anything.
My game logic was to not run the input + game logic code unless more than my fixed step length had passed. My fixed step length was shorter than the vsync render frame length, but I think in some cases the boundaries might fall such that a frame would render and the input check would happen right afterwards, meaning input and logic didn't process at all until next frame. This may not be the case though...with vsync it should be happening every frame ANYWAY, so I'm really not sure. It just seems to work better now, so I'm leaving it with a single input handling check and looping game logic updates, especially since it's simpler.
It's sort of difficult to explain and maybe I don't have a good grasp on it still.
Maybe it's just placebo.BomberMouse
Member
Play to your strengths, don't do a game that requires good art if you are neither able to draw it or pay for it.
Diablohead
Member
I went to uni to do sequential illustration and 3D modeling, not that it really helps you learn to draw, art is partly talent which varies from person to person.
BomberMouse
Member
So I just installed Unity to tried it. I downloaded 4 years ago but couldn't get into it due to how convoluted everything is, I thought after all this time things should be simpler right? Nope.
Same shitty interface with a million options. GM is so much easier in comparison, too bad it's only for Windows.
Same shitty interface with a million options. GM is so much easier in comparison, too bad it's only for Windows.
Zenaku
Member
I've dabbled in game creation for years now, learning some 3D modelling/basic programming and the like as a hobby, never really getting anywhere, and I've just started messing around in Unity. I've tried using a Javascript based editor (Sphere) years ago, so I'm currently building a basic system found in visual novels to recall my lost knowledge and get a feel for Unityscript.
Just starting it by getting it to read game text and system calls (to play animations/switch scenes, etc) from a script.txt file. Hopefully it'll lead somewhere interesting.
Just starting it by getting it to read game text and system calls (to play animations/switch scenes, etc) from a script.txt file. Hopefully it'll lead somewhere interesting.
GayForMaster
Banned
It's not so hard to get into. What's the smallest thing you'd like to achieve at first when using Unity?
- Status