Gaming Your Way

May contain nuts.

Killing the beast, one start at a time ...

I think I mentioned one or two times how much I don't like the maker of Flash. I really wonder what kind of morons make the decisions there. Even though I mentioned my utter dismay with Flash one too many times, I still think it's a great piece of software that deserves better than what it is getting from it's makers.

Remember the "Flash is the gaming platform for the net" blurb? So what has happened so far?

I really wonder why they don't start to push Flash more, trying harder to establish Flash as multi platform development environment and getting rid of the "all you can do with it are annoying ads" notion.

Oh well.

(And just to mention it: who the fuck is responsible for the shit UI in CS6? ... No I'm not sold on Creative Cloud either and I *never* will be)

Anyway the point of this post is closely related to my move to a new PC and the re-install of CS6, as after I was done installing it (ok, just Flash, Photoshop and Dreamweaver out of the Master Suit), I had a look at the autostart panel in windows' (8.1) TaskManager.

Big A has added 6(!) new entries to the list:

  • Acro Tray, Adobe Systems Inc. (ugly icon, btw)
  • Adobe Acrobat SpeedLauncher, Adobe Systems Incorporated
  • Adobe CS6 Service Manager, by ... right
  • Adobe Reader and Acrobat Manager, ...
  • Adobe Updater Startup Utility
  • Switchboard Server (32 bit)

WHAT THE FUCK is all that shit? (This is a rhetorical question).

I like to mention that everything still works fine without these.

All in all, 17 entries have been added to startup by various applications, of which all but 5 remained, plus one I set up myself.
Some of the entries that remained:

  • Acronis with 2 (no need for the image mounter)
  • Logitech Setpoint (for better mouse and keyboard settings)
  • Deamon Tools (for the need of a virtual drive at times)
  • 1 of the 2 NVIDIA entries (no need for the capture service proxy)
  • LanLights (the one I set up intentionally, a neat little app to show network traffic, also has a neat tray icon)

While I was at it I gave the registry startups a good bash (using CCleaner) and found more Adobe entries to kill (Adobe Bridge to note one) and if you are as annoyed as me about Acrobat adding his dirty fingers all over the system with adding "Convert to PDF" to each and every context menu you can get rid of it with this:

(This is for the 64 bit version AND cs6, but you should be good to adapt for other versions quite easy)...

regsvr32 /u "%programfiles(x86)%\Adobe\Acrobat 10.0\Acrobat Elements\ContextMenu64.dll

To run this little gift, use "Run as Admin" while starting CMD and reboot afterwards.

... and now have a nice week, I'll be coding like a mad god on non-game stuff.

-- Oliver / nGFX

Messing up scale - big time

I've been doing 16h coding shifts for the last couple of days (shipping deadline ahead) so I couldn't face touching the prototype game afterwards, which means no update on that this post.

Anyway, after Christmas I decided to rebuild the CSH22 MOC I've done some time ago (the original post is here). One thing I noticed while building the model with "real" Lego parts that the base and the roof (which looked OK as digital model) are not very stable or buildable, the obvious conclusion was to redo them before building the model.


The old base, without roof.

That said, it took the better part of 5 evenings to redesign the base and the roof, keeping an eye on stability and making it buildable. To say I went a bit over the edge with it, barely covers the amount of new parts - roughly 760 to be precise - adding up to 1254 parts for the whole model.


The new base, again without roof. The pool is all new, too.

Yesterday the last bag of parts finally arrived (Lego Pick-A-Brick is your friend here) and so while having my morning coffee I started to build the base plate and was - mildly - surprised how fucking big it is. For some odd reason I always have that with Lego models, wondering how I could have underestimated the size by that much.


That's a) a bad picture and b) 32.5cm x 31.0cm of base-plate goodness.

Oh. Well.

To end this post with something to look forward to, next post will be about messing up a game's items with exposing values to the Unity editor and how something I call the "ItemFactory" saved the whole enterprise.

... and now: there's a deadline ahead, ahoy.

-- Oliver / nGFX

And on the 8th day I created a mini-map.

With this title in place, I don't think I have to write much about the technical details, do I?

I read an interview a few days (or is it weeks?) ago (forgot who was interviewed) and one of the things that were said was something like "mini maps are a lazy design choice". Maybe.

I still needed something like that in the prototype game, one reason is that it shows where things are, but I don't want to show a map. In reality it works more like a radar, but honestly who is going to search for "game development" and "radar"?

...

And here ends this post. I got myself a new PC, you see. Seems like I now got most things set up and running again (I could have just migrated my old stuff, but I do like a fresh start now and then).

Well, tomorrow is Monday, so it's time for a new post anyway and I try to push it in between some very serious deadlines.

 

-- Oliver / nGFX

Decision Style #4: Activity-Focused Design

I'm still awe and wonder about what shit comes up when you search for our post titles. This time it's a tech-talk-bullshit gem.

Anyway, it's time to get going with the prototype game and start piecing together all the little tools written so far. I mentioned it on g+ already, but I reached the point where I needed more than my usual ToDo list to keep track of what I want/need to do next.


Just a small part of my "map helper"

The first map I used for testing was quite big and complex and with some 20 rooms and even more doors a bit - shall we say - shit to keep track of. So I invested 2 hours to make a smaller map, then rendered it out and drew my notes on it (making revisions on paper is a bit messy after a while).

Color coded rooms help to maintain overview and layers in photoshop make it incredibly easy to keep track of items to place and doors to connect. Right now I'm placing these in Unity and wiring things up to be able to do a "play through" with the main objectives: find docs (USB drives), codes and key key cards and avoid being caught.

The next thing on my ToDo list however is the minimap, which wont show you the location but items, guards and cameras (and their "senses"). With that in place it's finally time to add security to the map.

Maybe I should add a trigger for the exit first so I can have a "well done" screen up and running (and make it feel more like a game than a pure game mechanics test bed).

-- Oliver / nGFX

Inheritance is your friend.

Let's talk about items in the game prototype (which is actually a bit more than a prototype if I look at it).

One gameplay element is finding keys / codes to open doors (although you can also hack them, but that's another story). In the first version these items were separated into Doors and searchable Items, both with a lot of duplicated code, on the item and on the player object that had to interact with these items.

After everything worked like expected (ie: walk up to a crate, press the action button and wait, find the key, walk to the door and unlock it), I started the second refactoring pass. First thing added was the ItemData class, which holds most of the vital data and exposes them to the editor. ItemData covers basic items and things in the game, a wardrobe you can search through is using ItemData as well as a bed or a crate.


Basic ItemData in place.

I already mentioned that doors are a bit tricky when it comes to making them work with generic code, so adding ItemData values to a door meant some messing. As you can see ItemData contains two fields for interaction: action and secondary (mapped to different buttons) and this also the trouble with doors. Doors (at least in this game) have more than one action, based on the door's current state (locked, closed, etc) plus different actions for the same state. If you stand in front of a locked door, but don't have the key, the action is "hack door" - if you have the key, the action is "unlock door".

Exposing that to the editor is more than a major ball ache, except you want to write your own editor panel - which I very much don't want to.

This is where inheritance comes into play. So the Door (DoorController Class) is inherited from ItemData. The trick is that the code that manages the door's state also changes the "action" of the underlying ItemData. As doors are always work the same way this doesn't have to be exposed to the editor. So when the state of the door is changed the "action" is updated based on the new state. Quick, simple and clean - not as flexible as going through the editor, but that's a small price to pay.

Another (big) advantage is that items and doors now all run through the same code for displaying button hints, tooltips and message boxes, so no special cases to tackle.


For comparision: the door's editor values.

Now that this is done, I'm going to add guards wandering around the map and I fear I also need to get my head around doing a minimap to guide your around (without being a spoiler).

... and with this, "Hail to the king and his epic saga in search for candy".

-- Oliver / nGFX

The bad gains respect through imitation, the good loses it especially in art.

Friedrich Nietzsche.

I doubt good ol' Fritz had "kings" in mind when writing this, but such is life (though, respect for "kings" seem to fall apart lately...) .


Changing from MonoBehaviour to PanelSettings as base class ...

I've started a first refactoring pass today, one of many, as always. I like doing that every time I have a set of working functionalities that I can group together to make things easier to use / handle.

The code above is a part of the class that handles the tooltips in my current prototype game. The PanelSettings class is basically a wrapper for NGUI panels, adding a name and two methods: Show and Hide (which allow for no-brain fade in / fade out).

Together with the PanelManager singleton it makes things incredibly easy. Instead of creating connections via the Unity editor (read: linking panels to objects who might control them), Panels register themselves in the PanelManager to allow for easy access.

To fade in a panel it's simply:

PaneleManager.Show("mypanel");

// or, if you need a callback:
PanelManager.Show("mypanel", CallbackMethod);

As the tooltips need to be faded in out it was a good idea to use what the PanelSettings class has to offer and remove duplicated code from the ActionTooltip class.

... and with this I continue my refactoring saga and have some candy along the way.

-- Oliver / nGFX

I AM NOT YOUR F1 BUTTON!

Code won the game.

This only makes sense if you've read last week's post about FSMs. At some time during clicking and dragging states and trying to fit my idea into the corset of the FSM, I figured I need to write my own actions to make things worthwhile. So I started to write my own action. The problem is once you start writing your own, you need to find a point to stop and expose values to the FSM (that can then fetch these and pass to the next action ...).

With this working quite well, I came to the point where I needed to pass more than a single string or float, but my own class with data (or I had to pass a set of values) and suddenly the beauty of this new toy (the FSM and it's supposed easiness) started to fall apart. Years of coding took over the show, brain cells kicked into crunch mode and in an act of fury I deleted the FSMs from the game. A good deal of hours fiddling and working against instinct paid it's price and code once again won the game.

A few hours later the door control was coded and working, multi language ready, too:

 


Tooltips and control hints up and running and talking to each other via SendMessage, so no links in code are needed.

The interface for using the tooltips is unified and based on "Items" that carry a name, a set of actions and "results" (inspired by classic adventure games). So the Control panel right of the door has the "Item" component attached, it is also linked to the door (to request the door's state). In the image above the door's state is "locked" and the action for the control panel is "unlock door". The result is a new door state: "closed" and a changed action on the control panel "open door", plus the control hint is being updated.


I need more time...

Of course opening a door using a code (or hacking it if you don't have the code yet) takes time, this is also handled by the item, allowing to set a time these action needs to be performed - from 1 sec to a few minutes (it also handles if the time should reset if you leave before the task is performed).

Searching items is done as well, so if you search one of the blue boxes you find the key code for the door and can use it.

Next on the list are guards and the security cameras with these in place the map will be more or less playable and can be dressed for a quick game.

But that's for next week's post.

-- Oliver / nGFX

Strangely addictive

I've been toying with playmaker (a visual state machine) for while now and I'm still not quite sure what to think of it. On one hand it can make things incredibly easy, on the other hand it can be a huge pain in the ass to get things done.

Let's take one of the easier examples: a simple door.


Ingame door, developer art :).

All the basic FSM tutorials consist of the same basic parts: a door, a trigger and a set of animations to open/close the door. Of course you could also code the opening/closing animation... I deal with that later. Let's take a look at the FSM for this door (not as basic, though).


Even in this image there's trouble ahead.

The tutorials get along with four states: closed, opening, open, closing. When the state is closed the FSM listens to the trigger and when it is fired it goes to "opening". The "opening" state simply plays the animation and continues to the "open" state. The open state then listens for the trigger and if fired goes to" closing". Viola.

The problem is that in my case I have some more conditions to check and I want to paste some initial values as well. A door can be open, closed or locked. Additionally, if the door is open, it should test if the should stay open, and if the door is looked which key is required.

The FSM above could be done in a way better organized way, but this is the very first working draft...

...and to be honest, will be replaced by code.

I find a strange attraction in the thought to be able to do things visually and it's always worth a try, but at some point one has to admit that it would be easier to just code it the darn thing. The FSM works great, but it took me a good while to get my head into it - and there we have the result of years of coding: I have an idea how to code this right from "I need a door" and for me it is a lot of work to leave this path and break things down into parts I can built as FSM. This time the FSM lost, it may win next time.

Now with "Realistic-looking flames and colors" ...

... now that's the thing you want to read on an artificial fire log.

Prototyping stage.

I've been hammering out tiles over the last couple of days to be used in the prototype of my pet-project game I'v started. This time I'll try something different and do a very basic prototype first (before jumping right in and doing full fledged 3D models before even knowing if the idea is valid)

Though, I must admit that I couldn't resist and make the tiles just a wee bit more pleasing to the eye than plain grey-boxed ones...


Busy building the dummy map ...

As dummy maps go, this is a fairly bigger one than what I would normally do for level 1, but it's also a testbed for all the things to come. Mainly guards, cameras, locked doors and drawers to search through.

Unlike the usual pointless bullshit I write every week I have something helpful in mind for the next post ... something about culling and exporting stuff ...

-- Oliver

Prototyping the pet project ...

Oh well.

The new year started with a blast and the note that it is over already if I look at my table of deadlines and projects that need doing this year. Most of these are (of course) not game related, but that's where the money comes from.

Anyway, after the sudden and unexpected death of MTR (thank you client legal department, go fuck yourself) it's time to wonder off and play with some ideas and see if they can evolve into a game.


I'll start with a map.

Over the next couple of weeks(/days) this 2d map will be converted into a "tile based" 3d map, although a very grey boxed one (fighting my usual urge to make even these pretty from the beginning). I'll have to see what will follow next ...

And now: I need to continue coding for the e-learning web environment Dry Goods is developing ...

-- Oliver