Support NeoGAF

[Syph Medwes]

If you don't have code experience it's going to be far easier to using an existing package (gamemaker, etc) than to code from the ground up. Porting to an old console in particular is incredibly difficult unless you have substantial C and assembly knowledge.

What are your current skills in matter of coding and art? Can you do the scripting, graphics and music?
If you go 2D, GameMaker is a great soft to start with.

I know basic C++, and the graphics and music I'm not worried about, so I guess the thing I'm asking of in this thread is how to get started pertaining largely to the coding side of things.
I would still want to build it from the ground up; time or having to learn things aren't issues for me.

Like I've made text based games before, but I'm not sure how to get started making games with actual graphics if that makes any sense. (I apologize in advance for being so all over the place) I think what I'm looking for are resources to get started or point me in the right direction.

 

[Blizzard]

I know basic C++, and the graphics and music I'm not worried about, so I guess the thing I'm asking of in this thread is how to get started pertaining largely to the coding side of things.
I would still want to build it from the ground up; time or having to learn things aren't issues for me.

Like I've made text based games before, but I'm not sure how to get started making games with actual graphics if that makes any sense. (I apologize in advance for being so all over the place) I think what I'm looking for are resources to get started or point me in the right direction.

If you're comfortable with C++, I'd suggest you look up tutorials for SFML or even SDL. There's a downside in that if you want to use the latest 2.0 stuff you might have to download and build the library yourself, and figure out how the linking stuff works, but that's not too bad and they have information about it on the website (http://www.sfml-dev.org/).

There are probably other decent C++ game libraries, but those are two that I've used personally if you insist on starting at a low level. You CAN also try to do plain OpenGL with C++, but frankly I think it's better to use SDL or SFML in combination with OpenGL so they can handle some of the basic stuff like setting up a window and listening for input.

 

[The Friendly Monster]

No need to stick to C++, the C based languages are all fairly similar, and the advantages to using a setup that's been designed around game creation can be huge.

I'd recommend XNA or LibGDX (Java) strongly, they are frameworks very well suited to creating games. XNA is probably slightly better but if you're interested in Android at all the LibGDX can't be beaten for me.

 

[Blizzard]

If you're going for other languages, sure XNA for C# and Slick2D for Java should be good. I haven't heard much about LibGDX but it sounds good from what I looked at!

 

[ThatObviousUser]

JavaScript is a really cool language.

 

[The Friendly Monster]

If you're going for other languages, sure XNA for C# and Slick2D for Java should be good. I haven't heard much about LibGDX but it sounds good from what I looked at!

I can't compare it with Slick2d but I've been working using LibGDX for the last 6 months or so and it's really excellent. Not only a great framework to work in for Android but also runs on the desktop, this means you don't have to load up the emulator and can get a really quick workflow going. I've also been able to work with my audio guy smoothly even though he doesn't have an android device or Eclipse installed.

Even the engine programmers at my old work use it for their pet android projects.

It's still not huge but the community is really helpful, I've had bugs I've reported fixed in the nightly build.

JavaScript is a really cool language.

I have to say I found Javascript quite painful to use when I experimented with it for a couple of weeks, for distribution it's the best, but performance and flexibility no way.

 

[Blizzard]

Andrex, that image is so huge, one might think you're almost trying to advocate HTML5.

 

[ThatObviousUser]

Andrex, that image is so huge, one might think you're almost trying to advocate HTML5.

What, me? Never!

*hides HTML5 t-shirt receipt*

I have to say I found Javascript quite painful to use when I experimented with it for a couple of weeks, for distribution it's the best, but performance and flexibility no way.

You have to get into a certain groove but it's very beautiful... if you ignore the warts.

 

[Blizzard]

Does anyone have general thoughts on best practices for triggering events that need to happen at or after precise times?

Say you have a monster that is supposed to change its behavior mode to a new state exactly 120 in-game "ticks" after something else happens. Those ticks don't have to be milliseconds. Imagine they could be any unit.

If you have a normal single-threaded game loop and handle this in the update section, you could do a naive approach of "If the current ticks are greater than when that behavior was SUPPOSED to change, then do the change now". The problem with this is that with different framerates, you presumably get slightly different results.

Is the best result to make sure that have a way to make actors simulate their behavior so you can say "Well this was supposed to start 10 ticks ago, so I'll just simulate the actor for 10 ticks to bring it up to the present time"? Or is the answer to use multiple threads and/or timing callbacks so that after 10 ticks, the monster behavior gets changed behind the scenes? Or is the answer just to say "your game shouldn't need that kind of precision"?

I feel like there must be one or two best practices about it, but I'm not sure what they are.

*edit*
I feel like this might solve my problem, and if not, it's still interesting reading: http://gafferongames.com/game-physics/fix-your-timestep/

 

[Alts]

I have to say I found Javascript quite painful to use when I experimented with it for a couple of weeks, for distribution it's the best, but performance and flexibility no way.

Care to elaborate on flexibility? I'd say Javascript is more flexible that most alternatives that are usually proposed in this thread, but I imagine you had something specific in mind when you mentioned that.

Does anyone have general thoughts on best practices for triggering events that need to happen at or after precise times?

I wouldn't use "ticks". I would use actual time units. That way a two ticks of 1/60th of a second will have the same impact on the logic as a tick of 1/30th of a second (variable step). The cited article mentions framerates as which the physics just break, but the game is effectively unplayable at those framerates anyway, so it doesn't seem like a legitimate counterargument.

 

[The Friendly Monster]

Care to elaborate on flexibility? I'd say Javascript is more flexible that most alternatives that are usually proposed in this thread, but I imagine you had something specific in mind when you mentioned that.

That was probably the wrong word to use. I found it very difficult to achieve stuff that's easy in other languages, especially for asset management and rendering, WebGL looks more mature now, but you still can't rely on it.

I wouldn't use "ticks". I would use actual time units. That way a two ticks of 1/60th of a second will have the same impact on the logic as a tick of 1/30th of a second (variable step). The cited article mentions framerates as which the physics just break, but the game is effectively unplayable at those framerates anyway, so it doesn't seem like a legitimate counterargument.

But 30 and 60 are both playable, yet with variable timestep the physics will feel different.

Fixed step for life. That article is awesome, and spot on. The ticks do correspond to real time too, except for on a massive spike.

You get totally repeatable predictable behaviour at any framerate, and your code will be tolerant to spikes.

The only exception I have are for timers, music and some UI elements, like 1 second transition I might rather always take 1 second.

 

[beril]

But 30 and 60 are both playable, yet with variable timestep the physics will feel different.

Fixed step for life. That article is awesome, and spot on. The ticks do correspond to real time too, except for on a massive spike.

You get totally repeatable predictable behaviour at any framerate, and your code will be tolerant to spikes.

The only exception I have are for timers, music and some UI elements, like 1 second transition I might rather always take 1 second.

I've never really felt a fixed timestep is worth the effort. I can't say I can feel that much difference when my game is running at 60 or 25 fps (other than the framerate being crappy), and if there'd be cases where those tiny details really mattered to the gameplay that would probably be a sign that the game is way too difficult.

There are some nice things you could do with a fixed step but seperating graphics and physics and interpolating between different states can get a bit messy, especially if there are things in the gameplay dependant on animations and the position of skeleton joints

 

[The Friendly Monster]

I've never really felt a fixed timestep is worth the effort. I can't say I can feel that much difference when my game is running at 60 or 25 fps (other than the framerate being crappy), and if there'd be cases where those tiny details really mattered to the gameplay that would probably be a sign that the game is way too difficult.

There are some nice things you could do with a fixed step but seperating graphics and physics and interpolating between different states can get a bit messy, especially if there are things in the gameplay dependant on animations and the position of skeleton joints

Fair enough. It may depend on the type of game you are making. I haven't had any issue like the one you describe since I am making a pool game. I certainly can't describe it as messy as I think it's a very elegant solution.

It's really easy to find places where it does matter, for example I have a replay feature where the entire game can be rerun using just the inputs. If the physics weren't repeatable exactly then this would not work. Likewise network play often requires the physics to be repeatable. For a more common example it is very difficult to write something like a drag function that will feel the same at 60 or 25. This isn't a tiny detail.

 

[beril]

Fair enough. It may depend on the type of game you are making. I haven't had any issue like the one you describe since I am making a pool game. I certainly can't describe it as messy as I think it's a very elegant solution.

It's really easy to find examples where it does matter, for example I have a replay feature where the entire game can be rerun using just the inputs. If the physics weren't repeatable exactly then this would not work. Likewise network play often requires the physics to be repeatable. For a more common example it is very difficult to write something like a drag function that will feel the same at 60 or 25. This isn't a tiny detail.

Yes being able to record input is one of those things that would be nice to be able to do. I did that for some tutorial segments in a game once, but then I just hacked the timestep and ignored the framerate, which wasn't exactly ideal but we didn't have time for anything more thorough.

 

[Blizzard]

Regarding my "ticks", they're literally time units scaled. And I think I even use doubles to represent them (at least in some cases), so I get fractional ticks.

Fair enough. It may depend on the type of game you are making. I haven't had any issue like the one you describe since I am making a pool game. I certainly can't describe it as messy as I think it's a very elegant solution.

It's really easy to find places where it does matter, for example I have a replay feature where the entire game can be rerun using just the inputs. If the physics weren't repeatable exactly then this would not work. Likewise network play often requires the physics to be repeatable. For a more common example it is very difficult to write something like a drag function that will feel the same at 60 or 25. This isn't a tiny detail.

And this is one thing that I'd like to be able to do, have replayable/deterministic/testable behavior based on given inputs.

If I understand the article correctly, using a fixed time step involves running an inner loop inside the game loop to consume discrete amounts of time, and storing the leftover time for next cycle...except that that will cause occasional jumps due to double fixed time interval updates in the same frame. The solution suggested is interpolation between multiple states. That seems really painful to me, and I'm not sure how feasible it would be for cases like AI-controlled enemies or things that are changing state in a complex fashion, rather than just moving in a certain direction.

Am I interpreting it correctly? I think I want to try a discrete-time-consuming loop like the article suggests, but just save the leftover time and see if any jumpiness is actually that bad, and then see what I want to do.

 

[tomakasatnav]

A couple of years ago I made a Sierra style parser adventure game during a game jam. It has the catchy name of: The Secret of Hutton Church of England Grammar School (the theme was based on random wiki articles)

http://www.tom-simpson.com/

Made using AGS, which was used in Gemini Rue.. I guess that's the most well known AGS game.

 

[IceMarker]

New concepts blog post on my development blog for my first game 20 MOONS!

Ditch the visual combination of the H/P and M/P. I know it seems kind of cool, but it's just confusing.

Well, it's all temporary for the most part, eventually I'll try and get a real pixel artist to help me out. I'd like to get a real team started to work on this game full force. (Or join an existing team and pitch the idea.) Also, I'd like to mention at this point I've settled on Stencylworks, at least for the first few prototypes/alpha. The actual game at the moment is nothing more than a title menu and a playable moving sprite on a field.

 

[razu]

I'm making my own game!

I've worked as a game programmer since 1997. I've worked for Codemasters, Sega and my last full time job was "Lead Programmer" at Bigbig studios, (as such I find myself somewhat less employed than I anticipated at the start of the year!)

Instead of leaping into another full time job I've decided to do a mix of freelancing into nearby developers and developing my own stuff. Way exciting!

I have an Android phone, a Samsung Galaxy S2, so I'm going to make a game on that and see what happens when I release it. To add to the hilarity, I'm currently developing on an NC10 netbook. Although I will be buying a decent PC soon enough, the NC10 is up to the job, which just goes to show you don't *need* super expensive/powerful equipment to make games.

I have literally just started, so, if you start following my blog, (http://jamielowesdev.blogspot.com/), you'll see every twist and turn of the story!

The blog is going to be a mix of game design and pretty technical code bits - when I solve a problem I'll share my "experience" and the solution I find. I only started the blog today, but already there's a bunch of code for reading the tilt sensors in native code, (which I found to be a pain in the ass to find out how to do...). I will make it look a bit more appealing over time too - it's a bit dry as it is now

So yeah, that's me!

Enjoy!

 

[Bamihap]

I'm making Kids vs Goblins. Which will be released very soon on iPad 2 & iPhone 4S. Later on PC/Mac.

More info

 

[beril]

If I understand the article correctly, using a fixed time step involves running an inner loop inside the game loop to consume discrete amounts of time, and storing the leftover time for next cycle...except that that will cause occasional jumps due to double fixed time interval updates in the same frame. The solution suggested is interpolation between multiple states. That seems really painful to me, and I'm not sure how feasible it would be for cases like AI-controlled enemies or things that are changing state in a complex fashion, rather than just moving in a certain direction.

Am I interpreting it correctly? I think I want to try a discrete-time-consuming loop like the article suggests, but just save the leftover time and see if any jumpiness is actually that bad, and then see what I want to do.

Well you would run the AI code at a fixed timestep, multiple times per frame, as well and save their positions at the last state (and you'd always be one cycle ahead of the rendering). Even then the interpolated values may not be 100% perfect but you're just interpolating between the movements of 1/60 of a second so you won't really notice it. The part where it gets painful is that you'll need to save a backup state of nearly every value with any visual significance and interpolate them if you want to do it properly, so you'd probably have to build your code with that in mind from the start.

 

[Red_taiyaki]

Let's see, I've worked on a freeware doujin visual novel, Aquae Crystal Clear Waters, and we're currently in the process of planning out our first commercial endeavor.

Although it's really just a hobby, I'm honestly surprised that our first visual novel received over 2,000 downloads through just limited word-of-mouth. So I guess I would consider that a successful venture.

 

[razu]

Well you would run the AI code at a fixed timestep, multiple times per frame, as well and save their positions at the last state (and you'd always be one cycle ahead of the rendering). Even then the interpolated values may not be 100% perfect but you're just interpolating between the movements of 1/60 of a second so you won't really notice it. The part where it gets painful is that you'll need to save a backup state of nearly every value with any visual significance and interpolate them if you want to do it properly, so you'd probably have to build your code with that in mind from the start.

Exactly. Everything that's displayable needs to have three values. A value for the latest frame, a value for the previous frame, and a value for the time of rendering, which is an interpolated value between the two frames. In this way, as you say, the rendering is always slightly in the past, by up to almost one frame, but always super smooth.

At this point the update is decoupled from the rendering, so you can experiment with a lower update rate. You may find that you can get away with a super low update rate, as long as the rendering rate is fast. Try it out.

It's also worth mentioning that this type of keyframed system works well as a network model. As well is interpolating between the frames, you can extrapolate beyond the latest frame. Which is handy when you need to generate data that you don't have yet.

 

[Nemo]

Looking at the future, is flash3D worth it?

 

[Blizzard]

For now I've tried the naive fixed step internal loop without interpolation. It seems to work great in that I can have 120+ fps and only ~60 updates per second, and scrolling/animation SEEMS smooth...but scrolling quickly against a giant background, I can almost imagine I'm seeing occasional slight jumping. I guess I need to stare closely at the screen and try some different settings, and/or maybe record a video or let someone else who's sensitive to such jumping download a sample .exe to see if it bothers them. I really don't want to deal with the interpolation. =P But I suppose the three-value thing sorta makes sense, aside from places where an actor completely transitions to a different motion scheme, and/or behavior, and/or animation, midframe.

 

[The Friendly Monster]

For now I've tried the naive fixed step internal loop without interpolation. It seems to work great in that I can have 120+ fps and only ~60 updates per second, and scrolling/animation SEEMS smooth...but scrolling quickly against a giant background, I can almost imagine I'm seeing occasional slight jumping. I guess I need to stare closely at the screen and try some different settings, and/or maybe record a video or let someone else who's sensitive to such jumping download a sample .exe to see if it bothers them. I really don't want to deal with the interpolation. =P But I suppose the three-value thing sorta makes sense, aside from places where an actor completely transitions to a different motion scheme, and/or behavior, and/or animation, midframe.

Aye well it may seem more daunting than it is. For me it's super easy as I'm just moving balls around, but even with fully animated characters perhaps you can get away with just interpolating the position and not the animation. Of course if you don't need to decouple it then don't, but it is a great solution to a huge range of problems that can occur from variable or naive fixed time steps.

 

[HP_Wuvcraft]

I'm making Kids vs Goblins. Which will be released very soon on iPad 2 & iPhone 4S. Later on PC/Mac.

More info

The art is really awesome.

 

[Bending_Unit_22]

It really annoys me that I lost it over a couple new laptop transfers, but I did make a short 8-bit style shmup several years ago with Gamemaker I believe it was. I'm not a huge fan of them so I'm not sure if it had been done before but basically the idea was WASD controlled the ship while the mouse pointer controlled an energy shield and energy bomb dropper (when you had them). I had only gotten 3 levels done but lots of energy shots was the name of the game, the gameplay was figuring out where to move your vulnerable ship and mostly impenetrable shield to at the same time.

I hope I find it again on some old SD card or external HDD because I had the "engine" mostly finished at the time. I don't think I'll have the spare time to do it again. It was certainly nothing at the level of Bamihaps game thats for sure.

 

[Blizzard]

Exactly. Everything that's displayable needs to have three values. A value for the latest frame, a value for the previous frame, and a value for the time of rendering, which is an interpolated value between the two frames. In this way, as you say, the rendering is always slightly in the past, by up to almost one frame, but always super smooth.

At this point the update is decoupled from the rendering, so you can experiment with a lower update rate. You may find that you can get away with a super low update rate, as long as the rendering rate is fast. Try it out.

It's also worth mentioning that this type of keyframed system works well as a network model. As well is interpolating between the frames, you can extrapolate beyond the latest frame. Which is handy when you need to generate data that you don't have yet.

Sorry about all the posts on this, but I had some further thoughts. When you talk about the three values, would implementing it be something like this:

* You have the previous fixed step actor values saved from a previous calculation (initialized by something in the beginning).
* You only need to run the actor update function once, to simulate physics or whatever, producing the current fixed step actor values.
* The interpolated values would be produced by a special interpolation method, rather than running a potentially expensive update operation again. The interpolation would just calculate the approximate position between the adjacent points etc.

 

[The Friendly Monster]

* You have the previous fixed step actor values saved from a previous calculation (initialized by something in the beginning).

Yes

* You only need to run the actor update function once, to simulate physics or whatever, producing the current fixed step actor values.

You keep running it until you hit the current time, so it could fire any number of times per render call depending on framerate. It's a good idea to have a cap on this value or else you aren't guaranteed to ever call the render function.

* The interpolated values would be produced by a special interpolation method, rather than running a potentially expensive update operation again. The interpolation would just calculate the approximate position between the adjacent points etc.

Pretty much, you interpolation should only care about manipulating the visual stuff. For example you can linearly interpolate the positions of the meshes between the two points you have simulated, or slerp the orientations. This isn't perfect, for example if something is changing direction quickly you may end up "rounding off" the path rather than it being sharp.

The more accurate (but expensive) alternative is to simulate fixed chunks of time until just before the current frame time, then simulate a small timestep forward from here (making sure just to simulate positions and not actually alter the game state or play audio or anything). On the next frame you discard this extra bit and go back to adding on whole timesteps until just before this new frame time etc. You end up doing extra work here but it will give you a really nice looking result.

 

[razu]

Yep.

When a new object appears you just set its previous and current values to be the same. You still interpolate, but between the same values.

Same for if the camera "cuts" to somewhere else. You wouldn't want it to interpolate in that case, (it might only be one frame, but you could end up with the camera halfway through a wall or some such mayhem).

I need to do this stuff for my game pretty soon. I'll write up the system, the thinking behind it, then code a simple example object. I'll post back when I'm done.

 

[FanTomasas]

Can someone explain me the workflow behind creating an object for 2D game, animating and adding it to the engine.

I thought it was possible for software to generate in-between frames in bitmap, but I can't the program which could do this. Is such a thing even possible?

 

[BlueMagic]

Yep.

When a new object appears you just set its previous and current values to be the same. You still interpolate, but between the same values.

Same for if the camera "cuts" to somewhere else. You wouldn't want it to interpolate in that case, (it might only be one frame, but you could end up with the camera halfway through a wall or some such mayhem).

I need to do this stuff for my game pretty soon. I'll write up the system, the thinking behind it, then code a simple example object. I'll post back when I'm done.

What are the real advantages of this? I mean, why would you do it?

 

[fluffydelusions]

Game no...Android app yes

 

[Blizzard]

You keep running it until you hit the current time, so it could fire any number of times per render call depending on framerate. It's a good idea to have a cap on this value or else you aren't guaranteed to ever call the render function.

Right, I meant that update stuff does not need called again specific to the interpolation over the less-than-fixed-time-step duration. Good call on the max cycle time. I actually already had a check that says that if the cycle time is something crazy (currently set to a second per frame, but configurable via a compile constant), it just gets lowered to a frame time instead.

The more accurate (but expensive) alternative is to simulate fixed chunks of time until just before the current frame time, then simulate a small timestep forward from here (making sure just to simulate positions and not actually alter the game state or play audio or anything). On the next frame you discard this extra bit and go back to adding on whole timesteps until just before this new frame time etc. You end up doing extra work here but it will give you a really nice looking result.

If I understand correctly from the article, simulating small timesteps can be an issue with physics simulations due to small changes in time (dt) being different/weird/inaccurate/whatever. That doesn't apply to me right now, maybe not even in the near future, but for that reason it sounds like it doesn't hurt to avoid it and just do the interpolation.

 

[Blizzard]

What are the real advantages of this? I mean, why would you do it?

Take a look at the article I posted: http://gafferongames.com/game-physics/fix-your-timestep/

It is kind of a long and possibly confusing read at first, but it has interesting stuff in it. As far as I know, the very short version is that if you don't use a fixed time step, certain things (physics simulations especially) can be weird or mess up. Because of this, it may be a nice idea to decouple the link between a single update cycle and a single render cycle.

The reason to interpolate is because otherwise, some main game loop cycles might run 0-1 updates, and others might run 1-2 updates, and if you are trying to do really smooth scrolling, sensitive people might notice slight jumpiness or jerkiness.

Yep.

When a new object appears you just set its previous and current values to be the same. You still interpolate, but between the same values.

Same for if the camera "cuts" to somewhere else. You wouldn't want it to interpolate in that case, (it might only be one frame, but you could end up with the camera halfway through a wall or some such mayhem).

Man, good point about the camera cut. I think I will add an optional parameter to my move methods (move to point, move in direction, move with X/Y offsets) that specifies whether they should clear the interpolation by setting previous and next values to the same thing, to avoid the situation you describe. Thanks!

 

[BlueMagic]

Take a look at the article I posted: http://gafferongames.com/game-physics/fix-your-timestep/

It is kind of a long and possibly confusing read at first, but it has interesting stuff in it. As far as I know, the very short version is that if you don't use a fixed time step, certain things (physics simulations especially) can be weird or mess up. Because of this, it may be a nice idea to decouple the link between a single update cycle and a single render cycle.

The reason to interpolate is because otherwise, some main game loop cycles might run 0-1 updates, and others might run 1-2 updates, and if you are trying to do really smooth scrolling, sensitive people might notice slight jumpiness or jerkiness.

I see, it was a good read. Basically we are trying to let the logical update run at a fixed speed and let the drawing happen more frequently. I still find the interpolation parts kind of unreliable, but I certainly have no idea how this technique behaves in practice. I may implement this later in my "engine" to see how it behaves. For now, running with vsync at a fixed timestep and letting it run at about 1000 fps I haven't seen a lot of differences respecting physics behavior (except a couple of bugs which I still have to fix but they are pretty simple I believe). Then again, being a top down game, the physics are quite simple or straightforward.

 

[Blizzard]

I see, it was a good read. Basically we are trying to let the logical update run at a fixed speed and let the drawing happen more frequently. I still find the interpolation parts kind of unreliable, but I certainly have no idea how this technique behaves in practice. I may implement this later in my "engine" to see how it behaves. For now, running with vsync at a fixed timestep and letting it run at about 1000 fps I haven't seen a lot of differences respecting physics behavior (except a couple of bugs which I still have to fix but they are pretty simple I believe).

I think that was kind of my feeling -- using a fixed timestep (currently about 60 updates per second) and rendering at whatever speed (60-140 fps for instance) seems to work fairly well.

But since it's early enough in my engine development for me to be able to modify it, I want to see if the interpolation handles the final bit of smooth scrollingness I'd like.

 

[Blizzard]

I don't know if it applies to this thread, but I just ran across this pixel art (image filter?) HTML 5 demo, and it's pretty doggone cool: http://www.effectgames.com/demos/canvascycle/

 

[fin]

Any artists in here? I'm having a hell of a time making art assets. 3D modelling in Blender is going ok, my skills arn't the best. But I'm getting by, barely. I've done about 3 models so far, now I have one that I sorta like. Still looks like shit though. I'm finding it difficult to make manufactured, man-made stuff. Having all the edges perfect, straight and logical. Making characters and faces anything that is smooth and uneven it pretty easy though.

I'm used to modelling in CAD software so I'm thinking I'm gonna bring a laptop home from work and try using Inventor or ACAD.

TEXTURING!!! FUCK! Talk about iterating. Never though it'd be so time consuming. I'm making so many mistakes it's not even funny. I've done about 4 or 5 different textures for this model and ugh, I dunno...

Basically I'm unwrapping the model in Blender exporting that as a png, and opening it up in GIMP and painting it. I've tried the Blender paint mode, and can't really get the hang of it yet. But the benefit there is that you can paint right on the model. So I might invest some more time into that.

I'm going for a futuristic Wipeout theme....needless to say I'm more of a programmer than artist. It's like I get 25% of it ok then the last 75% is fucked. Anyone have any tips on texturing? Like what are the steps that I could follow? Basically I'm kinda doing a base noise pattern to get a rougher look. Then painting by hand. But as you can see I'm not following the unwrapped model very well. I'm kinda tracing a guide in Blender to get my barrings, because an unwrapped texture looks very different to the model. In the end, I might just pay someone to make some assets for me. I've got a whole new respect for artists.

 

[Nemo]

I don't know if it applies to this thread, but I just ran across this pixel art (image filter?) HTML 5 demo, and it's pretty doggone cool: http://www.effectgames.com/demos/canvascycle/

Wow man, the actual art is beautiful. Every scene I look at inspires me to do things

 

[Blizzard]

Ugh, I spent like half the afternoon implementing the previous/interpolated/next value system thing into my engine actors, and game loop, and when I finally got everything done it STILL looks kind of jerky when I do fast sideways scrolling past straight vertical lines. I guess it's time for me to start trying to grab timing values and see if I can trace any stutters.

It's so sad that it was apparently nearly perfect when I used simple variable step timing instead.

 

[hoverX]

Here's a question for the programmers in the group. How did you find an artist to work with? My girlfriend is going to do a lot of the graphic design work, buttons etc., but we need someone to do some cartoony type work as well. We had a friend who was interested but he's too busy now. Is deviant art a good option?

 

[bumpkin]

Here's a question for the programmers in the group. How did you find an artist to work with? My girlfriend is going to do a lot of the graphic design work, buttons etc., but we need someone to do some cartoony type work as well. We had a friend who was interested but he's too busy now. Is deviant art a good option?

I was where you are, but really just never had the follow-through to actually find someone. First I was asking my cousin (an illustration major), but he backed out over his lack of pixel art experience. Then I turned to an online friend who does illustration, and he was just plain too busy with paying work. After that, I just kind of gave up.

 

[Blizzard]

After further experimentation, I think the sideways scrolling slight jumps may be due to one or both of the following:

1. Since I do not seem to notice tearing, SFML may be nicely flipping the buffers in such a fashion that render operations occasionally happen at slightly different times? FRAPS showed like 140 fps, though, so who knows.

2. The set frametime limit in SFML, even with a fairly recent library build from early February, may be a bit inaccurate on Windows (7). In particular, not using a framerate limit or setting a high one may produce much smoother scrolling. Setting the limit to something like 300-500 may end up with actual framerates in the 500-1000 range though.

In the end, I decided that scrolling at ~150 fps is smooth enough, and vsync can be used for super smoothness if people want. Hopefully if I ever make a game, other people's systems will work the same way as mine. =P

At this point, I have finished the basic engine porting and test program porting (the flying ferret/bat thing). Next, I want to look back in the thread and find the performance test I suggested to someone else. After implementing that myself, hopefully no tuning will be necessary, and I can move on to trying to design a good, generic, easy-to-use-in-multiple-games GUI/menu system.

 

[Feep]

Here's a question for the programmers in the group. How did you find an artist to work with? My girlfriend is going to do a lot of the graphic design work, buttons etc., but we need someone to do some cartoony type work as well. We had a friend who was interested but he's too busy now. Is deviant art a good option?

(shrug) Found my artist through DeviantArt, and she was awesome. Do it. I just posted a "Wanted" ad in the forums. Got over a hundred responses.

 

[Blizzard]

Last spammy post of the night. Here's a test of approximately 400 bats with animation and motion, no collision. They can run at a higher framerate but I'd have even less of a chance of attempting to record it with FRAPS, ha. This is the result of crappy quality x264 encoding followed by probably even crappier youtube encoding: http://www.youtube.com/watch?v=GlgmCD1gfro

 

[Kamaki]

Any artists in here? I'm having a hell of a time making art assets. 3D modelling in Blender is going ok, my skills arn't the best. But I'm getting by, barely. I've done about 3 models so far, now I have one that I sorta like. Still looks like shit though. I'm finding it difficult to make manufactured, man-made stuff. Having all the edges perfect, straight and logical. Making characters and faces anything that is smooth and uneven it pretty easy though.

I'm used to modelling in CAD software so I'm thinking I'm gonna bring a laptop home from work and try using Inventor or ACAD.

TEXTURING!!! FUCK! Talk about iterating. Never though it'd be so time consuming. I'm making so many mistakes it's not even funny. I've done about 4 or 5 different textures for this model and ugh, I dunno...

Basically I'm unwrapping the model in Blender exporting that as a png, and opening it up in GIMP and painting it. I've tried the Blender paint mode, and can't really get the hang of it yet. But the benefit there is that you can paint right on the model. So I might invest some more time into that.

I'm going for a futuristic Wipeout theme....needless to say I'm more of a programmer than artist. It's like I get 25% of it ok then the last 75% is fucked. Anyone have any tips on texturing? Like what are the steps that I could follow? Basically I'm kinda doing a base noise pattern to get a rougher look. Then painting by hand. But as you can see I'm not following the unwrapped model very well. I'm kinda tracing a guide in Blender to get my barrings, because an unwrapped texture looks very different to the model. In the end, I might just pay someone to make some assets for me. I've got a whole new respect for artists.

Now I'm no expect but I am doing 3d myself at the moment. Is that meant to be a hover bike of some sort? I'm not going to be much help with texturing, I'm not aware of how blender handles uvs specifically. All I can say is if that's meant to be metal it reads all wrong. Even without a spec map it just doesn't look like metal, try making an account here and using their textures as a base. Normally I'd bake an ambient occlusion map and use that as a guide for where I put my textures.
Regarding the softness of your hard edges you have two options, you either add more supporting edges like in this picture here.
Or you find the equivalent of Harden Edges in Maya for blender, basically it does something to the smoothing groups or normals or something. Just look around on the internet for that one.

 

[Blizzard]

Blender tutorials (preferably with the latest UI) should be a good idea to look at. I'm really busy at the moment, but if you search back in this thread, I think I mentioned a Blender IRC channel. If you're patient and nice in there, it should be a huge help. Just idle in the channel, ask questions, and learn.

 

[Crazymoogle]

(shrug) Found my artist through DeviantArt, and she was awesome. Do it. I just posted a "Wanted" ad in the forums. Got over a hundred responses.

(Note to self: bug feep when needing an artist referral)

 

[The Friendly Monster]

After further experimentation, I think the sideways scrolling slight jumps may be due to one or both of the following:

1. Since I do not seem to notice tearing, SFML may be nicely flipping the buffers in such a fashion that render operations occasionally happen at slightly different times? FRAPS showed like 140 fps, though, so who knows.

2. The set frametime limit in SFML, even with a fairly recent library build from early February, may be a bit inaccurate on Windows (7). In particular, not using a framerate limit or setting a high one may produce much smoother scrolling. Setting the limit to something like 300-500 may end up with actual framerates in the 500-1000 range though.

In the end, I decided that scrolling at ~150 fps is smooth enough, and vsync can be used for super smoothness if people want. Hopefully if I ever make a game, other people's systems will work the same way as mine. =P

At this point, I have finished the basic engine porting and test program porting (the flying ferret/bat thing). Next, I want to look back in the thread and find the performance test I suggested to someone else. After implementing that myself, hopefully no tuning will be necessary, and I can move on to trying to design a good, generic, easy-to-use-in-multiple-games GUI/menu system.

Aren't most people's screens going to be running at 60? What are the benefits to not V-syncing?