Legacy:Solid Snake/Journal

5th of February, 2007

Just at work, and had an idea. Got to make sure to write it down before I forget. The idea involved a mutant like game type with the mutant the holder of a chain saw and everyone else has to hunt down the chainsaw maniac. Sounds like fun, and it will be a reasonably 'small' game, which makes it great for RoboBlitz and to showcase what I've done. have to ask Hourences for permission to use one of his maps from UT2004 to convert over (Thinking Sae). Anyways, back to work.

30th of January, 2007

Well it certainly has been a while since I last updated my journal again. At the moment things are pretty sweet, I've become a registered pharmacist and my social life is well balanced with the time I get to develop stuff for both L3 [My lans in NZ] and for Unreal. Right now, I've dropped UT2006. I might discuss exactly why and what went wrong with it another day (A lot of things did go right, but more so wrong). So I've started working with Unreal Engine 3.x and what I can honestly say about it is that it is a very sweet and awesome engine. Its improved its work flow massively, making development easier, especially when it comes to getting art into the game. There is just a lot less coder intervention this time round which is fantastic, especially for coders who don't have a lot of experience with 3DSMax/Maya and other content generation. Anyways, I've decided to write a lot more tutorials on how to do things with Unreal Engine 3.x than I did with Unreal Engine 2.x. Its been good fun, and I've learnt a lot about Unreal Engine 3.x that most other people simply don't know (Those that aren't bound by NDA's anyways). Anyways, I hope to actually release something this year, but if that doesn't come true, then at least a lot of tutorials will be other for you to see.

5th of April, 2006

Hmm its been a fair few months since I have last updated this journal log. Well, lets just say that life has been very busy with pharmacy work and also my social life. Anyways.. UT2006 is still being worked on with majority of the work being done for the windows interface. Some new things I am playing with is a mouse gestured system where you use the mouse movements to detect actions. A good example, is if you start a drag and drop and decide that you no longer want to drag and drop you shake the mouse left & right to 'throw' away the data. Other examples is to swirl the mouse expanding outwards to expand a window, with a swirl inwards to shrink a window... I don't know how useful it'll actually be, but it will be kind of cool none the less! ... I'm kind of at work at the moment, so maybe I'll add more later on tonight. If I find the time to do so!

2nd of January, 2006

Well it is finally 2006. The UT2006 project has to be done within a few months and I'm not entirely sure if that itself is even possible. It may come down to the fact that I may have to port it over to UT2007. However with that said, I doubt very much that I will have to do a lot of porting due to the fact that most of the work for porting code over from different generation is due to the unexpected changes in say the class tree. However Chaos Engine itself is loosely based of the original class tree, and it uses its own class tree primarily (loosely based, being that it is linked with Engine level classes such as Actor or Core level classes such as Object). However the GUI would probably need a rewrite, depending if they've decided to rewrite say xInterface ... which they probably did.

Anyways, the current progress of UT2006 is going well. I've developed enough of the code to allow me to actually start playing the game and work on the actual gameplay rather than the code which simply gets things going. It is however not all fun and games, and as a good friend put it: "For us programmers, developing the code which is interesting and different is the fun bit. However with games, you've got some of that but that is so little compared to the mindless content code crap that you have to do.". And that's rather true since working with code such as the HUD code is pretty pointless and only basically it is just code bashing and thats it.

Working with the HUD for UT2006 is a very interesting experience mainly because I am taking a dual layered approach to the matter. One layer is the interface layer which serves as graphics and interaction. The second layer serves as a graphical layer. The question may be posed as to why I need to graphical layers. The answer to that is that the second layer uses the HUD class with the native calls, DrawSpriteWidget to draw everything. This is actually pretty fast, and why this oversees the first layer, is because the first layer uses my Interface code. While the Interface code is reasonably fast, it requires Objects to render anything in the screen. So the reason behind the dual layer approach is that anything that is a direct interaction such as buttons on the screen is shifted to the interaction layer. Anything that is just a graphic gets rendered in the HUD layer. Hopefully with this approach, the HUD will be rather speedy and do its job well. So far its working really well, and with the introduction of the new mouse object code its really coming together (Ahhh, this is where it gets tricky. Because the HUD is rendered per frame in its own call this interaction is placed here, whereas I would need to do an extra function call within the Interaction layer. Because of the one less function call, I may have gained a slight performance increase.) What I like about my approach to the matter is that it is a pure vector mathematical method rather than the one present on the Wiki (which uses a trace). It runs pretty fast at around 0.1ms for when nothing is on the screen (background code mainly) and around 0.3ms with a few objects on the screen. The reasons why it is so fast is probably due to the object culling methods I opted right from the start. Making sure that the object culling code is fast, effective and relevant was the hardest part really. I'll probably explain how I did it tommorow. I'm rather proud of my code really ... but it wasn't all my own thinking since a few good friends helped me out with it (mainly because I overcomplicate vector maths).

With the mouse code implemented I can shift on to actually doing other things which is related to the mouse ... such as object allocation (informing your team objects are available), guiding them around and so forth. It should be more fun... maybe!

Oh, I've finished University now and I've started working. For those who don't know, I was training to be a pharmacist in university and now I am an intern pharmacist at a community pharmacy. So it means money and time in different aspects. When I had time in university it was in large chunks but I didn't know when and for how long. Now that I am working when I come home I know I've got 2-3 hours every night to do stuff ... so I spend around 1 hour to do code ... so its time on a more consistent level instead. I don't know which I prefer really. As for money, its pretty obvious because I now am doing 40+ hours a week and getting paid for it, instead of paying someone else for me to do 100+ hours (study).

13th of September, 2005

Annoying. Sigh, basically I am utterly dissapointed and annoyed by a particular company that sells computer gear online. I ordered the said part at around the end of June. In the second week of July I got a lovely email telling me that they've decided to stop selling to the public and started focusing on a lan event ... thus will send me my money back. Still to this day I have not received the money. Its utterly frustrating and well, being a poor student and all its really, really annoying!!! Well, thats my rant about the crap service of some online computer part dealers.

I've been doing some more coding, and I rewrote some of the menu stack code which incorporates the use of tags as window stacks. That way, instead of sorting the menu stack by class (which was the old way), that is now abstracting into just sorting by tags. However, to retain the windows like feel, what I had to do in the end was always force the desktop to be a index of 0, next came the array of windows (which don't get sorted) and then comes the stuff on top. The stuff on top needs to be layered properly, or strange things occur. For example the MainMenuBar needs to be one the last feel windows otherwise it gets hidden behind the desktop ... its not the most perfect system in the world, but it is getting better.

I also got hired by a game studio called Lucky Chicken Studio, working on a Unreal Engine game. This will be quite a lot of fun, and I get to work with AngelMapper which will be great.

In other news about UT2006, I've gotten to the stage where matches can start to be played now. One of the things I didn't particularly wanted to do was to subclass each gametype and some how insert new gametype code into the preexisting ones. However, while this approach would mean that a lot of custom gametypes would be playable, it does mean that mutators will be severly disabled, either that or I would have to mess a lot with the GameRules. In the end however, I also need to use the HUD for a lot of other things and well .. it just gets to messy. So I decided to simply subclass the gametypes and work from there... there goes an hours of thinking wasted. Oh well... till next time.

26th of August, 2005

Hmmm, been meaning to write to this but haven't had much time these days. Due to several things such as university and maintaining a social life. This is the final year of university for me, and since its heading towards the end of the year all of the full year papers and assignments are all building up thus causing a great deal of time to be chewed up in that.

However, some of my projects have been getting some loving while some haven't. I've taken a short break on coding anything related with UT2006 for a bit (ending soon) but to keep you guys updated on that, I've coded in the basic AI which handles the coach AI as well as the player AI. So now, coaches are able to search and hunt out for suitable players that are based on the players skill and money wage expectation and players are able to respond in kind. As the game progresses more variables are expected to go into the judgement of this such as Skaarj coaches are more likely to hire Skaarj NPC's and so forth... to add a little realism so to speak. So a start on the big hurdle of AI has begun.

I've ressurected my older project called 'Champion'. I don't have overly too much to say about this just yet, but its shaping up nicely... the tech demo anyways. From the tech demo, depending on the response of it, I will see if it is fit to pursue this mod. More details on that a bit later however,

Well, time to go and get some V (Red Bull kind of drink) to feed the caffine addiction.

21st of July, 2005

After all the time and actually implementing it, I feel a little silly as to why I didn't implement this in the first place.

When I first start rewriting the Interface code, one of the key requirements was that it required the ability to be able to switch Styles on the fly, so I implemented a new method of drawing but that was all script based. Being script base I was able to change the style of the interface (uWindows 2) anytime I required as well as creating new styles without object subclassing. Secondly the other benefit of that was non-static Styles, thus allowing dynamic effects to be possible such as the fading in and out of buttons, or button overlays that did fancy effects (of course not limiting to buttons). The only real problem with it was that it was slow. It wasn't so slow that you'd have a bad experience as such while using, but rather each window took up quite a lot of the game script time which tied up the FPS. I optimized the code more and more, and until now it was pretty much as compact as I could ever get it. However one major thing completely skipped my mind, until today. Why not grab the style definition from the ModuleInfo class, store it in the GUIStyle and then switch back to native rendering? This was such a simple concept, yet it completely skipped my mind. I had no idea why I didn't do it. So implemented the idea (it only took a mere 20 minutes to code it) and eagerly awaited the results. I gained a mere 10 fps, which isn't that much ... but this was on the desktop. When I went to open up windows, I noticed that the dip in FPS was very minimal, in fact, it hardly dropped below 100. It was amazing, that so much could have been achieved from such a simple concept. So now, I not only have very flexible windows code which is relatively easy to use (compared to UT99's uWindows) its also fast. W00t!

Later that day I also coded a simple vector renderer. I'm able to render wireframe meshes (meshes that being composed of vertex data points and edge data [Polygons will be supported later]). It was a quick test code to see if I could do it in a fast way... it chews up about 6 fps to draw a 8 vertex cube, which is pretty fast. Its a pretty neat thing, but it probably won't progress much from there unfortunately.

18th of July, 2005

I've finally fixed a lot of miscellaneous bugs that were bothering me in my iteration of uWindows. Those bugs only really existed because I had previous built a lot of uWindows on top of the pre existing interface code. While I am still largely using xInterface and GUI2K4, it occured to me that I was dealing with a lot of code. Not so much in terms of the amount, but rather a lot of code written by two different people [Joe Wilcox and Jon Prestenback]. While reading through a lot of their code you could see a difference in the coding styles and approaches used to solve similar situations. It also appears that Joe doesn't mind to write native code while Jon sticks strictly with script, although this could be because GUI2K4 was based of xInterface anyways. While it is obvious that native code was required for the Interface due to speed, I think certain things could have done without being native. Those bugs were somewhat due to the existing code and how that existing code worked... it took a bit of digging to find it, but in the end it wasn't too hard. A few bugs are still lingering around, but nothing to serious.

16th of July, 2005

I finished up the last bits of the remaining code base that was left on the submenu capable GUIListBox. This would allow other areas of the interface to also benefit from having sub menu capable list boxes. As I finished up the code I suddenly realised that I could have coded the exact same thing in an entirely different way, which relied on OOP a lot more than the current method I employed. What I did for the current version was that I had one master GUIComponent which controlled all the sub menus (They were all GUIListBox's by the way). The master GUIComponent was responsible for creating/removing sub menus, positioning them and so forth. But then I thought, hang on ... why didn't I just make a GUIListBox that was responsible for one set of sub menus, as in you had one GUI List Box that control a single branch. The branch would then handle its own branch, and so on ... which is essentially the same thing. The underlying difference is that each branch was responsible for itself and its child. I believe they would look similar in code design, but the key difference is that you could have different properties per branch, rather with the current method, it is per tree. I could make it so you could customize each individual branch ... but it does mean the code would have search through the childs. Luckily, as this isn't real time the actual existence of the current method is still justified in that it still does actually work ... although reiterating through it sometime to make sure it runs really fast might be a feasible project later on. But, don't you hate it when things like this happen?

15th of July, 2005

Some new screenshots of the current development of both Chaos Engine and UT2006.

Well thats all for today. Time for some sleep.

5th of July, 2005

I started work again on UT2006 and it is progressing very well. When I stumbled across how exactly the player interacts with the businesses that open up during the game I got a little stumbled. I wanted to offer the player freedom in how he/she spoke to them as the business owners themselves were also NPC's just as the tournament characters were also NPC's. Thus I really wanted them to be able to respond in more ways than just a simple, here is what you wanted to buy, kk thnx bb. So I began thinking of the different conversation systems that were already implemented in games that we see today. First there were the old school approaches which used the text based entry for players to enter their 'conversation' lines as such. This was very simplistic and it did not offer much chance to allow for emotions and feelings to be put into what their character would say. Of course, this was impossible to do as the game could only respond to what the programmer first coded the NPC like. Therefore it was restrictive in what the programmer/beta testers could think up of. The second approach that we have here is that we simply give the player a list of choices that he/she can make. While offering a good level of choices would allow more 'complex' lines to be used with 'expressed' feelings of the character ... there was still a restriction in that the choices would only be present if the programmer/beta testers put them in there in the first place (I am aware that some games get new options opened up when events occur, but keep in mind that those options wouldn't be there if they didn't think of them in the first place!). While it is impossible with the time given to write an AI that is capable of understanding English (Also means problems for people who can't speak English!) it is also practically impossible to have any kind of static AI which could actually converse with the player. So, I had a brain storm of how I wanted to approach this delimma. The way I've decided to do it was to have a generic <VERB><NOUN><EMOTICON> parser instead. Verbs basically imply an action, but it can be used a tier 1 convesation option such as:

• Talk about food
• Talk about movies
• Talk about code

The noun could thus be a tier 2 conversation option, and it would end there. But this only provides at best a two branched depth conversation to each branch so to speak. So the next part to add was a dynamic node system instead. A few other people suggested to me to use arrays, with arrays, with arrays in them. But this is unmanageable, especially if the conversations get very complicated, or if the conversations were able to change. While technically programming that is a piece of cake (just code a decent look up) it is very limiting in that players would just choose the right choice options and thats it. It would also lead to a lot of redundancies if the coversations merged with each other. My node linked system uses a different approach. Two arrays are constructed which contain every possibility of both the <VERB> and the <NOUN>, called Verbs and Nouns respectively. Each array was built up of a struct containing parameters in which a look up table could be generated. A string is used as the lookup 'table'. A string simply contains the list of numbers using the comma as a seperator. Each of the array elements is a node. Thus each node has its own lookup 'table' of possibilities. So as you travel into a node, it would look up the next node and so on. This allows for endless amounts of branching as well as merging without having to redo any data. You could also have conversation lines that are activated by appending to the lookup 'table'. It being a string allows for easy adding.

Thus the <VERB><NOUN> system works quite well for what I am wanting to do. Also a delegate was also assigned to each conversation line (which has its own unique ID assigned by the programmer), which allows other objects outside to perform a function when the NPC says that line. So this also unifies the system a little more as well.

The <EMOTICON> system isn't yet implemented but the reason for it, is that it represents how the <VERB><NOUN> paramater is said. Using simple :), ;), :\, :|, :o ... as geustures of how the player wants something said makes sense and removes useless synoms (happily, gleefully) and so on. It is also easy to parse. How it will affect the NPC is still to be decided.

I'm rather happy with the system, and I am sure as time goes a long, new features will be added.

26th of June, 2005

About one to two weeks I started up a module for Chaos Engine called Unreal Leagues, but its currently called Unreal Tournament 2006 at this moment. I'm not sure if Epic will ask me to not use that, but they probably would as it would confuse a lot of people between my module and their own line of games. So Unreal Leagues may have to be settled with. Anyways Unreal Leagues is a module designed to show of my windows interface which I don't believe any mod has developed at this point in time. Either because they couldn't be bothered, or they didn't have the skill to do so... probably the former rather than the later since I originally got uWindows working again back at the late UT2003 era, althought albleit buggy (and slow... ahem). Unreal Leagues is a focus on the single player experience that was present in UT2004, except that the focus is adjusted to a coach position rather than just the player position. Thus as the coach you are responsible for your teams training, players, money, inventory and over a course of a set number of days you must send your team to victory against other coaches. One thing that the UT2004 single player missed were critical decisions, sacrifices, rewards and conclusions. Thus anything you did in there didn't really matter at the end of the day. Unreal Leagues hopes to change the aspect by having a permanent cast of the characters present in UT2004 and a persistent world in which what you do have real consquences both bad and good. It is a really exciting project for me, as it detracts away from using UT2004 as just a multiplayer FPS tool, but rather a tool in which a game like this can be made, which I doubt anyone thought was possible. It should be interesting to see it develop in the next few days... when I get back to my own computer!!!

17th of May, 2005

Wow, it's been awhile since I updated my journal! Now with UT2007 firmly in place I think it is time I started talking about the changes I have made to Chaos Engine. Originally Chaos Engine was called Champion. The goals of Champion was to design a completely blank template for mappers to create their own user maps from. This mod allowed custom scripts to be run from maps without the use of Unrealscript, as well as having a lot of map creatable objects such as event/trigger systems that allowed more complicated actions to occur, custom weapon editing, custom inventory editing all within UnrealED. Slowly this project changed into Chaos Engine which I first decided to use the Warhammer 40K universe for, to avoid any real IP or copyright issues, the universe would be based from W40K but no real references to W40K would be made. As time progressed and more and more core functionality was programmed, I noticed that a lot of my code could be made modular. By modular, I meant that each code part could be modified through subclasses to achieve drastically different results by a few changes to the default properties. As I progressed, I then decided to make Chaos Engine into an engine to run other mods. To avoid the whole mix up of terms, Chaos Engine is a mod for UT2004 which allows 'modules' to run on top of it. The modules require Chaos Engine for base functionality as it handles things such as character sheets, weapon object creation, inventory creation, map creation, etc etc but how characters are made, what weapons are there, whjat inventory is around and what maps look like are all dictated by the module. This is quite exciting as I don't know of any other mods that do this. Of course this may all revert back into myself to support only one universe but it allows choices for me and other people to create Diabloesque like games using the UT2004 without having to write a lot of the base engine code (mouse support, inventory handling etc etc). With the news of UT2004 ending its life soon (due to UT2007) I am making a final push to get something out soon. I haven't pimped it much as such since there is so little actual content and as we know code technology rarely impress people versus actual cool content.

22nd of July,2004

I had a day off from University so I thought I might come into a net cafe and try coding up Chaos Engine's random level generator. For a start, the levels can't be generated haphazardly as that would lead to bots not working properly or that some of the tiles choosen would block off any kind of way to reach certain game objectives. So I started fleshing out some code and reading up on the pathing system present in UT2004. As I found out, the pathing system in UT2004 has certain limitations. First of all, it was mainly accessed only by Pawn's with attached Controllers. The pathing functions were in the Controller, but they wouldn't work if the Controller did not have a Pawn in its' possession, so that was the first mountain I had to figure out (Although a little help from Chimeric told me about Pawn restrictions).

Once I got the pathing system under my thumb, all I had to do was write up the rest of the code. For those who are curious to see how I did it, I guess I can share a little around. First of all the level laid out in a grid formation. Tiles are then placed into appropriate places to link up with each other. With millions of different tiles and tilesets you could create drastically different levels. However, to prevent the game from becoming too boxy, different types of tiles had to be made which could alter the Z axis or prevent you from entering tiles at certain directions. The immediate problem this raised was the fact that if I were to simply randomly spawn these tiles, I could not garuntee that bots would work properly nor could I garuntee a map had a accomplishable path flow.

After much brain storming I figured that a path finding mechanism was needed. Instead of writing my own, I decided that if I manipulated UT2004's pathing system I will eventually figure something out. I looked at the Willow Wisp's code and it appeared to be able to follow or find path nodes which ended up a destination. Obviously this was what I needed. To simply put, the willow wisp was able to find its' way through the pathing network to end up at the Game Objective. And so I went from there... I'm sure if you thought about it, you'd figure out how I did it.

---

Category_Journal