|
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.
So, I was lucky and the lottery gave us a day off for Christmas at the last minute. Which means I have tomorrow off. They told us this today. Which is to be expected. Of course this means however that I had to plan my Christmas a head of time as if I was going to work, and now I won't get to see my son until after 3:30pm. Then Friday, back to work and we'll see if I end up having to work New Years day, which is a strong possibility. Groan, groan, whine, ect.. To be honest I'm just glad I have a job right now. So the little annoyances aren't really that bad.
I do however need to start concentrating on some sort of transitional period over the next year. I plan to continue my current job, but would like to be ready to go into a software development position of some sort by the first part of next year. At which time I'm also hoping to have the engine ready and being used for exclusive production of Phyersoft games for the length of the current agreed upon contract, after which the engine will be released to the public.
At that time, I'm hoping that over a few years of further development, support, and building a community around the engine, I'll be able to transition into having it as the base ip for my own business. Then, after getting some infrastructure setup to continue development and support, I can really begin concentrating on making games. Of course as soon as the engine is in a production quality state, I'm going to begin on a project of my own as well. I have three that have been partially designed that I'd really like to finish and build, but I'll have to cross that bridge when the time comes.
In the meantime, the challenge of staying focused and motivated is in the forefront. I may have to limit myself to being more selective in my future involvements in future projects that stretch outside of the realm of my main goals, after current projects are made good upon and completed. At least until I have more time. If I continue to be so fragmented in my undertakings, and going off on tangent projects, the next four years will go by like this past one. Time having passed with good intentions, some work, a lot of planning, and little to show for it. This of course would not be a good thing.
For anyone interested, I'm now on Twitter. Something that I put off for a while because I thought it was kinda weird, but after getting into it the last couple of weeks, you can get a peek inside the lives of people all over the world every day, which is an awesome concept, even if it is instantly brief and and enormous time killer. A cool thing I've done, just randomly select followers from one person to the next and see who you end up on after a random number of clicks.
Merry Christmas everyone, may your stockings be coal free, unless they're stuffed with clean coal, then market that shiznit and make some clean energy for the masses.
Made some progress today on the new data management classes for the engine. I'm working to get linked list implemented in such a way that objects and scenes will be able to be as dynamic as possible. And as per usual, I'm rolling my own, which is always fun, educational, and tedious.
I have to go Christmas shopping for the family sometime this weekend, which will be a nightmare I'm sure !!!!!!!!!!!!
I didn't meet my goal 15 minute segments of internet use today, but I did cut back, which helped me be more productive.
So, it's crunch time for the next.. oh.. two years. Not the cap'n crunch kind of crunch time either, although I do have some crunch berries, my son picked them out. But no, I'm talking nose to the grind stone, eating, sleeping, pooping work.
I now have taken on three full time jobs. Lottery, Game Engine Developement/ Personal Website Development, and GoG Tournament system development. So what does this mean. It means that I've got to really get organized. My plate is full to the brim and if I'm going to be that orphan who gets that next bowl of gruel, I'm going to have to scarf down that first bowl, no matter how hot and tasteless it may be.
Luckily my metaphorical gruel doesn't taste bad, but that first bowl seems like it's a never ending amount to shovel. This just means that I have to get really organized.
In order to do this, I'm simply going to focus on the tasks that I lay out for myself each week, as well as limit the time that I spend on the internet (huge time killer) to 45 minutes a day, unless related to the Lottery, which doesn't count, 15 minute segments broken up throughout the day. The limitation includes research also, meaning that I'm going to have to use books for the vast majority of my reference hunting and if there is something that I need to look up, I better damn well have a good idea of what I'm looking for before I get on the net. This of course hasn't started today, but will start in the morning.
I'm also going to have to limit my gaming to no more then an hour a day (which I don't normally play every day anyways), which kind of sucks, because normally I'd just play for 3 to 5 hours twice a week or something, but this sucks those days away, which I'm going to need.
Before the new year, I need to :
Have Game States, G.U.I system, and the next version of the Editor started for the game engine.
Have a good start on the tournament system.
27 days after this one. Time to get this show on the road.
Well, I did a radio spot today on Macs World for the GoG and it was a pretty cool time. I guess I don't really have a lot to say about it. I was trying to let Ben from Gathering of Gamers do most the talking as we were there to promote the GoG and he knows more about it then me. I do think that it was some good exposure for some of the things that we are trying to do in Iowa to further the gaming culture. Overall it was a great experience.
The last design posted previously to this post is currently being revised. I decided to go with a linked list approach to add some dynamic memory management at run time in the engine. So the previous constraints of the amount of scenes will be replaced.
I'm also going to be working on designing and developing an online tournament system for the GoG. With work, being a dad, game development, and now the tournament system being developed, my time is pretty much spoken for, for quite sometime. This isn't bad, doesn't leave a hole lot of time to play Fallout 3. Which shouldn't all be bad as it'll leave more of the game to play once they release a decent patch for the game which is scheduled sometime this month.
Today I'm finally sitting down, after some long procrastination and a lot of lack of time, and also having to get the server back up after it went down, to get to work on the Scene class and file structure for the engine.
Scenes are but one parts of four file formats that the editor uses to build a final binary file that the engine will use. The four file types work together and combine all the the data and resources and as such are intermediary files.
The different file types are:
.TOF = Troglodyte Object File, used for storing Data specifically for Objects. This file format is specific to any one type of sprite object that can be used in the system. This type of isolation allows objects to easily be used across different scenes in any level or project. .TOF files can also hold purely audible data and can act as sound effects or music ques around a scene.
.TSF = Troglodyte Scene File, holds the data for a specific scene. Here is where game scripting, keeping track of objects, and object interaction begin to take place. This file knows how many objects are in a scene, keeps track of where the object data is stored on disk, and is responsible for resolving script and and object data at project compile time. Scenes can be a platformer level, and scripted animation scene, or even a menu, for example. Scenes are not limited to these types.
.TLF = Troglodyte Level File, this file is somewhat redundant in that it serves the same type of functionality for scenes that the scenes perform for the objects. Each level is limited to 25 scenes simply for simplicity, but does not have to make use of the full 25. If a developer feels that 25 scenes aren't enough, it's up to them to structure their data so that it works, or they can edit the source for the engine and recompile to suite their needs as long as they follow the EULA set forth.
.TPF = Troglodyte Project File, this is the all encompassing file that organizes all the other files types into a working structure to be used in the engine.
Once compiled these create a .TBF = Troglodyte Binary File. This file has all the video, audio, and script resources compiled into one file per level. If a project is named Quest, the files would be saved as Quest_L1.TBF, Quest_L2.TBF, and so on. L1 files will always be the starting point of any game. The editor will spit out compressed files into a structure such as specified directory/Quest/Bin
After a brief introduction into the file types, now onto the design for the .TSF files and classes.
All of the serialization work for the files are handled by a class called the hidden management layer. The Game State Hidden Management Layer is responsible for sending a message to start or stop a Scene and handles any errors that may arise during Scene and Level initialization and clean up. So, what this means for our Scene class, is that we can keep it fairly simple.
Things the scene class will need:
1. Know the number of Objects it has.
2. Know the number of Scripts the scene has.
3. Know which Script corresponds to which Object.
4. Know when an Object should be following a specific script.
5. Know when it needs to initialize and load data.
6. Know when scene execution should begin.
7. Be able to update the scene data each frame.
8. Know when to stop scene execution and updates.
9. Know when to clean up and release memory back to the heap.
10. Access to Objects interfaces to be to manipulate Objects.
11. The ability to add and remove Objects from the Scene at runtime.
12. A Scene Name. (Not to be Confused with state Name).
13. A unique numeric identifier for the Scene in order for the Level to keep track of it. This should range from 1 to 25. (Not to be confused with State_ID, which is used by the GS_HML.)
14. Area size. The size for one block on the area grid is 32X32 pixels. Area sizes of grids use multiples of 2 starting with 8X8 and the largest Area being 1024X1024. Which equates to up to a gig of background data being available in memory at any given time.
All Grid Sizes: 8X8, 16X16, 32X32, 64X64, 128X128, 256X256, 512X512, 1024X1024
15.Scene Orientation data. If the developer wants to use a platform type view for a scene, or if they wish to use an isometric or top down view, it must be specified using the Scene_Orientation variable. This is one of the variables that must be selected when creating a new scene.
16. Layers. Regardless of camera direction and placement, developers can make use of up to 32 layers. Depending upon the orientation of the camera however, the layers can either be used in only the z or y planes. Objects must be on the same layer in order for them to interact with one another, however, using scripts, changing an objects layer during game execution can be performed at run time. This can allow Objects to move from a background layer into the fore-front for example, or vice versa.
Things like pausing and swapping scenes and levels is once again handled by the Hidden Management Layer.
*Note: When adding Objects to a scene, a unique identifier for faster parsing of objects is going to be needed. This should be a numeric value.
No limit of Objects is implemented in the design per scene. This approach will require an increment to the identifier to made for each object added to each scene. This approach means however that if an object is removed from a scene, that the numeric value added to that object is no longer valid in that project.
For example, I add an Object called Apple. At the time of adding Apple to the scene it is assigned the Scene_ID of 25. I then remove apple from the scene because I decide that I want to use a different type of Object in its place. If I were to simply edit the Apple in the Object editor and update it in the scene, then it would retain the same Scene_ID. However, since I deleted the object, even if I later decide to add that same object back into the scene, it will be assigned a new Scene_ID at that time. 25 will become lost from the ID pool, but this shouldn't really matter to the developer as Scene_IDs are used internally simply for data management.
17. Error Messaging. When the GS HML loads or saves a scene any errors that may arise should be displayed to the developer in order for the developer to choose a course of action. Error logs should be generated in the Project folder for a project. The folder should be Error Logs and
inside there should be logs for problems with the overall project and then sub folders for each additional file format. This should handle:
17.A) Object Creation Errors - (Loading data from disk.)
Non-Critical Errors - The developer can be prompted to skip the object and continue Loading the Scene.
17.A.1) Resource Not Found. (A Texture, Sound File, or Script Associated with the Object can not be located.)
17.A.2) Corrupted Object File. ( The file has been corrupt and cannot be loaded.)
17.A.3) Missing Object File. ( The Specified Object File Cannot Be found.)
Critical Errors - The Scene will not be able to continue to be loaded.
17.A.4) Memory Out of Bounds (Buffer Overflow - Causes system to be corrupt. Engine/Editor must be restarted.)- This should generate
an error report pinpointing the Object that caused the error so that the developer can look at the Object and remove it from the scene if necessary.
17.B) Scene Creation Errors - (Loading data from disk.)
Critical Errors- The Scene will not be able to continue to load.
17.B.1) Corrupted Scene File. (The file has been corrupted and cannot be loaded.)
17.B.2) Memory Out of Bounds (Buffer Overflow - Causes system to be corrupt. Engine/Editor must be restarted.)-An error report needs to
be generated to show the developer which scene caused the error so that it can be removed from the project.
17.B.3) Mismatched File Type. ( The file attempting to be loaded does not have the .TSF file extension.)
17.B.4) Old file version.( The file being loaded is built with a previous version of the editor and the file format is out of date.) - Adding
support for some legacy file formats and being able to update them to the new format once loaded is a possible work around for this issue. This could potentially be a non-critical prompt message.)
17.C) Scene Serialization Errors - (Saving data to disk.)
Save Failure - If any of these errors occur the program will simply exit the saving method.
17.C.1) Scene File in Use. ( The file is an open stream being used else where.)
17.C.2) Minimum Data requirements not set. ( Some how the user by passed filling out the appropriate minimum data needed to create
a scene, therefore the file is not valid.)
17.C.3) Memory Corruption. ( The memory attempting to be read for serialization is corrupt.)
Save Prompt - If any of these errors occur the developer is prompted for action.
17.C.4) File already exists. ( User is prompted for to overwrite file.)
17. Followup Note - It will also be beneficial to allow the developer to set a flag that enables all non-critical errors to be ignored during in editor
testing. These messages should still be logged so the developer can fix them, but prompting the developer should be removed from the
process if that flag is set.
18. Scenes should inherit from the inheritance line of the class GAMESTATE in order to actually make use of the messages from the GS HML.
Blurry blurry vision, it's not as cool as it sounds believe it or not. Sure you see a big purple spot every where, but it makes it hard to read and to tell the difference between certain colors. Not really handy when your trying to put some new ends on a cat 5 cable. So, I experienced this last Monday and Tuesday. I finally decided to go to the doctor for the first time in six years after it didn't go away. The doctor sent me to a specialist, and after some test, they discovered that I have a condition called Central Serous Chorioretinopathy. It's an eye decease that effects mostly white males ages 25 to 45 and it causes retinal fluid to leak into the front part of the eye and causes warping of the pigmentation. This can lead to fun things like retinal detachment, or permanent visual defects. It's apparently caused by a reaction in the small single cell layer that separates the fluid and solid parts of the retina, brought on by a reaction to too much epinephrine( adrenaline for we simple folk), and is somewhat of a medical mystery.
The good news is that I should get most of my vision back and with some precautions, a the chance of a recurring episode can be greatly reduced. The bad news is that if it does happen again, the likely hood of permanent damage greatly increases. I go back to the doctor next Tuesday for a follow up to make sure the liquid has recessed and that everything is healing.
More troubles, except this time, in the server front. I have to assume that the server was some how cracked, because before this Monday, there was no trace of a problem, and I hadn't downloaded anything in months to the server. On Monday of this week however, I discovered that when trying to access the forums at decipherone.com, the forum software was generating an error message saying it was unable to connect to the database. I finally had some time to look into the problem after getting home from work late last night. Tenga.A virus anyone? If you want some I can send you any one of the exes on the server because they are all infected. Which after doing some research seems odd, because apparently there are patches for it in XP from service pack 2 up, and I have service pack 3 installed. I didn't get it, but now I get to spend this weekend reformatting the server and loading all the software back on it and setting up some new security precautions.
Well troubles are said to come in threes I heard one time, and I know of another problem that I won't discuss for reasons I leave a mystery, but the good news is life moves on. I really wish my work on the engine would though, but life keeps seeming to throw me some distractions that have to be taken care of first.
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.
I am spending way too much time reading and posting on forums these days. It's good to see all the great projects going on over at tigsoucre, but there is just so much information there that I've missed out on that I'm trying to catch up with that I'm easily spending two hours a day reading the forum posts. Plus working on my website and having various other things going on, I really need to refocus.
The server for the website will be down for a short amount of time as I'm going to move it on Thursday to a temporary place. Not that anyone goes to my site anyways, because there's not a lot to see there yet, but just in case someones wondering.
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
Source control is something that I neglected for quite sometime due to some issues that I had a few years ago with using Microsoft Source Safe. I'd asked some fellas over at gamedev.org a little while ago about what they were using as I have plans to get some additional help with projects in the near future and was wanting to look into again.
After looking at some of their suggestions I decided on Subversion , and I finally downloaded it to the server and started working with it today. At first it was kind of a struggle because even though the documentation is pretty thorough, it leaves out some important details. It seemed no matter what phrases I was typing into google, I couldn't find any other documentation.
It wasn't until I entered the phrase subversion walkthrough that I actually found some sites that help me get it up and working. Mainly Video How To: Getting Started with Subversion and Source Control was what I looked towards for some straight forward answers. It's a really well made tutorial for anyone looking to start using subversion on windows and it also introduced me to the GUI command tool Tortoise which is way better then simply using the command line interfaces.
I'm pretty happy with the experience so far, and am glad that I can now have access to things remotely as well. Now to actually get some coding done.
September is here already and although I've done better this year then any other at blogging I still haven't met a lot of my goals in that area, but things happen, people get busy, and time goes by, just like every other year and every other life.
At any rate, as per usual, I've been pretty busy. As previously mentioned, I'm still working on building the site over at www.decipherone.com , but it's been kind of slow going, along with production on the game engine. I haven't really been spreading myself too thin, more so I've been getting side tracked a lot with spending time with friends and also getting some other projects going.
One such project is getting involved with the guys over at www.gatheringofgamers.com . This is a great social networking site that is geared specifically towards gaming. With the exception of the great games experiment, I haven't been one for social sites, but this is one that I've actually been somewhat active in this year. I met the president Ben at our first game developer group meeting last year, and managed to meet up with him again and the site intern Zach (aka RyuBlitz on the site)a few weeks ago where we played some disc-golf, some 360 and had a few drinks. We had a great time.
At any rate, I'm very impressed with the site as it's grown to near 2,000 members as of this writing in a little over a year(just over as of August 26), and people keep getting more and more involved. There are plans for me to help out with some contract work as well as help promote the site and attempt to get some networking opportunities set up. It is dedicated to helping gamers network. You set up a profile and have friends, classic social site style.
Last week there was also the addition of a clan system that is used to help those involved in gaming ladders keep track of their members. The site has recently seen an onslaught of KSI members join since the system first went live and we expect to see numbers continue to grow.
Ben recently got back from New York last week where he went to meet up with the Microsoft based company Massive which specializes in in game advertisement. The plan is that the GoG is going to be in charge of a gaming event in New York in November.
Other interesting opportunities have happened for this small upstart, like attending E3 and plans to attend the Major League Gaming Playoffs in Dallas Texas in October.
If you are a gamer and you're looking for a place to hook up with other gamers, then the GoG is the place for you. Stop on by and check out some profiles, find other peoples gaming tags and meet up with them on line. Come be a part of a growing community that has of yet seen it's peak time. With many more plans for the future, get into the Gathering while the getting's good.
It's been a little while since I last wrote anything in here. What have I been up too, work mostly at the day job, but aside from that, I've been working on getting the website going. Really that's about all I've had time for, creating content, and I'm finally starting to deal with databases again for the first time in about six years, and starting to dabble with some php. It seems like I've been writing a lot also, but about what I'm not sure as it doesn't seem like I've actually produced a whole lot.
I'm also getting ready to move again, this time into a house finally. So things might be slow for a while a yet, but things are always moving in the background. I have forums up and running http://www.decipherone.com/community but odds are if you're reading this blog, you may already know that.
More as news develops at 10.
The month of June 2008 has come and gone already. Half of one orbital rotation has been completed and we are our on our way into the second half. As this begins, I think that it's important for me to reflect for a minute on things that have transpired this year. To see where it is that I am heading and to take note on where things need to change in order for more positive outcomes to be realized.
I was blessed enough to receive a job this year that has allowed me to hold true to completing obligations as well as fund my hobbies and personal business endeavors. It can be easy to forget where one comes from and to take for granted what one has when it becomes a part of ever day life and begins to seem less then extraordinary. The perception of course is wrong. It's something that I have to keep in mind as flight through the cosmos continues this year, and something that I think I should remind myself of, each and every day.
Family is also something that can start to be taken for granted. It's important to have family because they are the ones that help to keep us honest, that we share our triumphs and falls with. They are the ones that let us know when we are acting like a fool, even if we can't see it, and that help pick us up after we have had a bit of misfortune. When things start getting comfortable, it can be easy to forget just how important family is. They are the magnetic poles that guide our moral compasses.
Health is an area where I have been lacking in this year. I was doing well with taking care of myself for the first quarter, but once things starting getting a little unorganized, I allowed myself to fall into a pattern of little to no physical activity. This is bad for me as exercise has always been a huge way for me to relieve stress. This could potentially lead to other problem areas, which in turn could effect the other areas of my life that I've already reflected on. This is something that I've been making a note to change in my mind, but haven't really put forth an effort to remedy. If I don't get serious in this area, I fear it could have some adverse consequences.
I have not accomplished as much as I should have at this point with the game engine this year. At first my time was eaten into by other areas of my life such as work. But for the last three months or more, it's been mostly due to laziness and failure to structure my time to be productive. Granted, I have made some headway, but it hasn't been enough. I have failed to set consistent goals and know that I should have been doing more. Dedication in this area is a must if things are to be ready by the end of this year to move forward into what will be the second phase of my business endeavors. (which I will write more in about in the coming months)
I've been thinking a lot about my goals, community, and my future lately. Essentially, I've given myself five years to make it on my own from nothing to indie game development company. At the end of the five year period I plan on not giving up, but instead taking a more traditional method of academia, because at that point I'll have proven that I can't do it on my own. If things don't change, I'll be sitting here five years from now in too much of a similar position. Except I'll be having to take out loans to take a bunch of classes. I don't like being in debt for any reason, especially to learn(something that should be available to everyone if they want it, at an inexpensive cost, if not free)
Over the next few weeks, I'll be working to get back into a productive schedule that includes exercise and a minimum amount of time to work on things. I'm also working to develop a full fledged website and community to surround the game engine also, so time structuring will become more and more important as we come closer to the engine reaching it's first release phase, and the website officially going live.
This week has been an interesting one. I've spent the better part of it with my son, which has been a blast. I took the week off from work and with the exception of a few days he's pretty much been by my side most of the time. Sadly, I don't really remember the last time I got to spend such consecutive time with him, but I don't think I've ever had a better vacation.
On the server front, I ended up abandoning ubuntu as I was spending way to much time managing system resources and setting things up. Damn it Jim, I'm a programmer, not a full time systems admin. It was just way too involved for the things that I wanted to do and the time that it would have taken to get everything going just how I wanted. So, I ended up re-installing windows and simply going with an Abyss server app. Now, I'm very pleased with Abyss so far very user friendly and easy to use. I also got setup with a dns redirect for decipherone.com and now we're in action. I just have to write all the stuff that I need for the website and PLOW! no more paying outrageous prices for hosting and or renewing or registering domains with over priced registrars. Thanks Google, enom,, and
Dyndns.org
In engine news, I finally finished the directinput functionality for the engine. So now you can use 360 controllers and generic controllers at the same time, as long as the developer puts interfaces to it in the game that they are creating. I started getting the GUI class fleshed out last night, but I'm guessing that it's still going to take me a while to get that finished up. There's just a lot of functionality to consider when writing a full fledged GUI. It'll be good to get it going though and be able to get the editor more object based. Currently it's written as an object simply called Editor and all the drawing for the menus and everything is done directly in functions in the class. This is bad. It works, but it kills frame rates. I'm also looking into using FBO to turn text files into textures once the text is read into the engine. Currently it simply reads from the file each pass and writes the bitmaps fonts to the screen each pass. This is very inefficient. Lots more to come.
Sir Galahad was the knight who successfully found the Grail. A king among men. We should all strive for such greatness.
So, I spent the better part of the day and night messing with the server. I had forgotten about a problem that I had noticed about a month ago when I was assembling most of the parts to begin with. It wasn't until about three failed attempts of installing the latest build of Ubuntu that I remembered it. You see the case that I currently have for the server is arranged in such a way that the cpu is kind of close to the power supply. Granted, that this might not normally be a problem (although still a bad design in my opinion) but in my case, the fan that I have over the cpu is pretty massive. It's about 2 1/4 inches resting on top of a 4 inch heat reduction coil. Now, this is good for cooling purposes, but bad when there is only about a 1/4 inch gap between the fan and the power supply. In my haste to get things going I suppose I put it off in my mind.
Needless to say, this caused the psu to overheat. Now for some reason, I was thinking, "what is going on, is the damn thing overheating," but I couldn't remember why. It wasn't until I opened up the case to make sure the cpu fan was working that it dawned on me that I had forgot about the problem. So, I had to do some temporary adjustments and the psu is now resting on the bottom of the case for time being, with the case open. This took care of the problem for the time being, and the system is no longer freezing up. It's kind of funny though, I don't normally get that excited about things, and here I was just blowing off a problem with the system. Well, I thought it was funny anyways.
So, I'm either going to have to do some custom cutting to the case to get something worked out, or I'm going to have to get a new case. I have some tin snips, so I think I'm going to try some custom work to the case first, but if that doesn't work out, I found a decent case on-line for under $50. It'll have to wait a few months though as there are more pressing purchases to make in way of summer clothes for the kid, car insurance payments, and a portable air conditioner for where the computers are so that they don't over heat this summer.
My thoughts on Ubuntu Linux so far, after spending about five hours messing around and setting it up are, I like the interfaces a lot, I haven't really gotten to do a whole lot as I spent time downloading updates and just getting familiar with basic file structures and the like. I also downloaded Boinc to run Seti so that I could free up my dev box from it, so hopefully it'll have a little longer life. One thing I'm not liking though is the inability to access things as a root user without having to do some sort of working around. I suppose it keeps inexperienced people from screwing things up, but it seems like over kill in the area of protection. I would assume that anyone who can manage to work around the system the way that it is setup to emulate a root user, they could still screw things up just as bad, even unintentionally, but I guess it would take a little bit more work. At any rate, it's going to be an ongoing learning process. I just have to make sure it doesn't get in the way of working on the engine as well. Long day tomorrow.. err.. today. I better get some sleep.
It's flooding all over the state of Iowa right now, including here in Des Moines. I happen to be in an area with higher elevation, so I pretty much have lucked out so far and haven't felt the wrath of nature directly. I have however been witness to the many people who have not been as fortunate and who are losing their homes, access to their work, and even some people being separated from their families. If anyone reads this blog, and you happen to be the praying type, I'd ask that you do so now for those people who are having their worlds shaken up. At the same time I realize it's not like similar things aren't going on in the rest of the world, it just makes you take notice even more when it happens to hit close to home.
Speaking of weather, I've been kind of under it the last few days. I've had something of a fever and upper respiratory infection, so I've been kind of unmotivated to get things done. Not that I haven't felt that I wanted be motivated, in-fact, yesterday I attend the local Game Developer Forum Meeting, and today I completed assembling the server, and even now I'm taking the time to write in this here blog, but I've just felt un-motivated. I just hope to get back to feeling normal soon, but I suppose, just like the rain, all I can do is wait it out.
A few days ago, I did manage to complete the side by side XInput and DirectInput implementations for the engine. I also started working on a new test app, or rather a more polished demo showing recognized presses and the like for both generic and 360 controllers. I still need to finish that however. I am then going to tackle finishing up the GUI classes for the engine, which will probably end up taking me a little bit longer then I like, but it'll be a good experience.
I also decided to install Ubuntu as the os for the server. This will be good as I'll finally have a dedicated installation of Linux that I can start to code for, and work out serialization and windowing issues in regards to cross platforming for the engine. Although at this point it's not really a concern, but it's something to look forward to.
At any rate, I'll be spending time building up some resources for the server over the next few months. I'm not going to rush it, as I'm hoping to do some more professional things with the inter-web, and I also have a lot to learn in the way of the operating system, databases, server sided scripts, and server administration in general. I think I'm going to turn in early to try and get to feeling better, and to get an early start on things.
Things are starting to pick back up on the development side of things. I'm starting to really get focused back on my efforts and have been getting things organized once again. I've done a horrible job of documenting progress with releases of the engine and this is something that I'm really going to have to watch, just so it's easier to see what's been done for archival purposes.
On another note, I should be getting my server finally completed this week. It's something that has been a slow and steady build, but I'm just now waiting on the remaining parts to arrive for now. I'll be using it to run server software for the game engine as well as host some other projects that will be mentioned once the work is completed for them.
I've got a lot of work to do to get back on par with my development outline, so.. back to work.
My son is sick again today with a high grade fever and some other symptoms, but apparently the doctors couldn't pin point what it was. I plan on doing some reading and code analysis before bed, but I'm dealing with my son being sick for the time being.
Well, I obviously haven't done a good job of meeting my goal of blogging everyday up to this point. Reason being, I've been a little off kilter still and not very focused on development. No more, I now banish laziness from my life. Now the question becomes, where do I start back on the engine.
I still have fractions of things partially written here and there, half-assed implementations of classes and the such. I suppose the best place to start would be the area that I initially began in when going through in March and butchering up my implementations. That area being the gamepad functionality. While I had implemented the XInput stuff, I did not finish the generic gamepad support. So this will be the first place I start. There are more pressing issues to take care of, such as finishing the state management, but I figure my efforts became so fragmented because I didn't follow through in one area before starting something new. I had never done this before in the project and my thought processes and planning things out definitely took a hit because of it. Lesson learned. Keeping my work orders simple and linear will help keep me focused and productive. So, instead of planning out things way in advance, I'm going to do one task, then re-asses what to do next, and continue in this pattern for a while.
I also am going to have to begin doing additional research for the python interfaces, which I will begin doing again tonight.
I'm really going to have to work to balance things these next coming weeks as tomorrow an event happens that will surely take at least 70 hours of my time away from me. No, it's not the 8th World Biomaterials Congress Kick Off, nor is it my induction into the Nasa Bed Rest Study, instead..... It's the release of Mass Effect for the PC. Something that they said wouldn't happen. This couldn't be happening at a worse time, but it's something I'll have to deal with.
Things have started to slow down at work again. Which is good. It's been kinda of slow for a while, but I haven't had the mind set to get back to work on things full time, until now. I've done little to nothing for work on game development the last two months or more. This was due mainly to my work load, but also due to a lack of focus on my part. I took today to look through my archives and reflect on the things that I have accomplished over the last five going on six years. With the exception of the Conquest For Love proto type and the work that I've done on Troglodyte the last couple of years, I really have not been that productive. Of course when you start from nothing you have to build up knowledge and experience before you can do anything that is really worth while, but the reflection has once again put me in a motivated mindset. I am at a point where if I continue to work, over the next couple of years I am really going to start seeing my efforts pay off. Or, I could simply throw in the towel and move on to some thing else in my life. Doing so would leave me with a feeling of incompleteness however, and would leave me needing to have a redesigned vision for the future.
My current vision is in jeopardy itself. With the lack of work on a project comes the lack of management and a decrease in familiarity with the segments and details of the overall endeavor. It seems that I'm constantly coming back to this place. Doing large amounts for the project in short periods of time and then taking a break only to come back and have to get re-acquainted with everything once again. This is of course my own doing but seems to be necessary in balancing the other aspects of my life. Or, this is what I tell myself at least. At any rate, I'm finding myself once again having to structure my plans for things to come and a detailed plan of attack.
I am going to be blogging with the goal of writing something every day, and too have some progress to write about as well, no matter how small. I'm hoping that it will give me to motivation that I have been lacking.
Over at http://www.gamedev.org there is a competition going on over the next few weeks and I'm definitely getting in on it. I came up with a concept the other day and spent an hour or so fleshing out some of the details. I'm really excited about what I've come up with so far and thought that I would share my some what hacked together design document with the masses. So, without further ado, here is be :
2008 GameDev.org Expo
This Game inspired by Keep It Simple Stupid
This Game in dedicated to those that have passed away over the years your wit and creative spirits will be missed, but you are remembered.
Juho Vainionpää & Jam Rest In Peace.
GameDev.org Spam Bot Defender
Concept:
The premise of this game is a simple one. You are one of three forum
moderators who have been summoned by the Global Moderator Mikkom to help defend the virtual space of GameDev.org against an ever growing attack of porn spam on the website.
The enemies are actual spider bots who come by and drop porn images down from the top of the screen. As the images fall down towards the websites front end , it is up to the moderator to stop the image before it reaches the front end where it can be seen by the masses.
The spam bots have the help of distracting posters that come by and spam the forums with questions in regards to making mmo's, it's also up to the moderator to remove these posts from the forum front end as well. (This could be an added difficulty after the first few rounds.)
Actual Implementation :
Title Screens:
The screen fades in from black and displays the play area for the game, which consists of three different images each representing a different area of a virtual world.
---------------------------------------------------------------------------
The top of the screen (possibly done in a binary looking circuitry) represents the digital world, the internet. This is where the bots will be attacking and dropping the spam from.
The mid section ( this is the buffer zone where the player will have an opportunity to catch and destroy the spam. It will be most of the space of the screen and can have a simple image as a background.)
The bottom of the screen( the banner from gamedev.org) represents the forum front end. If spam hits this the forum is damaged and so is the reputation of the moderator.
---------------------------------------------------------------------------
At the fade in an image that says DecipherOne Productions Presents
GameDev.org Expo 2008
Spam Bot Defender.
Below this will be options for the player to choose one of three moderator
avatars.
Hymmerman
Ravuya
SDGamer
---------------------------------------------------------------------------
Each one will have different defense powers.
---------------------------------------------------------------------------
SDGamer will use disks of his movies to defend the forum.
Hymmerman will use small cities that resemble his city in the skies city.
Ravuya will use buckets of chicken to defend the forum.
---------------------------------------------------------------------------
Outside of the different avatar the player will see on the screen
and the different type of defense that will be used there is no difference between the moderator that is picked to represent the player.
---------------------------------------------------------------------------
After the player selects their avatar :
-- If time allows, core game mechanics need to be concentrated on first ---
A small story will unfold, presenting some god like eyes and a voice that talks to the player. IT is MIKKOM lord of the forum asking the player for their help in defending the forum against the hordes of spam bots that have been plaguing the forums lately.
This voice and and other classic characters from the forum will interact with the player throughout the game.
---------------------------------------------------------------------------
The entire game takes place in one area. Also, bots will attack in waves that get progressively harder with short periods of rest between each attack.
The player will be able to defend the forum using two types of devices that must be purchased from the armory.
The armory is where the player gets their defense devices. Each piece of spam that is destroyed leaves behind a karhma point (either 1 or 5) that the player must then use to buy defense devices.
Attack arsenal - These are standard range type defense devices.
Cost - 10 Karhma = 20 Rounds
Defense Barriers - Defense Barriers can be placed anywhere in the buffer zone. They destroy any spam they come into contact with, but they are also destroyed in the process.
Cost - 15 Karhma = 7 Barriers.
There will also be special weapons that the player will be able to purchase.
Arius's Cynicism - Completely obliterates any MMO posts from the forum.
Cost - 25 Karhma
Neko's Cry - This annihilates all spam currently on the screen.
Cost - 25 Karhma
DecipherOne's Ultimate-Defense - This creates a wall of defense barriers across the mid section of the screen. It last for 30 secs, after which all remaining barriers that have not be obliterated through being hit by spam, disappears.
Cost - 35 Karhma
Johnl's Wave of Wit - A wave goes through the forum turning all MMO posts into barriers that remain until they come into contact with spam or until the end of an attack phase. Also destroys any spam currently on the screen.
Cost - 45 Karhma
(A Note on MMO posts. These accumulate at the forum end of the play area and slowly stack. If not removed and bot spam comes in contact with one of them, it is considered a hit on the forum.)
---------------------------------------------------------------------------
Core Game Objectives
The player is given a Mod Reputation rating.
It starts off at 25 and can range from 1 to 100.
With each Karhma point collected the same value is added to
the players reputation.
The same amount is also added to a Score tally that keeps track
of the overall score throughout the game.
If spam comes into contact with the forum, what ever karhma points
the spam is carrying is then subtracted from the players
reputation.
If the players reputation goes below 1, then the Game is over.
It is the overall objective of the game to allow for an exponential increase in difficulty, fast play mechanics, a huge nostalgia factor for fun, and to allow for a comparison of scores to promote replay and competition.
------------------------------------------------------------------------------------
I'll be using Troglodyte to make the game and can't wait to get started.
In other news I let my http://www.decipheroneproductions.com domain expire today. The registrar I was with wanted entirely too much money to renew it and plus even though I've had that domain for five years, I always thought the name was too long. I instead registered decipherone.com for ten dollars through enom and google, which is a great deal. I won't be doing much with the domain for a public end until I get into a new place and get a server setup as well as an office, but I'm also pretty excited about that. Speaking of which, I have the day off from work today and am going to go house hunting as well as get resources ready for Spam Bot Defender.
There is still a lot of work to do for the engine as usual, but I'm putting that stuff on hold to participate in the contest. Wish me luck.
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.
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.
Ok, so I ended up scrapping the entire collision based block placement idea after a few more iterations of merking with it. Instead I decided to go with a basic grid placement system, that I will hopefully have finished by the end of the weekend. I just keep track of the space available, how many blocks of various sizes I have to place and update that information after each block placement. It's more of a simple system and actually makes sense, unlike my mad scientist ideas previously ventured. More later.
I was doing some more reading and I had a side thought about the last suggested block placement logic. The way it is currently set up the loop exits upon first collision, meaning that if the block were to intersect on the x axis while it was being placed, it would simply be projected away from the object it was colliding with and then the loop would exit leaving it possibly suspended in mid air, if the block was now no longer colliding with an object.
OOps, not what we want to happen. This is an easy fix though, we just have to continue to move the object through the main do loop until both an x and y collision has happened, so that the Object is at rest. So, this will change the logic structure too..
int collide=0 //Change collide to an integer value
do
{
if(collide==0)
{
Move block along negative x and y axises by -0.005
}
else
{
Move block along negative y axis by -0.005
}
if( collision with block placement area)
{
determine the projection by seeing which axis is the shortest distant to
non collision
move block to new position.
collide +=1; //ADD ONE TO COLLIDE
if(collide==2)
{
break; //(SIMPLE IF ENCLOSER OF BREAK STATEMENT)
}
}
else
{
do
{
subtract a number from the current block to work down the list of previously
generated blocks
if(the current block to check is out of bounds)
{
subtract one from the current row of blocks to check and make the last
block in the row the first to check
}
if(the row is out of bounds)
{
no collision happened, so break this loop
}
if(collision with current block to check)
{
determine the projection by seeing which axis is the shortest distant to
non collision
move block to new position.
collide +=2
break;
}
}
while(there's still blocks to check)
}
}while( collide<2)>
This seems to fix our problem, but upon closer inspection we run across one more. Using the current structure of logic the blocks at some point will begin to leave spaces due to the inability of the blocks to know about spaces between each other. This problem occurs no matter what point of origin is used for placing the blocks into the Block Placement area. This is due to the different sizes of the blocks and the random nature of their creation.
So.. Now what?? Well one solution is that through the use of reference counting, the blocks keeping track of the order in which they are created, that they should be able to share information with a management system. It will be the job of this management system to keep track of available space that needs to be filled as the blocks are generated. For example : The first row of blocks can be generated by keeping track of the translations of the blocks before them without running into the space problem. By simply knowing the boundaries of the block before it and knowing it's own boundaries the right origin for placing the block can be determined. Once the first row is filled, if we continued to rely on this system alone, the same problem would occur so an added element is needed. Because of the nature of the growing complexity of placing these blocks, this is where a quad tree does indeed come in handy. By Subdividing the space we can know which blocks the next block placed in the new row can come into contact with, without having to cycle through all of the blocks. It will be up to blocks to keep track of what sectors or branches of the subdivided space they are in so that when an initial collision occurs on the new row, by comparing sizes of the blocks, and knowing the dimensions of the each sizes bounding blocks, we can determine where the new block will fit without wasting space.  This sounds well and dandy in theory, and I'm glad that I took the time really analyze the problem before attempting to really code the solution again, even though this analysis took me a couple of hours, it probably ended up saving me a couple of days time. Following this model I will be structuring a new system for block placement. I will post screenshots of this implementation, even if it ends up that it doesn't work out. That will be available sometime later today. Further analysis will be required as well if this implementation fails.
|
|
