|
I've got a lot of over time to work the next month or so, and as such I won't be getting a lot done I'm guessing. Although for days that I don't work, I will be fully concentrating, but I'm just going to try and not get burned out on things.
I started working on the GUI for the engine this week. I didn't make a whole lot of head way and I still need to finish the other two systems previously started, but the GUI will tie into both of them, and it seemed like the logical next step at the time.
It's a pretty standard GUI, the only somewhat different thing is I'm planning on making it adaptable via python scripting, which is yet another system I need to finish.
I really need to take some time over the next few weeks and re-asses things for the engine once again, get things back on track with a plan of attack, before they get too out of control. Make a detailed plan of action but before that, I'm going to play some Team Fortress 2.
Not really much to write. I'm still working on the state management system, when I have time. I have made head way in solidifying a workable idea for the system that took the general concepts I had before and makes them work. Now I just have to find the time to write and implement it.
The more I work on the engine the more I think that I may not continue to build tools myself once I decide to move into the realm of 3D. This may be a fleeting thought, and I'm definitely going to complete a version of the engine that is complete and capable of making 2D games, with 3D elements, but I'm not sure if I want to continue working on developing tools from the stand point that I have been over the last year and a half. This may change however as hopefully with the completion of the engine and current tool set I'll be able to start making the games that will allow myself to be an indie game producer and actually be able to concentrate on both tools and games, but currently, 90% of development time has gone to the engine, and the rest to actual game concepts. If it ends up that I'm not able to support myself making games, or end up working for another company doing games, or keep my current job for a long run, then I want to shift my focus back to why I started this crazy shindig in the first place, making games. I also realize I'm not on the fore front of anything, I'm simply remaking things others have made, although possibly slightly better, or worse.
Of course the whole concept of writing my own engine and tools is to be able to have complete IP freedom, as well as to have a better understanding of game engines and the development process in general. Also, eventually, to release the engine to the public, and allow others to learn from it as well. So, regardless of how things turn out, it's not in vain. I've just been thinking how I miss working on games lately.
Little time for game development. I keep attempting to get time in every day, and I do, but it seems that on average the most I pull out is an hour. Most of that time is spent recapping where I am and adding a few design notes, and a little bit more implementation. There isn't really time constraints at this point. It's been rather a matter of motivation to get my two hours that I've been shooting for and an ability to find two consecutive hours to work on things. It seems that as I'm working the rest of the world is constantly sending other challenges my way, interrupting the time that I do have set a side and distracting me. This is of course alright, because those things, such as work and family, are more important. Family always will be, and hopefully the work will be the game development some time within the next five years.
As such, I'm still working on the state management system for the game engine. I started writing ideas for it over a year ago and started working on the actual implementation last month. I think I've over complicated things for myself in the design area, specifically with something I call the Hidden Management Layer for game state management. I started out designing the HML simply to be the interface between the user and the game states. All commands going through the HML, via direct console commands, or GUI commands, and the HML being responsible for handling any commands that it was capable of taking care of, otherwise passing the integer value for a command code to a specified game state so that it could handle the functionality. The HML also is responsible for keeping track of states that are active, that are in memory, and that currently have the app focus, while the states simply update themselves if they are active and process any tansitional code, release and initialize memory, ect.. when needed. This all seems fine to me so far.
The over complication comes into play once I started growing my definition for what a game state should be and once I started to ask my HML to handle tasks that should probably be handled else where.
For example, at some point I got the bright idea to incorporate my different engine management structures(engine objects, Scenes, and levels) into game states. At some angle this made sense to me. By doing this I would be able to control every object, scene, and level in the game as if it were simply a state. I would be able to pause individual states(Meaning that if for some reason I wanted to freeze individual object logic from updating, or temporarily remove an object from a scene, it would be very easy to do.), also all the different management structures would be able to interact with each other very easily.
As I'm writing this I'm having too many ideas run through my head as to how I should approach this. Currently I've just been designing a ADT and planning on deriving three classes for the different types of Engine management structures. This may work out ok.
I can't seem to focus to write this now, so I'm going to leave these ideas un-elaborated on for now. The phone won't quit ringing.
I made a little bit of progress today. I finished some auxiliary functions for helping to manage opengl that I had been meaning to finish for a while, and I continued working on the design for handling game states within the engine.
I need to finish writing the state functionality as well as finish adding the DirectInput legacy support for the engine. Then I'll be able to move on to GUI stuff. I've got to work this weekend as well, but I hope to get the state management finished with. For one reason or another I started doing the state management and game pad support at roughly the same time, I should have just finished one before moving on to the other, but it's a little late for that. AH well. You know, I tend to lose my sense of humor when I'm tired, which is kind of weird. Or I lose my ability to express my sense of humor when I'm tired. It's like my comedic kryptonite.
The rat race is an unfortunate part of a capitalistic society. At the same time, it also challenges one to be smart with their time and resources. I for one will consider myself to be rich when I am able to fully support myself and my family as an Indie game developer by making games. To me, that will be the end of the rat race. It will be the beginning of a better life. In the meantime however, I've got to fund life and game development with a day job. It does help when the job doesn't completely suck, but it still sucks that it's not doing exactly what one loves. At any rate, it has still been taking up a lot of time, but I finished training last week and I'm starting to get used to being out in the field on my own now, so I've got to get back to working on the engine and finishing up the Barricade proto-type.
I'm going to still be working a lot of over time with work because of the area I'm assigned to having not had a service tech for six months before my presence, but I've got to push myself to work on things a least two hours a day. This should be reasonable even on the days where I have my son, but it also is going to require no dilly dallying on my part, but I've got to make time for it, especially if I'm going to even come close to getting things polished and ready for the full production of Barricade by June.
I'll also be moving again in June, but I haven't decided where to yet. Ideally some where closer to my sons school as driving all day and then having to make a round trip after work in my personal vehicle to pick up my son tends to take a lot out of guy, I'll have to figure something out soon though.
The weather has finally taken a turn for the better. Warmer temperatures are a welcomed blessing after a pretty harsh winter. It was to be expected and the cold isn't quite over, but a break from it was much needed.
Oh, if I ever use something like Chedda again in a topic or while speaking in real life, someone please slap me :P .
Last night was the monthly game developers forum meeting in Ankeny for the central Iowa area. It was pretty cool, the guys from intuition games came out and we were glad to have them. We got to take a look at Dinowaurs which is a very interesting RTS type game made in flash. I had to leave a little early from the meeting due to work the next day, but it was still very cool to see the game in it's current state. It's awesome to see all the game enthusiast in central Iowa coming together and to be a part of it.
More Later.
I finished up the XInput implementation for the Engine this weekend. I still have to finish the DirectInput functionality though. XInput was fairly easy to implement once I found some time to write the proper wrappers for it. It was so easy I wish it were the only thing that I needed to support, but that just wouldn't be smart.
Anyways, with as little time as I have hopefully I can get the DirectInput finished by the end of this week. It's my son and my nephews birthdays this week though as well as week three and the final week of training at my job, so I'll probably be really busy. I'll still find time to code though.
I also have decided that I need to write a more flexible version of the bitmap font class that is currently in the engine, because well, it kind of sucks the life out of updates. I've never really noticed it before because I have never had a lot of text on the screen at one time, but with the demo that I'm writing to test the input you can definitely see the difference.
Here's a screen shot trying the built in picture layout functionality of blogger. ( I usually don't like these because they are not as flexible or as easy to use as simple html tags.)
The frame rate is very low when a device is connected and there is a bunch of text
on the screen, but when a device isn't connected the frame rate is in the seven hundreds. That's a flag if I ever saw one. I still have a lot to do and I'm not really sure if the proto-type release will be done by Mid March, in fact at this point I'm pretty sure I'm going to go over as I'm planning on being a perfectionist because I really want the proto-type to be pretty polished. And if not the game, at least have a very polished version of the engine.
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 ended up getting some basic gamepad functionality into the engine this past Sunday, but as for a completed class that offers the support of XInput and DirectInput both, in a flexible way, it has yet to see completion. I'll continue to work on that through out the week and am really looking forward to get a big chunk of work knocked out this weekend. I decided that I'm going to have to write a lot of custom initialization code for DirectInput as well. I'm still not really sure how I'm going to handle a few issues at this point, but I'll figure it out.
There is a lot that needs doing. At this point, I'm lucky if I get my two hours a day in for coding though. But I'm thankful I can even get that time in. I'm trying to convince myself that I can still make a mid march deadline for a proto-type release, but I'm not sure if that's realistic or not, especially with work now taking up a lot of time and it being harder to focus on things after work as I'm usually kind of tired. It may be beneficial to switch my schedule from working out in the mornings before work, to coding in the mornings before work and working out in the evenings. I may end up trying that next week. The problem with that being if I don't work out in the mornings, I usually feel tired all day and if I'm not really a wake I won't do very well getting things done code wise either. A little experimentation will probably be in order though.
Ok, I've got too damn much to do, so I'm going to quit blogging now.
Well, this week I started back into the work force. The good news is that I really like my new job. My boss is really cool and so are the guys who have been training me. Once training is over I'll pretty much be working on my own most of the time, which will be ok as well. Time was eaten up completely by work and family obligations this week. I only managed to code a total of about two hours, most of which time was spent working on the gamepad code and doing a bit of reading in that area.
I should have at least two hours a day to work on game stuff once training is over too as I ended up working some overtime almost everyday this week to get through the first part of training. It's going to take me a little bit to get some balance going on so I can fit game development related stuff into the mix. I should also be able to do 20 hours a week extra every other week when my son is with his mother, which will help out and then probably two to four hours in the mornings when my son is here if I get up at 5am. So, things will be progressing still. I will get the game pad code done by Sunday night. I've got a lot to do after that as well. More 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, after really getting down and dirty, replacing code with previously tested code in different sections and completely substituting the entire current structure of the prototype with the old one to make sure that the problem was in that code I finally figured it out.
IT WAS ShowCursor(true);
Don't ask me how the hell this was making everything corrupt, but it was, I don't get it?? Who'd a thought. I use that call in other places and have never had that problem before.
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.
Well, I've been pretty busy with other things today. But I spent a few hours fixing another problem. If you look at the screen shots below, ever since I started working on the collision and block placement, the blocks seemed to have a lot of space in between them. I was a little confused about this because I had used my editor to map the textures to the size that they were supposed to be. It turns out however that somewhere a long the lines I had lost five pixels in length and width on my small blocks. Using math to multiply the bounding volumes was how I got a visual stencil to map my other sized blocks, so the loss of five pixels translated over to 10 in width of the narrow blocks and 10 in width and height for the bigger blocks. This of course is what caused all that space. After figuring that out this morning, I set about fixing it over the last couple of hours. That's done now. Here's a screen shot.
__Click for bigger view__
Ironically all that space actually helped me to develop my collision system though, so it worked out pretty well having that error happen.
Ah.. now that's much better. I still haven't finished the wide spectrum collision, but as I stated I've been busy with other stuff today. I may finish it tonight, but definitely will get it done by tomorrow. I'll be going back to work at a day job next week, so I want to get as much finished over the weekend as possible. More later.
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.
|
|
