Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Member Since 28 Nov 2004
Offline Last Active Apr 22 2014 10:55 AM

Posts I've Made

In Topic: Game a Week

10 April 2014 - 01:19 PM

I like this video on an 11 day level design


This video is really nice.  This gives me another idea.  I usually focus on programming, game component design, and visualizing the games during the game a week, but this makes my skills kind of one-dimensional. Instead it would be interesting to focus on a completely different sub-craft of game development, like level design or asset creation (art, music, other?) for a week, and then do a write-up on what's learned as well as the results (no actual game, just whatever content is iterated on or created).  This will help to understand the other sub-crafts of game development deeper for when I work in teams with artists/musicians, etc.  It will also be a good way to become familiar with those pipelines and tools in those fields.

In Topic: Game a Week

09 April 2014 - 10:48 AM

Hey man, Mondongorongo here; i noticed you linked my blog up there, thanks for that. 


Hey, no problem, event though I can't read spanish well it's still nice to see your games.  I also added your name in the list :-)  Thanks for your input!!


you have to understand your limitations and know that you can't aspire to build the WoW killer in thosae 7 days


I think this is really important.  I've been a programmer for a while, and I still find I underestimate the amount of work required for things.  I think that for aspiring game developers (indie or not), it's important to be able to predict the amount of time it will take to work on something, whether it be contract work or reporting to your manager how much time you think a task will take.  This is a skill, and it takes practice to improve that skill in time-estimation.  Writing more and more games means that you can start seeing what is realistic to accomplish in a certain amount of time versus what is unrealistic, and this is always helpful for any project that's taken up.


the only ones still making money are the quick one game a week apps that I did over a year ago whilst the ones I spent months working on with paid for assets are making nothing


Wow, this is really interesting.  Can you think of anything that you can attribute to this?

In Topic: Game a Week

08 April 2014 - 08:06 PM

I've never heard of a game a week or every two weeks. I've only heard of jams and the one game a month ( http://onegameamonth.com/ ). I'd think that the failures you get with one game a week or two would be the same as the month long one, but would likely run the risk of you getting burned out faster than most programmers.

Yea, there have been some recent blogs and ideas for one game a week floating around.  The goal is for people to start writing games, and start small so that it's not as easy to fall into the big ideas trap (have a great idea, a small team...3 months later realize it can't be done with the resources, and there is still nothing to show for it).  The idea is that if you design for small week projects ,you will get your creativity out, start prototyping your ideas, and hopefully gain experience in writing games/programs.  There are other benefits, but those are just some.  Thanks for the link, I think I have heard of it but I forgot all about the onegameamonth.


Awesome, will take a look.  I looked at it a little bit and he has some great things to read in there.  Thanks!


Thanks for the links, I'll edit them in the original post to keep track.

In Topic: Voxel Theory & Practice

12 August 2012 - 11:04 AM

Wouldn't it be faster to start from the bottom

I don't remember how the Laine paper reconstructs it, but I do believe the Crassin paper does construct bottom-up. They treat the fragments produced from the graphics pipeline as leafe nodes of an octree, and then build the tree up from these leaf nodes in parallel (I think on the compute shader). Essentially the idea you mentioned.

IMHO, building bottom-up or top-down depends on a few things: 1) you use the right construction that makes sense for your application, 2) the construction method you pick is not overly-complicated for your problem 3) parallelize node construction as much as possible. (important if your on the GPU, perhaps not so much if you're on CPU, and perhaps not important at all if it is done as a preprocessing step and you don't have dynamic objects).

Obviously when using the pipeline, it is faster to construct bottom-up since you have the leaf nodes after the fragment shader (all in parallel), but if you're on a CPU or something, you may just want to construct the tree top-down since that way is generally easier.

In Topic: Voxel Theory & Practice

11 August 2012 - 10:59 PM

I guess I'll need to read into the fundamentals of voxels and octrees first to gain an understanding.

I really love octrees. They are used everywhere. You can also experiment with a quad-tree in 2-dimensions if you are coding one up. It may be easier to visualize the tree that way.

Also, I edited my first post. When I said you don't need 3 numbers for cubical voxels, I was referring to the numbers corresponding to voxel height, width, depth. you will still probably use three numbers to access the voxel or derive the 3-d location for the voxel (index values are fine if it is a grid).

Ooo Ooo, sorry for a TON of edits, but I also found this page which might be helpful, especially the links which are referenced: