Quick Update and tip on images

So I've been out and about this weekend, watched a couple of films as well, so afraid no development on the game.

However I decided to take some time sourcing images to give me some ideas of what models I'll be using. I've had to organise a lot of photos already from TPoC days, but I think I've just doubled my image library for more specific model photos over night!

I thought I'd share a couple of tips on mass image saving as well, since a lot of what I found where hosted on third party image sites, meaning I can't use DownThemAll to one click download all image links. I managed to find another Firefox extension called "Save Images", which has a nice feature of saving images on webpages based on some filters you apply (minimum dimension, file type, size, even regular expressions). One of the most brilliant feature is saving images from all tabs, or in my case save images from all tabs to right.

Essentially my workflow is now, come across an image, use Google Image search to reverse search for sources. Find a gallery of pictures with third party image hosts, select and batch open links in new tabs, save images to right and I'm done.

Obviously there're picture boards as well where I can just search by model name.

All the freeloading though had made me feel a tiny bit guilty, so I actually paid for a year long subscription to MetArt which has some pretty nice sets. I can't afford to pay for X-Art as well which is another of my favourite.

Anyway, if you have any suggestion of models, please feel free to comment.

The current lineup is looking something like this:

Adele B

Alena

Bree Daniels

Caprice A

Danae A

Indiana A

Jenny Poussin

Malena Morgan

Melisa A

Ulya

Schedules

SymCity is meant to be a sandbox game that allows player to explore the world at their own pace. To add variations to the world, it has to evolve with the player's exploration. The most obvious choice of variation is to modify the world with events - and naturally scheduled events plays a fundamental role.

The concept of schedule event is simple:

Player's actions advances time, and at designated times, events will be triggered: locations become accessible; character moves to different location etc.

There're different ways of doing this depending on the scale of the game - you could have nested conditions setup in your game if it's fairly linear. I suspect a lot of story driven RAGS games with "day" counters use this approach, by defining specific times when certain events will be triggered.

For a sandbox game, this is just won't do.... So let's try something else. For my approach to this problem (credits to Anonymous's suggestion as well on TPoC blog earlier this year), we'll need:

Time_now - A time variable.

This is a Date Time variable, so we can do simple operations like "add minutes" or "add hours" to it. This is basically what day and time it is in the game world.

Schedule_List - A multi-dimensional array that keeps track of the schedule.

The MDA holds the scheduled time, threshold time, schedule pattern, timer name and variable name. The list is always kept in ascending order. More explanations later.

Active Timer: Schedule-Checker - Checks the Time_Now against Schedule_List

As the schedule list is in ascending order, this timer just does a while loop to see if the first "scheduled time" on the array is due for processing, if so, it calls the next timer:

Inactive Timer: Schedule-Trigger - Manipulates the Schedule_List array

This is where the magic happens. This timer checks the "threshold time" to see whether we still want to execute the associated event. This is due to the nature of some actions / events potentially taking up several hours - by which point we might not actually want to execute the event anymore.

If we want to execute the event - then we simply execute the timer by name stored in the array, and supply suitable variable to it.

Next we need to remove the top item from the Schedule_List array, because it's been expired (whether we triggered the event or not). But first we have to determine the next scheduled time and threshold time, using the schedule pattern.

Since this next part is purely to manipulate the array data, I do it by javascript. Read the schedule pattern, calculate the next scheduled time and threshold, push it to the end of the array, sort the array and return it. Now we have the next scheduled event on the top of our list!

RAGS Code below.

Timer Schedule-Checker:

Variable: Set (Javascript): aStr1, [true if Time_Now > Schedule_List(1)(0)] Loop: While: aStr1 Equals True Timer: Execute Timer: Schedule-Trigger Variable: Set (Javascript): aStr1, [true if Time_Now > Schedule_List(1)(0)]

Timer Schedule-Trigger:

Variable: Set (Javascript): aStr1, [true if Time_Now > Schedule_List(1)(1)] //passed threshold time yet? Variable: Comparison: aStr1 Equals False Variable: Set: TM_[v:Schedule_List(1)(8)], [v:Schedule_List(1)(9)] Timer: Execute Timer: [v:Schedule_List(1)(8)] Variable: Set (Javascript): Array: Schedule_List, [pop the first schedule, refill the schedule time if next available time exists, set threshold time, push back to array, sort and return]

Note 1: I actually cheat a little with my array by having titles on the first row, so rather than calling picking Schedule_List(0)(0) for the first scheduled time, I pick Schedule_List(1)(0) which is actually the second row.

Note 2: Rather than setting and retrieving Timer Custom Properties, I opted for using variable variables for quicker variables setting. All Timer's variables are named TM_[Timer Name]

I realised after writing this post that I should probably allow empty thresholds, and if threshold time is empty, then execute the event regardless. But hopefully this gives you some ideas of how to schedule events in your RAGS game.

I'm not releasing the code for this because the Javascript to calculate the next scheduled time is highly specific to SymCity's needs (I took some shortcuts) - so it's not a fully featured javascript function. If you're able to tweak it to your needs, you can probably code it from scratch (it's 2000 characters long); if you can't, then it's probably best you avoid it.

If you really want to play with scheduler but are not confident in coding the "next scheduled time" with javascript, you can always just build a list using actual time and skip the schedule pattern.

Hope this is of use to some of you guys :)

Day and Night Picture Mechanics (Set: Room Picture tip)

So far some basic testing I think the scheduler is fully working now. However today I'm going to talk about something else first.

For added game emersion I've requested help with getting Day & Night photos of locations, so that there feels like a real sense of time progression. Currently I'm just setting a variable to "Day" between 6am and 6pm and "Night" all other hours - however I'll probably use variables to define the "Daylight hours" so season change can be "felt" as well by different Day Night Cycles. Afterall, I do have plans of using Day Night Cycles for some game mechanics later on ;)

So back on topic - to show the difference between Day and Night, the obvious choice is to set the Room's Picture to the Day pic or Night pic dynamically based on time of day.

Now since I always go by code efficiency path of thinking - <<Player On Enter>> became the obvious choice of setting the Room picture. But actually that doesn't make any sense at all - as time can progress even when player's stationary and performing certain actions. So, I need a turn based Timer to do this.

I could set a condition to check whether the room picture needs updating, but the effort that'd go into checking it probably throws out the benefits of avoiding to set an image unnecessarily - so the code instead becomes:

Condition: Multimedia: In Group: [v:Time_DayOrNight]-[room.name].jpg
Room: Set Picture: : [v:Time_DayOrNight]-[room.name].jpg

Let's see what happens:

So turns out there's a "bug" in RAGS that means room data aren't updated if you change them (Room Display Name, Room Picture) while you're inside the room. If you leave the room and return however, you'll find the changes made.

I started by adding a couple of commands to throw the player into a temporary room and returning them immediately, which fixes the image problem, but comes at the cost of another bigger problem:

Since my player has actually moved rooms, all the "on enter notifications" appears in the text window - it is as though the player is seeing double, and it's not even 8 o'clock yet! The bigger challenge is also the fact that I have on player enter and on player leave commands (calculating time progression for a start), so it's not the best solution.

While considering other options, I accidentally come across the other Room command:

Out of curiousity I tried out the command, and funny enough:

So it seems that while Steve was building RAGS, he considered the need to update the room's picture when the game updates the layered picture, and refreshes the room picture immediately. Unfortunately having tested it, the refresh was only localised to the room picture, rather than an interface refresh - as I tried updating the Room Display Name and THEN set the layered picture, and only the picture got changed.

I've requested the bug to be squashed, so hopefully we can do things like renaming rooms from "House" to "Living Room" on enter to make the transistion into buildings more.... emersive.

Debugging Smartly (or how I wasted an evening trying to fix a bug that didn't exist)

So I decided with half the map on it was time to put the scheduler in place. I'll explain the mechanics in the next post, but basically I have an MDA that stores the schedule in a semi-cron fashion, with "next execution time", "threshold time", "Timer name" and "Timer input" stored as well.

I had the option to populate the array with the next execution time and threshold time by hand, or use javascript to initialise the values (I had already written the javascript to return the "next execution time" anyway.

So, Player: <> > Timer: Execute Timer: Schedule-Initalise. Put the initialisation code in the Schedule-Initialise timer, Preview the Javascript and Test the Javascript - returns a nicely populated list of time. Let's test it via debugger!

Not what I was hoping for. Started experimenting with Set RAGS Data, even resorting to creating a blank array to see whether it's unable to set the array, or it's returning wrong values.

30 minutes later, out of frustration, started moving around the game just to see if anything changes (assuming it wouldn't), and hey presto:

The RAGS DebugDataFrm displays the variables at game start state, so if you have <> actions that changes the variable values, it's not reflected until you've perform an action in game to refresh the data. The code was working all along, I just wasn't looking at the result!

The tragedy is that I discovered this back from development of TPoC, but had completely forgotten about it. So try not to follow my mistake!

The Path of Corruption last alpha

Since TPoC development ended abruptly, right after I implemented the "on duty" timer (without "off duty" instated), the last version essentially had all erotic content locked!

Well here's a re-release with a tiny bit of bonus content:

The Path of Corruption Alpha 0.2.7.2 (unrestricted)

Just to confirm, I will not resume development on it, but I'm not releasing the code either because I plan on releasing demo code for different mechanics in the future anyway. I will be happy to help with any programming questions however.

Compass Demo

So back in development of TPoC, I asked myself: What kind of features would I like in the game? What would be the best way of doing things? And one of my bug bears was navigation.

The compass never really did anything useful, and I always found it hard to remember paths to different locations. I've seen other developers using various ways of tackling this problem, map inventory, player portrait map etc. But nobody seemed to have played with the compass itself.

Soon after exploring the RAGs designer I came across the line of code that lets you change the compass image:

Media: Set Main Compass Picture

Now considering the Compass is much bigger than the Room Picture (just above the up down compass), it seems logical to me to update that with a map, where the green dots indicates the direction you're heading towards.

So here's the code:

Player > Actions > On Player Enter
Condition: Multimedia: In Group > ![room.name].png > Compass
On Success: Media: Set Main Compass Picture: ![room.name].png
On Failure: Media: Set Main Compass Picture: <Default>

What the code above does is that it first checks whether the compass image exists based on the room's name. I added the ! in front because [room.name].png or [room.name].jpg would be more sensible choice for the actual Room Image. Now RAGS doesn't have a command that checks if an image exists in your media library at all, so I've picked the Multimedia: In Group as a solution. All you have to do is to add the compass images into your game, and put them in a Group - I've named mine Compass - and check if the image exists in that Group.

If the image is found (On Success) then replaces the default compass. If not, you don't want to do nothing, as the last compass image would be left behind, defeating the point of intuitive navigation that you're trying to create. So you set the Compass Picture to <Default> to reset it to normal.

When I used this for TPoC, I decided to make the map exactly representative of the zone / room I'm in. The problem of jumping from one zone to the next was the sense of continuity.giving little feedback when you move around the world as the map would flick from one zone immediately to the next.

To compensate for this, I've "zoomed out" a little with the current version, which gives more of a sense of actual movement when you navigate the world.

The demo code is here, feel free to have a play!

World building

I have always struggled with the RAGs room system. Whilst it serves the purpose of building a world for text based adventures, it's somewhat limiting when we want to really go the extra mile.

I suppose I've been overcomplicated things, but the perfectionist in me wouldn't rest on this one, but I see indoors and outdoors travelling very differently. Indoors you move from room to room, outdoors you follow roads and paths. As such the "room to room" approach of travelling with the RAGs map system feels somewhat limiting.

Let's say you're walking on a busy road which is linked to lots of locations - you have 7 possible directions to choose from (I'm subtracting the direction you came from) excluding up/down and in/out. However at least one of the other exits should really be where your road leads to, leaving you with 6 directions. At crossroads you eliminate two more and are left with just 4 directions to choose from. This is before the confusion of which direction leads where.

In TPoC I adopted the "NSWE" for roads diagonals for buildings, but that means I couldn't create curved roads. So this time round, I'm changing it entirely.

Similar to TPoC, outdoors navigation will follow roads, streets and paths, however buildings will be represented by Objects that you can choose to enter.

Pros:

• No limitation to buildings per location
• You know intuitively what building you're entering by selecting them
• Optimised "accessibility" mechanics by checking accessibility upon entrance instead of changing room exits when accessibility is changed
• Consistent navigation logic throughout game
• New locations can be added easily later on in game

Cons:

• Slows down overall navigation
• Breaks away from typical RAGs game navigation

Unfortunately due to the scale of the game I'm planning, I'm not asking for feedbacks and just going to go ahead with it. Which means it's a "play it like I intended it or don't" policy. I hope if I can push the game out there to the community, it'll give people some more thoughts as to future game developments.

Anyhow, after some brainstorming sessions, I've drawn up roughly half the map so far:

 

I haven't added the university campus, another town, rural area and nature preserve up north, and I'm planning on having a couple of islands to the south.

As you can see, the scale isn't small and I still have some decisions to make, but my plan is to make it a growing exploration map, akin to Zelda, Metroid or even Bodywerks, with some differences. Whilst some areas of the map would be inaccessible to start with, you should have pretty decent access to all the key areas - but start unlocking new locations as you progress.

Finally, day night cycle... Now this is going to be ambitious, but for added "immersion" I'd really like to add day AND night versions of outdoor locations. I've been googling night photography and finding day time photo of same locations, but it'll be hard work. Perhaps I'll start with daytime photos and gradually change the photos over development phases.

A list of Ideas

So just to help me plan out my future posts, I'm putting down a list of ideas I'm currently working on or planning on experimenting with. If I get hit by a bus tomorrow, you guys are in charge!

Dynamic Rooms

Building your world with a simple array and some "On Leave" timers

What to do with the Compass

The compass sucks, we never knew what to do with it. In TPoC I decided to turn it into a mini-map of your current location. By let's take it further: how about a slightly larger map view (regional map) with a "you are here" dot?

Forget about locked doors

RAGs' door mechanics is a lot of work, unlock door (deactive unlock action), open door (check if it's locked or closed, change exit to active, deactivate open action), close door etc etc. Simplify this with "Enter" action which transports you to the next room if door's opened.

Scheduled events

Overlay stats

Since most of us don't want to do the time consuming and often awful looking photoshop cutouts just to allow overlaying of images, we rarely utilise it. Well we all know the status bar is too limiting, so why not overlay some key stats on the bottom of the main media screen? Research barometer, Notoriety rating, equipped items.

That's it for now, more to come later, hopefully.

Dynamic Characters

Most of you would probably have played DollMistress's Overseer. It caters towards those with Latex, Living Doll and Bondage fetish in particular, that's 2 out of 3 for me. It's also an ambitious game to push the envelope in terms of what complex mechanism can be achieved.

I won't go in depth about all the game mechanics bar one today - the drones.

Overseer lets you entrall victims in your base or go out to hunt for some yourself, you put them through the slave chamber and they get turned into objects - literally.

I guess the programming reason to convert RAGs Characters into RAGs Objects is to separate the code between individual characters and individual drones. Rather than having the code for every possible drone type action coded into each character, DollMistress can create the drones separately from the characters you capture on the first place. A second good reason is probably because Objects are easier to copy and paste than Characters (seriously Steve, Characters and Rooms should be organisable like Objects and Images).

Anyway, I thought this was a genius idea and I'm definitely stealing it. But when thinking about how I'd tackle this concept of drone types and pre-slave characters, I hit upon another idea:

Why create so many drone characters when I can dynamically change every character's properties anyway?

I plan on having lots of characters in my game, and the prospect of creating so many characters, and typing out all the properties for each character etc frankly does not inspire me at all. Now I very much plan on extrapolating all actions into Timers as possible, so as far as I know, I only need to maintain a list of character names, portraits, and attributes in an MDA, and a few template characters and we're good to go!

Now the problem with this is, you can only have as many characters in the same room as you have dynamic characters, so a decision had to be made. I chose 3 but this can be easily extended by duplicating these dynamic characters anyway. All actions will basically be "parse the character name to the timer" affair so there will be little to no code tweaking within the characters themselves.

Second problem - how do you now track what characters are in which room now? It's a serious question as well, since you can't just leave your character in a room and forget about them - and the solution why simple conceptually, does take some coding with an "On Each Turn Timer" - keep track of where your characters are with an array and move them into the room (and don't forget to move other characters out).

For efficiency reasons I chose to keep them on the map template so you don't have to loop through all your characters each turn, so I just have to pick the room name from my array (using direct array ID reference) and figure out who needs to be here, and convert my template characters into appropriate characters.

So far so good. But why stop at characters? Next time, I'll talk about dynamic rooms.

Fresh start and whatever happened to TPoC?

So earlier in the year I started what I knew was a somewhat abitious project of creating a multi-chaptered RAGs game, spent a few weeks on it, and then disappeared for six months.

Well, real life got in the way. I was going to write an apology after building up the hype for it. I had some ideas that I really wanted to see to fruitation, I wanted to be the new kid who's going to show everyone what untapped potential the RAGs engine has.

I chose to make my exit quietly, for personal reasons. Part of me was still tempted to return to the project, but after a month, two months, a season and the drive to return to something this big just fizzled out.

Luckily, although time will tell on this one, all is not loss. Captain came along with the Lilith Device and blew everyone away - a formula that worked perfectly for RAGs AND our fetish in Erotic Mind Control. Then DollMistress came along and really set the benchmark of what one can really do with RAGs.

I was utterly blown away by the sheer content in these games. However, as a programmer... what I saw as well were potentials and inspirations. Overseer planted the seeds to the mechanics in my little experiments with RAGs, and both gave me some directions in terms of what I really want to go with my next game - again, time will tell on this.

So I guess what I'm saying is, bear with me, and I'll post my progress as time goes by. I'll share some of the ideas I've developed so far, and some I'm planning on implementing - so even if I don't finish my project, someone else in the community will hopefully be able to take up on them.