If we don't want to add a certain feature, we don't have to add it it's as simple as that! And it's pretty rare for us to disagree strongly about any significant issue, so it's easy for the two of us always to be fully committed to the game that's taking shape. This is very satisfying, and keeps things fresh plus, the game really is your baby, since you're not just working on one tiny part of it.īeing a team of two means that we never have to compromise our creative vision for the game.
Ryan does the coding and I do the graphics, but other than that anything goes. Matt: For starters, with such a small team it's great that you're heavily involved in everything: initial concept, game design, level design, character design, testing, marketing, support. We were all newbies once! Other people helped me get my start, and I'm trying to return the favour. Also, after switching from VB to C++, I found that C++ game development websites were sometimes lacking in the newbie-friendliness department I hoped that the Game Programming Wiki would be a place where aspiring developers could come and ask questions without fear of being looked down upon. That's why I thought it would be a great idea to use a wiki-format: People can simply add new tutorials to the wiki on their own, and I don't have to deal with the formatting headaches myself. People often sent me tutorials to add to the website, and it quickly became too much for me to handle on my own.
#Rage bots professor fizzwizzle how to
It grew to be quite popular (in the VB game programming community), and it was a very friendly place where newbies could come to learn how to program games.
I've always been a hobbyist game programmer, and back in the late 90s I started a website called Lucky's VB Gaming Site. Ryan: The Game Programming Wiki started a few months before development began on Professor Fizzwizzle. This makes it easy for me to do all my clean-up work on the sprite (mostly cleaning up the ink lines generated by LightWave) before shrinking it down to its final size. One other thing I do, which is pretty standard I'm sure, is render everything much larger than the final version - usually at four times the size, but sometimes even larger if I'm doing significant post-processing. I think this is particularly important when you're going for a simple cartoony look. I often had to simplify my models so the sprites would look less cluttered. As for modeling something that looks good when rendered as a small sprite, one thing is obvious: it really helps to limit the amount of detail you include. I've been more conscious of this while working on our current game, and it often yields cleaner cel-shading as a bonus. and since I'm still learning, I'm already a sloppy modeler! In making Professor Fizzwizzle I often made the mistake of using too many polys, which resulted in models that were frustratingly slow to pose.
Matt: Unfortunately, not having to worry about the number of polygons can lead to some really sloppy modeling. The in-game story that you see is his creation entirely When he first showed me the rhyming version of it, I thought it was amazing! Combine the silly plot, the rhyming verses, and the excellent illustrations, and you've got yourself a memorable story! After these rough initial ideas, Matt really fleshed out the Professor and the Rage-Bots, giving them the character and spunk you see in-game.Īs for the story of the Friend-Bots turning into Rage-Bots, Matt really took off running with it. I had originally intended to use a vocoder (my uncle created his own, which I could use) to give them robotic-sounding voices, but we didn't end up doing that. The Rage-Bots were chosen because I figured they fit with the Professor theme, and because they would be fairly easy to come up with sound effects for. I decided that a Professor would be a good fit because he would allow us to have gadget-like powerups that could be used to add complexity to the puzzles. Ryan: It started with the "platform puzzle game" idea, but it was obvious that we needed a protagonist.
0 kommentar(er)
