Archive for category rQuest
RPG Project – Update End of June 2009
Posted by Joshua Smyth (Admin) in rQuest on June 29, 2009
This month I was far more productive with my still-not-named episodic RPG project – Using two monitors makes life so much nicer.
This month also marks a special occasion as I’ve now been working on the project in my spare time for one whole year now.
Time sure flies..
This month I’ve added features for NPCs to the map/world editor and spent a little time working on the datastructure for NPC dialog trees. The thing with dialog trees is that they’re not actually trees – But rather directed graphs. When you think of modeling conversations as a series of nodes which represent the state the conversation is in and a set of response options which represent a transition function to another state in the conversation, it’s actually quite simple.
I’ll be using lua scripts for the dialogs, that way I can easily add conditional responses – For example you wouldn’t want to accuse someone of murder unless you had gathered enough evidence to support the claim.
Also I’ve decided on doing a ‘pilot episode’ which will probably be a 3-4 hour long game to test the engine and actually produce a finished product before the turn of the century. I’ve sketched out some details for a side-story which will take place in the same world as the other episodes, but will involve a different protagonist.
See you next month.
rQuest End of April – Update
Posted by Joshua Smyth (Admin) in rQuest on April 27, 2009
Its not quite the end of the month, but it’s close enough to write my monthly review on the rQuest project.
Work this month was slow as I’m starting to pick up other (non-computer or only semi-computer related) projects / hobbies to do in the evenings.
Programming a video game after spending 8 hours a day programming line of business applications can be a little hard on the brain, eyes and body. Getting exercise and spending time away from the computer to degauss in the evenings can be really satisfying. Realistically I can only commit approx 8 hours per week for rQuest, but thats ok – as it’s a non-zero amount and it’s surprising what you can acomplish in an on-the-ball-ready-and-focused 8 hours.
This month I created the CRUD to add items to the project – For all your wands and shields and swords of much smiting +12 against trolls.
Screenshot Below
This was actually one of the more boring tasks to do as it is stupidly similar to what most database front-end working programmers do day in and day out – Someone has a product and it has these data fields which mean stuff and an end-user needs to enter new products and edit existing products etc…
Basically if I was running a medieval shop (or is that shoppe?) this months work would have been scarily similar to the functional specification of that shop.
I also did a little bit of story development. So the ‘soft’ areas of the game, if still neglected haven’t exactly been forgotten about.
As I have worked on the game editor it has become pretty obvious that I need to get another monitor – Often I need to run two IDEs (Visual Studio for C#, CodeBlocks for C++) with perhaps a paint program, or an Internet browser open. (Three monitors would be cooler, but my budget doesn’t extend that far just yet.) It’s almost an exercise in inefficiency to keep developing on only a single monitor.
So next month it’s dual monitors!
rQuest – End of March Update
Posted by Joshua Smyth (Admin) in rQuest on April 5, 2009
March was a pretty slow month for me.
Most work this month was spent re-organising the level editor, which is slowly transitioning into a complete game editor.
Instead of creating maps, you now create a project – Which contains multiple maps and each project has its own data for monsters, npcs, scripts and tilesets. This is largely a bi-product of deciding to go episodic, but it also centralises much of the workflow involved in creating a game.
This process will take a while as it’s much more complicated to write an application that manages n things when you only originally planned to handle one thing.
So work this month will probably continue to improve on the game editor. But I should really get around to getting the C++ game engine UI stuff implemented sometime.
Also, does anyone know of a (Preferably Cheap) syntax highlighting edit box for .Net? – I want to add the ability to edit LUA scripts into the game editor and would like to have some syntax highlighting.
Response to Two Major Decisions to Make, Part 2 – Maps
Posted by Joshua Smyth (Admin) in rQuest on March 20, 2009
The other question I was pondering with respect to my Indie RPG was how to deal with maps.
I thought that implementing an Ultima7 style continuously scrolling seamless map would be cool as there are not many tile-based RPGs that do that sort of thing. I even sketched out an algorithm that was based on a tree that would grow and store neighbouring maps in memory in order to stitch them together at render time, and I’m pretty confidant it would work quite well.
However, I’m not going to do it.
And the reason for that is because I’ve been thinking about the story line and other aspects of my game and it’s now going to be delivered in a series of episodes!
Having a seamless map kind of makes sense if you are planning a huge world, but as each episode is going to be its own game having the traditional style go to the edge of the map and load a new area makes more sense.
Delivering a series of episodes means smaller development cycles and a tighter focus per game. I think I’d rather play shorter games as I mentioned in Too Many Games to Play
Now that I’m done thinking about things, I can go forth and actually start producing some real work!
Response to Two Major Decisions to Make, Part 1 – The New Resolution
Posted by Joshua Smyth (Admin) in rQuest on March 19, 2009
So a little over a week ago I posted about two fairly important decisions I had to make about my Indie RPG and after pontificating over a couple of hundreds of dozens of cups of tea, I’ve reached my decisions.
Decision One : The Resolution
Will be 1024×768 or 1024×700 in windowed mode – The extra 68 pixels in fullscreen mode will contain a little border graphic, the reason for a difference between windowed and full screen is because if you are playing on a laptop like mine and you only have 800 vertical pixels to play with and approx 80 of those are taken up by the taskbar and the application window, in order to fit the game on the screen, you have to cull some pixels.
This means that the game will look large enough to be played in windowed mode, so people won’t feel the need to go to full screen to get a more immersive experience and my old school pixel art won’t look all blurry when the game is played at non-native resolutions. Of course, if you were really old school you’d have a CRT monitor anyhow.
I may also offer a widescreen mode down the line, but I’m not promising anything at the moment.
1024×768 also allows me to have larger, easier to read text on the screen which is good for older more experienced people
The tilesize is going to remain at 32×32 at least for now. I’m going to make use of some stock art assets found around the internet and in the RPG Maker community for now so I can begin to piece togeather the game without having to fork up heaps for custom art assests straight away.
Two Major Decisions To Make
Posted by Joshua Smyth (Admin) in rQuest, Uncategorized on March 7, 2009
I haven’t got much actual programming on the game done this weekend because I’m faced with two rather major decisions to make before progressing too much further least I change my mind and have to undo a whole lotta work.
The first is whether or not to create the map a seamless world like in Ultima7 – I kinda want the game to be completely playable using only the mouse and to keep the player in the centre of the screen – Using the same mouse controls that are in Caverns of Underkeep
This becomes a little bit strange when the player comes to the edge of maps as I either A) Have to break this rule, or B) Add a lot of padding to the maps so the player doesn’t just see black tiles around the maps edges – This was ok for Caverns of Underkeep as the game takes place inside of a cave, but it looks a bit funny on maps that are supposed to take place in a forest.
So the decision to make is do I enforce padding on maps? Leave a border made up of black tiles? or make the overworld seemless?
Enforcing padding is more work when it comes to design maps, as it is time spent dolling up what are effectively non-play areas.
Seemless overworld is more upfront work for me (as I have to implement a cache tree of some kind to load and unload adjacent maps in order to hide load times.) But would scale alot better – And besides I don’t think there are many other old school style RPGs that do that kind of thing – With the exception Ultima7 already noted.
The second major decision is what kind of resolution to run in, which effects what size each individual tile should be, which effects the time and skill required to make good looking tiles, which increases my budget required to get the game finished.
Originally I planned to run in 800×600 – But I just fired up fullscreen mode on my 19″ LCD and it looked like complete arse due to the game not running at native resolution. I can’t even take a screenshot because this is a physical hardware problem due to the physical nature of LCDs – But you can reproduce the effect if you want, go find some perscription glasses for which you are not perscribed and wear them.
Many game developers will fix this by rendering at some fixed rate, say 800×600 and then scaling up to whatever the native resolution should be. Thats fine for anti-alised games or vector graphics games, but mine is very purposefully supposed to be pixel art and when you’re working with discrete pixels you don’t get nice scaling without distorting your image.
Adding to the complexity, there are widescreens, non-widescreens and crts, all running at various resolutions and each with various native resolutions, I have to come up with a solution that will not look like arse to one particular group and at the same time doesn’t compromise the entire look overall.
I’ll let you know what I decide when I decide.
rQuest – End of Febuary Update
Posted by Joshua Smyth (Admin) in rQuest on March 1, 2009
No screenies this month, and possibly not for a wee while – I’ve mainly been writing code.
This month I worked more on the level editor – You can now place monsters in a map and edit the walkable areas (as well as set tiles to have a default walk/no-walk flag, which pretty much means you don’t have to set no-walk areas at all…)
I also did more work on the C++ game engine side of things. Most of the engine is a port of the Java class structure from Caverns of Underkeep – With some improvements and refactorings and taking into account that this game is going to be more data-driven.
So at the beginning of the month I did what I almost never do and wrote a class diagram on a scrap piece of paper, showing inheritance trees and associations between objects, I’m sure my diagram doesn’t follow the UML spec what-so-ever, but it was helpful enough for me to start fleshing out the header files, and providing some basic implementation for the classes that I was going to be working with.
The feature that took me the longest to implement was remembering how to load data in C++ and convert it into some meaningful structures that the game can use. This turned out to be a pain, Esp. as I use non-null terminated strings of arbitrary length in many places – And I’ve mainly been working with garbage collected languages for the last 3 or 4 years.
So I spent quite a while in the debugger that day.
For example:
- When reading a file do I use .read() or .get() on an input stream. Which method increments the read position pointer automatically and which one doesn’t? (Hint: The first one I used didn’t.)
- If I create an object on the stack and then add it to a collection, what happens when the object goes out of scope? (Does it make a difference if it is a value type? Should I declare it on the heap? Should I store a pointer or a copy?)
- Why aren’t variables initalised to reasonable values, such as NULL for objects and 0 for value types?
- How do I create a dynamic multi-dimensional array that I can resize? (Hint: ObjectName **myArray) – And how am I supposed to clean up the memory when I resize it?
- Why are strings such a pain? How can I easily convert from char * myCharString to String myString? And back again?
So it probably took me about an hour to write the save/load map functions in the C# map editor and about 8 hours to write the equivalent feature in the C++ engine. (Too be fair, if I used C++ instead of C# every day at my day job, I’m sure the converse would be the case.)
That said, the C++ engine can now display maps created in the C# map editor, which is pretty cool.
Next month will probably be working on UI components and maybe getting some basic AI/Combat in place.
rQuest – End of January Update
Posted by Joshua Smyth (Admin) in rQuest on February 2, 2009
So I’ve decided to do these monthly progress report things. Weekly/Fortnightly seems to be too often, but if I do an end-of-the-month report I should at least have something of interest to talk about.
This month I finally got the project in source control – if you don’t currently use an online versioning system for your own projects I highly recommend getting EVERYTHING into source control NOW. I use assembla, but there are lots of online version control hosts out there, some better/cheaper than others.
I got a little distracted this month with recovering from the holidays, attending the 2009 Global Game Jam, playing Persona 3 (55 hours in, haven’t finished yet) – And just general working out what the heck I’m trying to build here.
The goal is now to get a working prototype done by the end of July this year (thats six months!) – I don’t know if it will be a public prototype yet. I might just show it amongst friends and collegues, but the idea is that I have a playable, if not complete game – I might take a leaf from Jay Barnson‘s book and try to make it a ‘pilot episode’ – We’ll see.
Most of this month and the coming month will be spent on the level editor and CRUD – That’s Create Read Update and Delete for all you non-geeks. Basically all the stuff that you want to do when you want to deal with data. I’m using custom flat file formats in order to maintain portablility. Its the type of work that is not very hard but it is very time consuming as I have to sketch out the data format, write save/load functions and drag and drop UI controls onto a form and bind it to the data so that the user can edit and tweak all the values.
And RPGs have lots of data, oodles of it in fact. All those HPs and MPs and Spells and Monsters and Resistances and To Hit scores, and classes and races and lions and tigers and bears, oh my! Can produce some pretty large tables.
Heres a screenshot of the current world editor in progress
Good Software Usability is Hard
Posted by Joshua Smyth (Admin) in rQuest on January 21, 2009
Now that we are full tilt into 2009 I’ve managed to find some spare time to work on the still badly named rQuest project.
I’m developing the map editor, which will over time evolve into the game’s complete authoring kit – With tools for dialog trees, weapon/monster database editing, import/export tools, all that fancy stuff.
I’ve started writing the application in C# with .net 3.5 and the GDI – If anyone has experience with the GDI you will know that it’s dog slow. I coded my own blit routine using unsafe pointers, and its about 10x faster than the .drawImage() routine, but its still pretty slow. Thankfully I’m only making the editor not the game with the GDI.
But its funny just how long a process it takes to get the software to ‘feel’ right. Simply creating software that works is easy by comparison – when I was testing out the map editor, it quickly occured to me that I really needed an undo. Which is a pretty non-trivial feature to add (especially for unlimited undo) Other things that we’ve come to expect in modern software also need to be implemented such as copy and paste. (Both in and out of the application.)
Another change I’m going to add is that instead of thinking in layers, which in some other RPG map editing programs cause me to get confused as to which layer I’m currently trying to edit. Each tile is going to be a stack – Left click adds a tile to the stack and Right click removes the tile from the top of the stack. Where the stack is capped at some height n. This should give appropriate visual feedback to the user as to what part of the map they can edit at any given time.
So work on rQuest continues, but at a slow and steady pace.
rQuest Update #1 – The Basic Tileset
Posted by Joshua Smyth (Admin) in programmer art, rQuest on November 27, 2008
I’ve been spending my evenings trying to get The Basic Tileset up and running.
The aim of making these tiles myself is so I can have enough artwork to start creating basic maps in my not-yet-made map editor. With the idea that at a later stage I’ll hire an artist or two to go over the tiles and pretty them up.
I’ve been using a freeware program called mappy which is pretty decent but there will be some custom features that I require so I’ll have to roll my own.
The basic tile set includes:
- Grass
- Dirt
- Water
- Sand
- Cliffs
- Trees
- Some Houses
I’ve been looking at alot of old school RPGs and I’m firmly convinced that what really makes a game look good is the subtle changes and variations within a tileset – Something I think only a much more talented pixel artist than myself can bring to the project…
After I get these basic tiles layed out I can return to programing the engine, which will actually allow you to play the game, rather than just stare at my static mockup screens. Exciting!
Next week I might just be linking to a beta version of another project I’ve been helping out with.
I’ll probably also talk some programming geek talk.