|
Yay! Server is back online and so am I, with a dedicated connection. This will be a good thing heading into the new year and should allow for things to continue to move forward. I was thinking of doing a year end review but I'm not sure if it'd really be all that beneficial for anyone. I mean, I reflect enough as it is and it seems like everyone is talking about year end wrap ups or recaps and, well good for them.
I've started work back on Barricade currently. I'm working to finish some of the game mechanics that I did not finish during work on the proto-type. I worked on it a couple of days last week and some decent headway.
I switched back to this for two reasons. One, I decided to port my existing code base over to Qt in order to get things independent of a specific OS. This will allow for the editor to be cross platform as well as the engine itself and will hopefully open up a wider user base.
I've never used to Qt before, but I'm getting the supposed manual and am going to start learning sometime in the next month. In the meantime, I decided to work on the Barricade demo some more. The second reason being, I have not been able to make a solid decision on the next iteration of the engines state management. I've gone through at least 3 redesigns this year, with the core system staying some what the same, but the implementations being very different. I need to buckle down and just make a decision for this as it's been holding back progress from other areas for quite sometime now.
On a more personal note, I usually find it hard to focus around this time of year, and this year is no exception. It's almost tormenting to simply want to put everything off until the new year and just go out and live it up with everyone, but there's times and places for those things, not every day.
There has been quite a bit going on since my last post. I moved last week, downtown, into a new apartment, which is quite nicer then the last place I was staying. The building is older, but it's kind of interesting to be in one of the first buildings built in the state. I haven't had any ghosts visit me, but that's all good and well I suppose as I don't think I really know how to entertain ghosts. I'm also finally not in a basement apartment, which I had been the last two before this one. Instead, I'm on the top floor and there's an awesome view of some trees and downtown streets from my many windows. Which is all well and good, it did suck having to move all my shit up four flights of stairs though. Many thinks to Dan and Sam for helping me move my stuff.
As I get settled I'm hoping to really get focused back on getting the engine to the 1.0 bench mark for beta by the end of the year. As I've been writing about for a while now, I haven't really been as focused as I should be. The good news however is that I really feel at home in the new place and feel a lot of focus starting to come my way.
I'm also really wanting to finish the Barricade Proto-type to showcase the engine and want to start working on my personal game project. With things being so close to completion I've found it really hard to stay the course, but after coming this far, it wouldn't make any sense to give up.
Work on the website needs to continue as well, although I'm thinking that it will take a back seat the engine now, which wasn't the approach I was taking the last few months. There's still a lot of work to do there, but things will be completed with time.
Not really much more to write as of now.
Well, I modified the blog layout to resemble the theme on the Main website so now things look somewhat uniform.
I've been doing way too much messing around the internet as of late and not enough coding on the engine. I'm also going to be moving again next week, so things are a little hectic right now.
I'll be moving into the heart of downtown Des Moines for the 3 time in four years. I finally got a decent apartment down there though, so I plan on staying there a few years. Which will be an awesome change because, well, I tend to move a lot.
So I'm supposed to be finishing up game state management, python interfaces, and working on the next version of Scribe. Those three things will put me to what I'll be considering a 1.0 version of the engine. It'll be the bare nuts and bolts, and will allow me to make games.
I'm then going to be working on a side scroller and completing the Barricade Proto-type, which has stood still since April.
Then there's the networking layer and the effects layer to take care of, which I'm considering extra at this point, but really is a necessary part of any modern game engine.(Hell even 10 years ago.)
I'm really aiming to have all of those tasks completed six months from now. Those things will be doable, but are going to require extreme focus on my part. Especially as I'm trying to do the gathering of gamers thing and develop my site community. I'm also going to be having to have some beta testers come on board and help test things.
If anyone is interested in beta testing email: support at decipherone.com
Still working on the gamepad functionality. I still haven't had a lot of time to get things done this week. I decided to go with a better organized, but stream lined version of what I want for a final implementation, mainly because I really want to move on to getting the gui class stated and completed and then finish up the Barricade demo. Going to go play some Bioshock before bed for a little while. Later.
I'll be glad when spring is finally here. Don't get me wrong, I love snow, but after it snowing at least two times a week for the last two months, I'm just tired of it.
I start my new job tomorrow. I'll be working for Scientific Games as a service technician for lottery computers and networks. It should be exciting, seriously! Plus it will allow me to provide for my kid and for game production as well, it's got many benefits and will be the coolest job yet to date.
Ok, now back to some game production notes. As stated in my previous post I was to spend the weekend working on implementing dircetinput and Xinput into the engine. I sat down to start that yesterday, but I ended up getting side tracked from that and working on fixing the bullet path code for barricade, which I managed to fix. There still is some adjustments that need to be made to the speed of the bullet as the dot product changes so as to have the velocity of the bullet remain seemingly constant. Kind of a trial and error thing there to get the feel right. I also started restructuring some of the management components for the engine, such as the command console and organizing a better structure for game state management. Currently I just have it setup as IDs, but have been wanting to change over to a stack like implementation for state management. I started designing that also.
Today, I'm fighting a cold "AGAIN!", it's like every two weeks I get a new one. I don't get it. I quit smoking cigarettes again months ago, I work out almost every day, get plenty of sleep, eat lots of veggies and fruits, yet still manage to get a cold regularly. It's annoying to say the least. Especially because it causes me to not feel as focused as I should and I get side tracked a lot more easily then I normally do.
With that excuse in your mind now, I started to get the game pad stuff added into the engine. I'd say I'm about a quarter of the way finished with it, but I decided that I'm going to wait to finish it because, well, I'm having trouble concentrating because of the cold. So, instead, I'm going to take it easy the rest of the day. I probably won't get back to it until Tuesday night, as I've got to work and spend time with my son on Monday, but that's ok, things are still progressing and it shouldn't take very long to finish up the game pad stuff.
Ok, I'm going to go lay down now.
So, this week has mainly been presenting the game in it's current state to other team members and those who attended the Game Developer Forum meeting on Tuesday as well as ongoing assessment of where to take things. I got some of my tax money back on Tuesday as well and yesterday, along with paying some bills and taking care of a few other necessities, I picked up an Xbox 360 controller and a wireless 360 peripheral receiver for Windows. So, today and for however long it takes me over the weekend, I'm starting to implement DirectInput(for non 360 gamepads and devices) and XInput functionality into the engine. I'm also going to fix a few things that I thought of at the game developer forum meeting and that was suggested to me by some of the group participants as well, but those fixes shouldn't take very long. Away I go.
I took a few days off last week from focusing on the code. Mainly the weekend as I spent time with my son and nephew. After having that time away and then coming back to work on the game again, I began sifting through the code for the demo and thought to myself that it's now time to start refactoring code.
The demo , in it's current state, is an ugly mesh of global functions, the physics code for the block management and bullets are stuck inside places that don't really make sense and use math functionality that can easily be stuck into a component class for reuse, and it's all large enough where it's hard to manage and can take anywhere from 30 secs to 2 minutes for me to find a certain section of code at times. These are all bad signs.
I was planning on waiting to refactor until I was finished with the proto-type, but the code is getting in the way of productivity now and the addition of a vector class and a generic physics class to the engine in general will be a definite benefit. I'm also going to take this time to go a head and begin implementing the support for game pad functionality into the engine.
Doing all this stuff also has a second function. It's going to allow me to do some more experimenting with the wide area collision management system as well as allow some time to do additional research as I've yet to finish that part of the game. Also the addition of the physics class for the engine will allow me to handle multiple types of physics calculations for a single function that I can switch between in certain instances which will add for some interesting play mechanics.
This means that a public demo has the possibility of being delayed a little, but hopefully not, as once these items are done it should actually speed up things nicely, it'll also make for a more complete demo and hopefully save time in the overall development of the game once we start production of that.
So, I found the error that was causing the release build to throw an exception. It was an instance of a class that was created for testing and referenced in a small local part of the code and for some reason alt tab-ing out of the app was causing some sort of corruption, so I got rid of it. Now something else weird is happening. Frame rates are dropping drastically in areas that contain hit test for mouse detection. I've never had problems with this before, and it only happens if I load the Barricade prototype first. If I load another of the demo's that are accessible in the engine, even those that use hit testing, it doesn't produce the same result. I spent a long time looking over the code. I even compared it to previous versions but couldn't find anything. I'll find out what it is or go blind trying.
This weekend is kind of crunch time, but I've got my son this weekend, so I probably won't get that much done code wise. Which means I need to concentrate a lot tomorrow and Sunday night and Monday night. The manager at the place I was supposed to start working this week also hasn't returned any of my calls. It's got me a little worried, but I suppose as Bob Marley says, "Lord I've got keep on moving, Lord I've got get on Down!" so I'll just keep my spirits high and hope for the best, prepare for the worst. I really want to start working though, but I guess I just have to things as they come, is all anyone can do.
So, I got burned out on working on the block dropping management system on Sunday after I fixed the issues previously stated and there was still errors happening. The system is going to need a complete overhaul. I've got the right ideas, but I'm missing some functionality that I had initially tried to put in(mainly keeping track of the blocks that surround every block), but for some reason didn't work like it was supposed too. So, I need to fix that and then go ahead and redo the entire system.
Instead of working on that, I've been getting the bullet class up to par. I've got bullets firing now, got the bullet chamber up and cycling through bullets, and have the bullets following the correct vectors to where the aiming reticule is currently located. I also got a good speed for the bullets to travel at. One where they are just a blur, but you can still see them, because well, it's a game you need to see the bullets flying through the air. I've next got to get the damage inflicted on the aimed at blocks, which will require a little bit of ingenuity as conventional intersect testing isn't the solution.
Here's a screen shot.
Click For Bigger
I've also ran into an interesting problem with release builds that I can't put my finger on. It just started happening with this last build. And I can't reproduce it with a debug build. When I alt tab out of the app or minimize it a few times, it triggers an unhandled exception. As far as I can trace what's happening on the stack is that for some reason, the application is calling the destructor for a sprite when alt tabing back into the application. This doesn't make since because it shouldn't be being called. It'll definitely require some research. I think I may just try rebuilding though and see if it still happens, a bad build possibly? Who knows.
Only a week left from today until next weeks game developer forum meeting in Ankeny, and while I'm close to where I want to have the game by that time, there is still a lot to do. I'm kind of burned out on it too and have been wanting to take a day off from working on it, but I just can't seem to keep away. Especially because the weather is horrible, it's cold and snowing, and because the company I'm supposed to start working for this week hasn't called me to get started yet. And plus it's too much damn fun to work on. I think I will take tomorrow off though.
I was up very early today and began setting back to work on the second phase of the wide area collision. There were three problems that I came across during that time and after resolving them I figured I was done. I tested it a few times and after a while I began to notice the blocks were doing some interesting things. Interesting meaning doing things that they shouldn't have been doing.
Things being that they were falling in the correct spots, but for some reason certain blocks were only partially falling to the point they were supposed to before being marked as at rest, so they were being suspended in mid air, which meant a collision was happening and they were hitting the blocks directly below them, as the system is designed to check for, but I was a little confused on why. So, I took a break from the collision for a while searched for some new fonts, did a little bit of texture mapping, had lunch, and then came back to try and tackle the problem.
I've found that from time to time when I do get stuck, it's a good approach to move onto something else, and then I can come back later and look at the problem without as much stress and a fresh set of eyes. In this case I was actually going to finish implementing the bullet class so I could shoot multiple blocks to help figure out what was going on, but as I sat down to do that it dawned on me that my design for a two phase wide area collision system was flawed.
In the current system there are 2 phases, phases in this instance can also be translated to 2 large code blocks.
The first phase consists of looking to see if a block is marked as no longer being collide-able. If it is marked it's then marked to be destroyed. It then cycles through every block checking to see if it is in the same y cell column and that no other blocks would stop that block from falling. If those criteria are met then the block is marked to fall, grid location is updated depending upon the size of the block being destroyed, (the size of the block being destroyed tells us how many cells our other blocks should fall), and that's it for the first phase.
The second phase is where actual collision tests take place based on sector locations as well as actual updating of the blocks positions. Designing these two parts separately was a mistake however because of the way in which the blocks are placed on the grid to begin with. It's done somewhat randomly, placing blocks where there is no block and where there is room to place them. Meaning that having the second phase executed outside of the first phase causes the wrong blocks to fall first. This results in premature collisions, which results in the suspended blocks.
For example :
|_2_|
|_3_|
|_1X_|
Block one is the one being destroyed and blocks 2 and 3 are marked to fall.Because the blocks are out of order, when we reach the second phase, block 2 is checked for collision first and moved first, meaning, that since block 3 hasn't moved yet a premature collision happens. This may not happen every time, it depends on where the block is that is being destroyed and where the blocks that are falling are located, but it's an obvious design flaw.
So, the solution then, which I'll begin working on after this post is to combine the two phases together. Even though the blocks are iterated through in the first phase, we start with the one directly above the destroyed block, so, if I start moving these blocks as soon as they are found, then the premature collisions should no longer happen. At least that's what I'm thinking right now. I guess I'll find out soon enough.
Ok, so I'm still hard at work and making decent amounts of progress.
Yesterday, I took the time to fix proper scaling of the bots in proportion to their game display size in accordance with their actual size on the sprite sheets. I also remapped the textures so that they are now more precise and there are only some minor fluctuations now that your average person probably won't notice, just very slight dither blurring at certain translation locations of the sprites. I was thinking that it's due to floating point error, but I'm satisfied with it for the demo. That actually took most of yesterday to complete and I think I did some more things as well, but I can't really remember so they must not have been to vital.
Today I set back to work on the wide spectrum collision detection for the blocks. What exactly does the wide spectrum collision detection entail you may ask. Well it simply keeps track of the blocks that aren't resting(as in falling), what sector(s) of the block placement area that the block is in. It then looks at other blocks in the same sector and determines which one is underneath a falling block. From there a narrow collision is checked against that specific item. If a collision happens, the falling item is then marked as resting. It works out pretty good.
The second phase of the wide area collision has to deal with updating blocks when blocks below them are destroyed testing if other blocks prevent certain blocks from falling and then entering into the first phase. I guess you could really reverse the numbers for the phases or just call one the top phase which is what I have to finish yet. I got some testing and tweaking to do to it yet. Hopefully that'll be finished tomorrow with minimal effort.
In the meantime, here's a screen of the first phase in action. After the blocks are initially placed on the grid, the collision system now kicks in and the blocks land on top of each other. If you scroll down and look at the picture of the post where I finished the initial block placement, you'll be able to notice the difference.
Click it for a bigger pic. More Later.
Damn it feels good to be a gangsta. I finally, after about a week of doing research into using Separating Axis Method for collision detection, and working on the collision systems for the engine and for Barricade on a whole for about three weeks, finished the narrow pass collision detection. I want to do some cartwheels right now because the whole process was kind of starting to get under my skin. Reason being, I'm no mathematician by any means and the only resources available out there are written from a math theorem perspective. But anyways, I've complained about the process too much as I did it, which if I didn't complain as much I probably would have been finished faster, but it's done.
So.. I can finally go back to concentrating on building a wider spectrum collision management system for the game barricade. They systems already about 75% done at this point, I just have to continue to tweak a few more things. I was worried I wasn't going to make my goal of having a playable proto-type for next months game development forum meeting, but it looks like things should be a go. There's still a lot that I want to get done before an official public release however, but that will hopefully be ready by the first of March or round abouts.
Things that still need to be finished at this point include, but probably aren't limited too..
Finishing the Wide area collision management system.
Remapping some key textures for sprites and animations.
Getting the texture fonts mapped and loaded.(Currently using bitmap fonts for the game.)
Getting some temp sound effects for the demo and getting those inserted into the correct places in classes and adding the proper audio updates.
Replacing the temp graphics made by me with actual graphics made by Dwayne for the game.
Implement the bullets class and resolve bullet to block collision.
Add the ability of blocks to drop powerups and other items upon being destroyed.
Implement chain effects for blocks(Not sure if this one will make it into any of the demos because of lack of information on how this is supposed to work regarding how damage effects different block sizes and Mike Pool is no where to be found for comment.)
Implement powerup effects.(Not sure if this will make it into the demos for the same reason mentioned above.)
Implement gamepads.
Implement general scoring system for the demo.
Create a general level manager in charge of dynamically selecting play arenas and calling the functions related to generating blocks upon the start of new rounds.
There's a lot more stuff to do from there, but once those things are taken care of, a public release of the proto-type will be done. Then we'll have to see how things go from there.
I know after that I need to get back to working on the editor scribe and really start focusing on having the engine be more dynamic and taking care of all the design elements that I made sure to put in place last year. I'll post some screen shots later in the week once I start getting more things up on the screen.
Seeing as this is the first game I've ever programmed using the game engine I've been building over the last two years, I knew I would have a lot of problems to solve. I've gotten over a lot of hurdles that I've come across, and I'm learning more everyday, plugging away everyday, but some days, I just want to have it done.
A lot of the stuff are design patterns not common to me. Essentially what I'm finding is that designing systems for large numbers of objects that require constant updates and such seems to become more and more complicated. The more problems I solve, the more I seem to come across as well. Once again, I'm still making progress, but it's requiring a lot of testing, a lot of small tests for implementing new systems and unfortunately, because I'm learning as I go along, a lot of re-writing things as well.
The most important thing that I'm learning I think, is that sometimes it's important to take the time and think about a problem from many different angles. If you don't you can find yourself designing an entire system that can later get tossed out, and then you end up losing a lot of time that you can't get back.
Things slowed down a little bit on the development front this last week. I didn't make as much progress as I had wanted because of the problems mentioned above. This simply means I'm either going to have to learn to more efficient, or have to end up putting in more time so that I can try and make up for lost time, or both. At any rate, I'll have some screen shots and more meaningful posts later in the week, maybe even a video, but we'll have to see how far I make it. Also, I've been aiming for an end of the month completion, but it may end up being a few weeks beyond that, but I should have some game play by the end of the month for sure, I just want to take the time to polish things up, but I do plan on having a play session at next months Game Developer Forum here in Ankeny Iowa. Back to coding.
Ok, I ended up spending the weekend hanging out with my son and my nephew so I didn't do any coding. Today , aside from a couple hours this morning that are my daily exercise, eat, and shower routine and a few minutes to make this post, I'm pretty tied up.
Yesterday however, I finished writing the block management class and finished writing the block generation and placement for the game Barricade. Here's a screen shot.
Clicky For Bigger
It felt great to finally get this finished. Tomorrow I'll be starting on something new for the game. More later.
|
|
