It’s been almost a full year since I last posted here, and to say the least: RPGThing kinda hit a brick wall with my having to do schoolwork and all that. On the bright side however, I’ve done a lot of game programming for school, namely the two semester projects I’ve done have both been rpg styled games.
The first game I worked on was going to be in the style of the Diablo series, but was changed half-way through the semester to a side scrolling style (the designer on my team likened it to Maple Story, a game I have no experience with). The team name for this one was Team Reckless, and we had a total of four people.
This game turned out as an atrocity of code and unfinished mechanics. The first problem I had with this was my and my teams plans – we planed for something far too big to create in a single semester. Simple as that. It was our first (and probably worst) mistake.
The second problem was that teams needed some form of networking component in our games. This was a major issue in that we were never taught anything about networking or network programming seeing as we were still freshmen students. Since our game started based off of Diablo, that’s the kinda of networking I was trying to accomplish (I was in charge of the networking and core mechanics) – one game would act as a host for a group of other games. The way I went about handling this was with asynchronous networking, where the networking module works on a separate thread from the main modules so it can receive data independently, and the main modules can access the data when they need it. I started work on the networking about halfway into the semester, and never finished it. For all the time I was working on it, more and more problems kept arising, none of which had any reason to exist when I stepped through the code. Because I was working on this for most of the semester though, the core mechanics for the game went unfinished.
What we got in our programming classes was nothing like that. What we got was this: when someone asked a question, the professor would walk over to the computer (we have small classes in computer labs), ask why the student did something in a certain way. To which the student would say (in a variety of ways) that they don’t know what they’re doing, and no one was teaching them anything. After a few more exchanges the conversation would reach back to the problem at hand, and the professor would say something along the lines of “that’s a good question, maybe Google would know.” Because of this, me and the handful of other students who know what they are doing (as well as a new adjunct professor for the CS department at school) have been volunteering to help students with actually learning how to program. Luckily I have a tutoring position set up for the spring semester so I also can get paid for helping them!
That and other problems aside, since this game turned out so bad I spent a good bit of time researching game programming during the summer and I managed to learn quite a lot about it. So now I know a good bit about how to set up different core mechanics for games! even though I still have trouble with the simplest of collision handling (HANDLING not DETECTING! there is a difference!), i.e: 2D bounding box. >_>
.
The semester project from this past semester was a Rouge-like rpg based around NetHack (site: http://www.nethack.org/). For this project I was with Team Ironclad Turtles (a total of three people), and the game’s name was Pixellated Blimp Troopers. I (for one) can’t tell how obvious it is, but we got that name from a random video game name generator (found: http://videogamena.me/).
For this we used XNA in order to speed up the development process. To say the least, it worked wonders. Combined with what I learned over the summer, this game got to be quite a good bit ahead of the other game. A big part of this project was a random floor generator, which I (so very wittily) named “DunGen”. I managed to get it to the point where it was almost fully functional. It generated some random rectangular, circular, and L-shaped rooms and placed them around the map, but I couldn’t quite get the connecting halls generated. Instead of finishing it, I figured working on the game itself would have been a better use of time.
The game itself ended up pretty nice by the end of the semester. I changed around one of the levels generated by DunGen to have halls so I had something to test on, and I added sprites from there. For sprites, I made a basic sprite scripting system which stored a lot of information about the sprite in text files. The system made it quick and easy to make sprites for the game; so fast in fact that drawing the 32×32 tiles for the sprite took longer than making the sprite file!
There’s not really much more to say about the game – I don’t have any significant complaints or anything about it, but I will say this: we are planning on working on this game more in the future, perhaps just to see what we planned for it get done.
