Friday, October 19, 2012

Let's try a more industrious method to enviroment creation

Right-o, so for a long while I've been on programming duties, but yesterday after finding out I had coded duplicate functionality for something else my partner had done (lead designer also). I decided that 1: I have no idea what's going on in the design, 2: I enjoy doing art better than programming, 3: whatever man, there are still 3 environments to go (which I hope doesn't change on me later). So yep, now I'm going to work on two of the three outstanding environments (the apartment could use some more love too) which are a gym and a park. I had set a self-imposed deadline of having level blockouts done one per day so that I would have a start for both by Friday, but level design is one of the many things I under estimate.

Whatever, enough words, here's my progress so far:

To be a locker room

To be a transition area between the locker room and the main areas

To be a gymnasium, setup with basketball nets and a suspended indoor track

To be a workout room overlooking the pool

To be a pool

To be the entrance to the environment with a snack area
Coming up with floorplans are suprisingly a pain in the ass for just arranging blocks. I tried to plan for lines of sight - so that there is always something interesting to see and explore, and to have very short travel times when walking between main areas. I've tried to design the floorplan for the gym a few times before and always got sidetracked placing areas that the player would never go to ( like offices) or having unacceptably long and winding corridors between areas.

As you can see yes I have blockouts of the level, no they're not any good at describing what the final product should be, so I think I may need another day working on these images. What I'll likely do is use my poor painting skills to paint over these screenshots and see how that works out. Once these poor excuses of concept art are done and approved, I'll be doing the same for the park - maybe even the hospital if they turn out to be not terrible.

Tuesday, October 16, 2012

Experimentation with procedural levels

Well while doing the loading bar, I found out some neat commands; Application.LoadLevelAdditive namely. And in a case of "when you have a hammer, everything looks like a nail" decided to change how levels were setup. Since the game only takes place in 4 environments and has much more levels I thought it would be good to build the levels procedurally by reusing the environments by additive loading them into a blank scene that contains the relevant level data.

It works but on experimentation it leaves this slow blank awkward pausing screens that I rather not deal with. So scrapping that idea, I just dumped all the level data into the start menu scene, deactivated and ready to go on level select. It's not ideal but it works. The issues with this method is that it is harder to control scene specific objects with a script that isn't even based in the same scene. - Say like I needed to script some doors locked, I probably would have to create a level specific reference list script in the scene just to get easy access to variables needed to properly setup the environment for the current level.

Also got the generic event system going and it seems to work without problems for purpose of objective tracking, haven't extensively tested it or seen how it handles large amounts of data, but handle problems as they come along I guess.

Thursday, October 11, 2012

Generic Event System

Well continuing on from last post I got that resolution independent GUI layout helper function done. It took the whole day because I basically over thought the math necessary to scale elements down between a minimum and maximum. Figuring out an equation for linear interpolation of 2D elements, or scaling by the difference in area and then applying Mathf.Clamp on the results? I went with the latter, much easier to code and understand.

So onto the event system which is supposed to be my silver bullet for solving all my woes in tracking objectives and attachments progress. It's under 40 lines of code.  - Well uh maybe I learned from the GUI code kept it simple, stupid. All it is, is a glorified list with time stamps, so yes the size seems right. But like everything else all it's dirty hidden problems will only show themselves through testing and implementation. Now for the fun part of hooking it up and giving it real feeds and having objectives query it.

Also on the to do list is now loading bars/ screens, and run time asset loading. I've got loading screens working now thanks to a quick Google search and the ease of use that is sometimes Unity. Just need to work on making nice progress bars, but I'm sure a search will turn up something.

As for run time asset loading, well I'm not looking forward to that. Yes there are numerous benefits to the technique, like patching without having to recompile or redistribute the whole folder, but then I also need to worry about asset management and file type parsing. For a first game, it doesn't strike me as a priority over getting shit working and actually enticing to play.

It always looks like there is no end in sight, but just gotta get what I can get done.

Tuesday, October 9, 2012

Got a working prototype finally

Well it's been awhile, I honestly don't even want to keep track of how many days it has been, but last Friday I managed to scrape together a crude, but working version of the game - main menu, levels, objectives, actions, and recognizing victory. Of course since it was all done in a rush and with lots of hard coded quick fixes it is an absolute mess and I have to go back and reorganize and improve everything, but at least it's a step forward.

WIP Start menu, the bars are animated.
As for today I'm going to make a tool for converting pixel coordinates into resolution independent percentages that should make creating a GUI layout for multiple resolutions a lot easier and automated.

What it should take into account is the screen resolution the layout is currently designed for, where each element is and what point it appears to anchored to and then generating the coordinates for any resolution that it was not designed for. I don't think this will be that hard, so today I may also be able to get started on a generic event system.

The generic event system would be a log of every action recorded in one place that would allow for classes to tell each other what they are doing without explicitly hard coding in conditionals into their functions. This is useful for checking for achievements and objectives, which as of now are hard coded into the relevant behaviors. Anyways more on it as I go.