Backyard Interactive

Results and changelogs

2012-02-02T19:07:00.000+01:00

I've been pretty busy over the past few weeks with a lot of things related to Game Development, but not necessarily CubeWars. We're currently working on getting this set up as a business which is pretty time consuming but also a very cool and promising prospect. Because of this I haven't had the greatest amount of attention for CubeWars.

That doesn't mean that I didn't spend any time on it however!

The past 2 months I've spent a lot of time getting the Interface handling done and today I can finally say that the framework stands! Again! I've done some cleaning to prevent a lot of duplicate code and to make it easier to add new Interface elements in the future, though I'm pretty confident that won't be necessary... or at least that much.

On the functionality side I've finished up the multi-layer gizmo which let's you turn on/off layers for viewing and sets which layer you're currently editting. I've also added in a 'solid color view mode' which draws tiles as colored rectangles representing the layer they're on.

Below you'll find an *extensive* changelog of all the things I've been doing since the last update. It can get pretty technical, so consider this a disclaimer for the uninitiated.

Until next time!

(Most recent commit at the top)

- Added Toggle group functionality, only 1 toggle will be on in each group
- Added animationstep(level*, player*) to the Window Manager
- Moved existing animation code from putscene(level*, player*) and draw(int) to animationstep(level*, palyer*)
- Moved level::animstep() and player::animate() calls from Main.cpp and Editor.cpp to animationstep(level*, player*)
- Renamed level::animstep() to level::animationstep() for consistency
- Added a command line option to the editor to disable all animations ('--noanimation')
- Added "super secret" command line option from CubeWars to the Editor as well
- Added window::putlayer(level*, int) to draw specific layers only
- Added window::putactors(level*) to draw the actors only
- Rewrote window::putscene(level*, player*) to use the new putlayer(level*) and putactors(level*) functions
- Added editorinterface::putscene() function to draw only the visible layers
- Added editorinterface::toggleviewlayer(int) and editorinterface::setdrawlayer(int) functions
- The editor now only renders the visible layers as indicated by viewlayers
- Hooked the Layer Gizmo toggle buttons to the triggers for setting drawlayer and viewlayers
- Added 'solid color' mode to window::putlayer(level*, int, bool)
- Added layercolor variable to editorinterface to determine whether or not to use 'solid color' mode
- The amount of 'clip' entries for blitting is now determined by MAX_CLIP and MAX_MINICLIP
- Changed MAX_MINICLIP from 64 to 256, giving us 8 rows of 'mini' tiles instead of 2
- Added new 'eye icon' graphics to the tileset
- Added new 'eye icon' toggle button on the Layer Gizmo
- The 'eye icon' now toggles layercolor, the drawing of each layer as a solid color

- Replaced 'Layer Gizmo' items with Toggles
- Added icon drawing for Toggles
- Created all the 'Layer Gizmo' button artwork (CTRL+C - CTRL+V)
- In Layer Gizmo set up, changed thisbuttoncount to thisbuttonnum
- Added Toggle group functionality. Each group always has 1 member set to 'on'
- Toggle's initial/zero state is now 'Off'. Drawing logic now abides this

- The rendering of an ui_element's base is now a seperate function
- The rendering of a ui button is now a seperate function
- The rendering of a ui slider is now a seperate function
- The rendering of a ui toggle is now a seperate function
- Changed button's offsetonclick to offsetondown for consistency
- Restored button rendering
- Restored slider rendering
- Added rudimentry toggle drawing
- Reworked the mouse handling code to use ui_elements
- Added basic handling for toggles
- Added back the slider's customised handling
- Adjusted the Editor version number in the roadmap

- Fixed render segfault, was a problem with pointer init for the ui_element array
- Render code currently uses just ui_element information, but it works for all of them
- Changed sliders to have 'drawbase' set to 'false' by default, fixing their apppearance with the new code

- More GUI graphics
- Fixed a bug where Guiclip would wrap around to the next row too soon
- Introduced abstracted communication with interface elements
- Fixed an overflow problem with the new method of interface communication
- Init'ing elements will still be done the old way now, changed code accordingly
- Element init routines now share the code for basic error checking
- Finished set up and init routines for Toggles
- Looked at the rendering code and decided to redo this :/
- Broke the rendering code, it segfaults. Better commit.

Interfacing... more of it!

2011-11-09T16:39:00.001+01:00

The past few weeks have been fraught with distractions, regardless I've been able to get some things done. I've drawn out what the new interface will look and function like and have begun bringing it into the Editor. Some elements are working and in near-final shape (the Main Menu is one) while others are bare bones or not there yet.

A lot of time has gone into adding the 'Slider' interface element. This will allow the user to scroll windows or change values easily. I actually had a bit of difficulty getting the math right for that one. It's all working now so I can get back to putting the Editor together again.

I've set myself the goal to have the Interface done by the end of this year. It may be a bit bold, but I think I can make that.

Until next time!

Interfacing

2011-09-22T20:57:00.003+02:00

After a couple of weeks of dredging through 'ground work' I've finally come out above ground level. I've got the inner workings of my 'Interface' class working properly and it's looking to work pretty well! Right now it handles just panels and buttons. The window manager knows how to draw 'em in all their states (like, if you mouse over a button etc.) And the proper 'hooks' are in place to connect buttons to certain events.

Initially I was going to have the buttons 'perform events' by providing them with a function pointer to the function they need to execute, an idea by a friend of mine. However I found, having implemented most of this already, that function pointers cannot point to parenthesized functions. Quite a problem considering most of my code is designed with a reasonably strict class hierarchy. The interface class, for instance, doesn't 'know' about any of the higher level classes like those part of the Editor.

In stead of this method I decided to do a crude implementation of an 'event' structure. I have an array of booleans which correspond to 'actions'. A button is supplied a pointer to a particular boolean, this defines which action it'll perform when pressed. After the interface has been handled each cycle, the Editor will see if any of these booleans where set to true and then perform the function associated with that boolean. Pretty simple stuff.

The next step will be to design the UI using my existing (and probably some new) Interface elements and hook it up to functionality. Most of this will rely on the foundation I've been building the past few months.

Also, good news for me and anyone keeping track of this, I recently took an internship in a nearby town and thus will have a regular commute over there and back. This provides ample opportunity to do more coding. Couple this with the fact that I'm back into 'not boring foundation work' zone and it should make for some productive times!

Until next time!

Still Alive...

2011-09-06T12:58:00.001+02:00

This is just an update to let everyone know I'm still alive and work on CubeWars is still ongoing.

Most of the work is currently going into the Editor at the moment. I'm working on a redesign of the Interface class and the way it's going to work in both the Editor and the Game itself. There's not a lot to talk about since it's very basic stuff, which is also why it's taking me so long. Doing it right is going to make my life easier down the road though.

I don't have a real estimate on when I'll have this done but judging by how long it's been taking me it could be a few weeks, though work has been picking up pace in the past week!

I'll try to post updates here whenever something mentionable happens, it's just difficult in this stage because most updates of the past week would've been stuff like "this class now inits properly" or "I made a change and had to fix the destructor, it works fine now though" which isn't particularly interesting to read for anyone not working on the thing.

Anyway, I'll hopefully post another update soon!

Dynamics & Triggers

2011-06-20T18:44:00.001+02:00

Finally! After weeks of infrastructure I finally got Dynamic_Actors working!

Thanks to the help of the people in #C++ on freenode I was able to solve some lingering issues with my set up. Turns out that defining functions in a class derived from another class doesn't necessarily override existing functions from it's parent class. Thanks to virtuals I managed to solve that.

After the basics worked everything else was a breeze. In no time I had the Door functionality working exactly as I wanted and Dynamic_Actors are, at long last, a fundamental component of CubeWars levels! It's weird how fast coding goes once you have your fundamentals up.

In addition to that whole ordeal I've put in place a system that allows you to chain switches and use them as a rudimentry sort of logic gates. So you can have a switch somewhere that only works if another is in a specific state. This also makes the amount of stuff you can trigger with a single button virtually unlimited.

I'll be playing around with that a bit more in the future, try to get as much functionality out of that as possible, but for now I'm focussing on redesigning the Editor. It's long overdue and with my final type working (and the time it's taking to build levels partially with notepad) it seems like the best thing to do at this point.

A special thanks goes out to my new whiteboard with whom all of this would've taken considerably longer.

See you next irregular interval!

Bucket of update

2011-05-17T12:19:00.004+02:00

So it's been a few weeks since I last updated the blog.

I've been most busy working on CubeWars in this past period. So far I've laid most of the ground work for the Dynamic_actors and I should probably get a functional one in the game this week or next. There was just a lot more general design that went into it... more then I anticipated. But I'm happy where I am now with all that. Pretty soon adding new actors, of any type, should be simple and clean and I can focus on getting the game the way I want it.

In this period I've also been reworking some other things that correlate to Dynamic_actors. For one, I've routed *ALL* Actor <=> Player interactions through the Level class. The reason for this is that this makes trigger handling a lot more manageable. I can, in theory, very easily do trigger chaining or have objects of one type trigger objects of another, without much hassle. Also, it sets the precedent for the Dynamic_actor class, which are pretty much required to be handled this way, because of the way I designed them.

It feels pretty good to have these consistent themes throughout the code though.

Other things of note that I've been working on:

Enums, they're beautiful bastards which I'm beginning to use more and more in stead of more cryptic code. So where I had a "static_actor.type = 3" you'll now find "static_actor.type = SWITCH".

I've also spent some time on redesigning the Obstacle static_actor... y'know, the one that used to be my Door. The idea is that it'll be used to make parts of the level dynamic in the sense that you can move whole sections from A to B with the flick of a switch. Or make them invisible... or even to just fill up another section with a bunch of tiles. Combining this with the fact that Switches can now trigger multiple targets... and I have plans for multi-triggers, to allow you to trigger large amounts of objects at once, it should make levels very... interesting.

There's also a few minor optimizations done, some clean up here and there... and me postponing the Interface/Editor redesign for another day. Let's get this working before I delve into that.

I hope to have some more concrete news for next week.

Until then!

Design work

2011-04-19T20:22:00.003+02:00

These past 2 weeks I mostly spent on design work. That is also part of the reason that I missed last week's update, nothing much happened.

In any event, I've worked out how to, practically, work out this infrastructure. I'll end up having a single pointer array of type 'dynamic_actor' which the game will walk through every cycle. Each entry will refer to an entry in object arrays of all the derived classes, which are the actual dynamic_actors (such as Door or TurretBullet). They will inherit some basic function calls, such as query() or playercollides(), which can be called from the main loop. In addition to those they will have functions depending on how each of them functions. So a Turret gun will have a shoot() function and Door will have open() and close() functions etc.

It took a little while, but I've got some basic designs laid out on how to do all that internally (and do it well, mind you) so I'm beginning implementation in the coming week.

Some time was also spent on the next iteration of Project: SPACE. I've mostly been laying out how I want to do all the objects and how the application will be laid out entirely, and once I feel good about the general outline of the whole thing I'll start writing code. I intend to take 'Design then Build' pretty seriously for this one because I feel that it helps get everything right from the get-go, which saves me a lot of work later.

Also, my priority is still CubeWars, so it's no big deal if I get distracted because of how slow that's going.

Finally, there's now a twitter feed on the blog. Not all of my tweets are on the topic of Backyard Interactive, but it's not like I tweet that often :)

See you next week!

All my designs

2011-04-05T22:20:00.004+02:00

The past week I've mostly spent on theoretics.

In particular, the implementation of the Dynamic_Actor class. Currently the level is created with a few pointer arrays for all the elements in it. There's an array for tiles, one for Goody type objects and one for Static_Actor objects. For Dynamic_Actors I initially thought to just add another array of that type, and have that class contain all variables and functions required for all types.

Then I thought about the things I actually wanted Dynamic_Actors to do, and all of a sudden that plan seemed overly convoluted.

You see, then I'll end up with, for instance, a 'query' function that has all these different cases for all the different types of Dynamic_Actors. The code will become hard to read (and thus manage) and I'll need this base class with a ridiculous amount of variables to accommodate the (often complex) behaviour of all the different types of Dynamic_Actors.

Instead, I've been thinking on giving the Dynamic_Actors class a very limited amount of variables and functions and create child classes of different types to accommodate each different type of Dynamic_Actor. So I'll have an "Enemy" subclass that has variables such as hitpoints, response time or whatever and another subclass called "Door" which won't have any of those, but instead will have things like waiting time or key colour required. As most of this different behaviour is handled by the class functions themselves, you technically don't *need* to know which subtype it is for it to be handled properly!

So I've been planning out how I want to do that, and looking at all the caveats for that. I've written very little code, though I have begun some optimizations because of this process. It's interesting the things you find out as you plan other, similar things.

Also, I've been watching the Alien films today and was shocked, SHOCKED to find how many games take cue from the first 2 ones. Stylistically I mean. Just look at the gunship in Aliens and tell me that doesn't look like a Halo dropship... or Command & Conquers Orca gunship... or sounds like StarCraft 2's banshee... etc. etc.

See you next week!

Err

2011-03-30T01:17:00.003+02:00

It's Tuesday (technically Wednesday) and I don't really have anything to say. I worked on the tilesets some more and I made plans to switch between the current 32x32 snap grid and a 16x16 one. This to accomodate some new tiles I've been making.

Until next week then.

Content and Design

2011-03-22T20:10:00.004+01:00

The past week has seen an increase in productivity.

I've decided to work on some more practical things since past Tuesday. I've finally finished the switch and door mechanics. You can now trigger a door by flipping a switch anywhere in the level. I've also made an addition to the Editor that also highlights the targeted object if you select a switch that has a target.

I also found that making the door a 'Static Actor' type wasn't a great decision, because of how I've decided to handle Static Actors. SA's are only handled when the player collides with them, or if another object directly triggers them. Because of this, they cannot transition from one state to another smoothly, unless I make a substate out of every single step, which is stupid. So I've decided to make doors into 'Dynamic Actors' (which get queried every game 'step') and keep the existing functionality, but call it an "Obstacle". Before next week I'll also allow the user to define the appearance of this Obstacle to any world tile so that it's in line with this.

A few times I considered making fundamental changes to the Editor (it needs it) but I haven't began working on that, code wise, for now. I've chosen to approach this differently. First I want to design how the program will look. I'll make sketches of every state of the program, and all of it's submenus. This way I'll have a definitive final design for the Editor itself. Then I'll start designing how I want the program flow to go, maybe write specific behavior in the form of pseudo code. After all that, design in hand, I'll start rewriting the Editor from the ground up.

I've figured that going in too hastily will cripple my ability to have the Editor 'keep up' with the rest of the game until it's been completely rewritten. This will probably take it's toll, motivationally, on my progress with the rest of the game as I will have to go back to using a Text editor to add new features to a level for proper testing. I don't want to run the risk of this taking even longer, so I figured that designing the entire thing before building it would be smart in this particular case.

I gotta watch myself to not go overboard with how 'neat' it'll be, or I risk casting this job into the depths of oblivion, like I've done with earlier projects.

As a final note, I redid the logo and title screen for CubeWars, of which I'll upload a screenshot later. It now draws a random level that passes slowly in the background. It's really nifty.

Edit: Here it is!

See you next week!

The "Meh" Principle

2011-03-16T01:06:00.002+01:00

So the past 2 weeks haven't been very productive code-wise. I've written very little actual code and most of the things I did were bug fixes to behaviour that was already in place. The 2 things that are currently on my todo list are "Implementing Doors w/ switches" and "Rewrite graphical interface". The former is a lot more practical so we're going to skip it for today's exercise and move on to felon #2.

Currently I don't feel much for the task of (partially) rewriting my graphical interface implementation. It takes a lot of time, it doesn't yield very tangible results (not that anyone but me will see) and it's also a bit more taxing cerebrally. Where most of the things I work on for CubeWars are things that simply need to be written (because the implementation is straightforward) it seems that topics that require a lot of forethought and planning are less interesting some how. I mean, don't get me wrong, I love problem solving. I love it when a good design allows for some great code and I love to go through that process, but because it's results are not highly visible, it's not as exciting to work on.

This is, of course, not anything really new. I knew that this would be the hardest part, which is why this project's process is aimed at short-term results with the aim to keep my motivation up. So I'll be thinking about how to circumvent this so it becomes more manageable. I'll keep coming back to my codebase, even for silly things, to keep it on the brain, and hopefully I'll come up with a brilliant solution for this problem in due time.

Also, as a sidenote, I'll be updating on Tuesdays from now on, because I have a thing on Monday.

That's right, I have a thing.

Things are cool.

See you next week!

The Milestone

2011-02-28T18:27:00.003+01:00

Last week I accomplished quite a feat. I made it to my personally defined 0.4 milestone!

Now this was quite something for me. It took a lot of effort to accomplish all the things I had planned for this milestone. For one, the Editor is now usable in a reasonable fashion. Sure it crashes when you click on uninitialised toolbox buttons, but that's a minor detail. The GUI looks nice, I've got sprite-based buttons as well as rectangular buttons with text. I got the features in the game engine that I wanted and I even scraped some last minute animations in there.

For next week I plan to pick things up again. I took a little break after reaching 0.4 and gave it to a few friends of mine who picked and commented on it a little. One such comment influenced how a jumping character handles. These sorts of comments I tend to value as that's one of the first things that you get blind sided on from playing with the build for so long. You tend to notice subtle things less like how character movement 'feels'. Mostly the comments have been on par with what I've been going for so I guess I'm on the right track.

Next week I'll start implementing doors and switches, right after I fix how "Hurt" objects are handled, which currently don't respond very well if you're bumping into them from the sides. I think doors and switches will be one of the first changes to a more complex and entertaining object palette with which to build engaging levels. I've got big plans for the future... well... y'know. Big within reason.

See you next week!

Oh, and for those who care, here's the monstrosity that is 0.4's changelog.

Main v 0.4 (unreleased)
- Added smooth scrolling of the screen.
- Gave Player character arms and a gun.
- Player animation subsystem implemented.
- Currently the legs animate and can be controlled individually.
- Reimplemented level structure, it's now it's own class.
- Sepperated the player into it's own source file, it was getting too undwieldy.
- Player no longer dependant on the tile class, collision triggers from main loop.
- Added Goodies to the game. These are pickups that help the player.
- Goodies are now rendered, interactive and loaded from the level file.
- Implemented a basic GUI to display player health/lives/score
- Added a static backdrop to make the level appear less plain.
- Made goodie collision more accurate.
- Added hazards that can hurt and kill the player.
- Started the CubeWars Editor. An application to more easily build levels.
- Added function to save level & player states to file.
- screen.draw() function now takes argument which defines the framerate cap.
- Complete restructuring of source files. Sepperated GUI functions and window manager.
- Also, as part of the restructure, Editor and CubeWars now share dependencies again.
- Finished "graphicalinterface" reimplementation. Made functions accessible to Main.
- Fixed a bug in the scrolling routine that got it stuck near the edge of the level.
- Goodies and static objects can now animate at 3 basic speeds.
- Moved the animation handling to WindowManager. No use having thousands of copies of that during runtime.
- The Coin and Life powerup now have animations.
- Losing all your lives now causes 'game over'. Currently this just brings you to the Title screen.
- Reduced friction while Player is airborne. This causes more realistic jumping behaviour. (Thanks Martijn!)

- EDITOR: Version 0.1
- EDITOR: The Editor shares all classes and functions with game core.
- EDITOR: Added class to track mouse actions and positions.
- EDITOR: Added classes for buttons and buttonpanels to act as GUI elements.
- EDITOR: Using the mouse, tiles can now be picked from panels and placed in the level.
- EDITOR: Also wrote sweet-ass 'snap-to' logic.
- EDITOR: Redid the GUI layout and wrote button sorting functions.
- EDITOR: Created art for the new GUI layout.
- EDITOR: Moved a large number of variables and functions to a 'graphicalinterface' class.
- EDITOR: Rewrote most, if not all, of these functions.
- EDITOR: You can now scroll freely around your level at 2 different speeds.
- EDITOR: Added redundancy check, eliminating multiple tiles at the same coordinates/drawlevel.
- EDITOR: You can now place Player Start, all current goodies and the Hurt static actor.

Re-arrangements

2011-02-22T19:42:00.004+01:00

So this week I did a lot of reorganization code-wise.

I moved a whole bunch of code around between files, trying to find a good configuration with as little dependency overlap as possible while giving each class or function access to the other classes and functions that they would need access to. It was a bit of a shuffle but I'm happy with how things are now. I'll most definitely do this a few more times over the lifespan of the project, but that's what you get when your aim is mostly short-term progress. The upside to this approach is that I'm fixing problems as they arise, rather then trying to set up a structure to prevent every problem I might possibly encounter. The later is the reason another project is currently in limbo. This whole experience should give me some great insight in how to structure a project, which will be invaluable the next time I start, or continue, a project.

To not bother you too much with specifics on this, let me just leave you with the schematic I drew which helped me organize my code in an adequate fashion.

On to things I did that have a more practical result in the program. I redesigned the Editor layout (see screenshot below) so that you can easily pick a tool from the toolbox and then a brush and get to building. This whole ordeal brought on the creation of a system that handles drawing and manipulation of on screen buttons and panels, as well as mouse handling. You can see these in the above schematic as 'Graphical Interface' and 'Mouse' respectively.

The Cubewars editor currently only works to place world tiles, so you can make a maze to maneuver through or make jump puzzles or whatever. I'm currently getting the static_actor and goody classes to work as well, but that was a little less straightforward so I'm still on that. It should be implemented by next week. I've also figured out how backgrounds will be handled. In your level you can simply define which background # to use, and the game loads the bg#.bmp file that corresponds with that number. It's really simple stuff.

I also fixed a truckload of bugs and worked out a ton of kinks everywhere, but that's so specific it ceases to be relevant reading for anyone but myself. Rest assured though, awesome things happened behind the scenes.

Though, on a last note, I do hope that I can do some more visible things in the coming week. It just feels more rewarding to say to yourself that you got X in the game.

See you then!

Death and creation

2011-02-14T23:23:00.004+01:00

So this week was rather busy. I seem to be doing that off and on. We're working on a grand awesome project, me and some friends, and I'll announce that when we have something to announce. For now there's just 1 word you need to remember: Thorworks. That's right.

Regardless of these things I still managed to do quite a bit of work on CubeWars. I continued implementing objects, now adding a static actor class. This class will encompass all objects in the level (save goodies) that do not get their logic processed without direct player influence. This would include things like buttons, doors, hazards and the like. Anything that doesn't do squat unless you interact with it or just bump into it. I already made the Hazards work and also implemented dying. I already have plans to have the player explode into gibs when they die, but that's cosmetic and will come at a later time.

Aside from some tweaks to collision for non-tile objects, the major change I made this week was to something I had figured I would add at a later time. I'm talking about the level editor for CubeWars. Originally I had planned this for the Beta release, or whenever I would be needing it more to start making levels, but modifying my levels through a text editor became too unwieldy and I figured I might as well do it now. Rather cleverly, I made the new Editor core depend on the game source files so I wouldn't have to redo those and if I make any changes/additions to them, I don't have to go to great lengths to make it work in the editor.

There are a few things which are needed for the Editor which are mostly done now. First is mouse control. CubeWars will play completely with a keyboard (or controller) and doesn't use a mouse, but the Editor kind of depends on this so I started a class that would hold the mouse position, if it was clicking, what 'brush' the user has selected and so on. After that I added a 'button' class for the GUI and a panel that would hold multiple buttons. Using these simple elements I can easily craft a simple interface that would make building levels a cinch.

I tell ya though, the biggest challenge was figuring out how my makefile would build 2 projects with slightly deviating dependencies. That ended up being real simple though, just like when I ran into some trouble with dynamic arrays causing segfaults. I love programming, don't you?

See you next week!

It's beginning to look it

2011-02-07T20:57:00.005+01:00

This past week I've done a ton of work on Cubewars. First off I started doing some reorganizations with the code. I created a class for the level (rather than having all the variables for it lying around) and updated all the code relating to that to take advantage of this. I also moved the Player class to it's own source file as it was getting a bit big. For this to work I had to remove it's dependency on the tile class (which it interacts with for collision checking) and made the whole thing a lot more clean as a result.

Yesterweek I also mentioned that I was working on an animation subsystem. This is now finished (for the legs at least) and I even went so far as to have the legs animate independently. This is really great as I just need to draw frames of 1 leg walking and I can just duplicate and offset where it is in the animation for the other leg. Presto! You now have a walking animation. I already drew some frames but am not too happy about them yet, so I will end up redoing those before release.

I finished the 'goody' class, which will represent objects that are beneficial to the player. Such things include health, lives and items that increase your score (yes, I'm going down that path). I had a bit of a scuffle with this but it works perfectly now barring a minor issue that I discovered while working on the HUD. Oh didn't I mention that already? We have a proper HUD now. On it are the things I just mentioned that can be affected right now. I spent some time frogging with it before I found the right orientation for all the individual components, but I'm pretty pleased with where it is now.

Also, just 5 minutes before I started writing this post, I threw in a backdrop, it makes the whole thing seem a lot less plain then the stark black that the level is drawn on. I'm not sure if this will end up in release, but I'm definitely looking into the possibilities I have with such a system.

Here's a screenshot of how the game looks now.

Whew, that's a lot of stuff for one week. Things are really going well. Every time I'm doing other things (such as StarCraft 2, gotta get Master League) I'm already looking forward to working on this bad boy again, so that's nice for a change. Let's see how the next week pans out.

See you then!

Small fry

2011-02-01T01:25:00.003+01:00

This update will be brief, I've been busy this week.

I spent most of the time implementing and, consequently, fixing smooth camera scrolling. It now works in a way that I like, so that's covered. In doing this I also found and fixed some bugs related to tiles and the player character's position relative to the screen's offset. I also started to implement items when I realised I only had 1 static look for the player character. Being a bit OCD about stuff like that, I started figuring out how many more frames I need to 'reserve' to cover all the player's animation before I can start dedicating space on my tile sheets for non-player objects. For this reason the player character currently has arms. An animation system will follow shortly.

I also started work on redoing my level implementation. As it is now the level is just a number of pointer arrays for the tileset. Another array was going to be added for goodies when I realised this would create a whole cluster of level specific variables and those would probably have a better home in their own class. So I'm writing that and reworking the rest of the program to use this new level class.

Progress is good. I'm feeling comfortable with how things are moving along.

The physics of it all

2011-01-24T17:37:00.004+01:00

Last week I spent more time than I really wanted on fixing collisions. I spent the majority of my time redoing the physics bit from basically scratch. Turns out that my previously "infallible" implementation wasn't quite so infallible as I thought, what with moving through walls and jumping to the other end of the screen, but I think I've got it down now.

What I did was detach rendering from the progression of the game world. Now the game world takes 4 "steps" before rendering anything. This made me reduce every physics related variable to about a fourth but everything is now much more accurate and it feels a lot more slick. I'm quite pleased. I also managed to implement this really sweet tool that's going to make debugging later a breese. This debug mode allows me to pause the game and step through each physics "frame" to look for any inconsistencies. It also displays what the physics engine did at that frame so I know where to look if something goes wrong.

Now that I've laid the groundwork I can continue with adding cool stuff to my little "engine" to make it more complete and more like an actual game. Though I'll probably spend time moving stuff around so that I get a bit cleaner code. Below you'll find the revised changelog for the current game version (0.3). I'll also have you know that I have a roadmap up to V 0.5 so I'll have plenty to do for the coming weeks.

Until next time!

v 0.3 (unreleased)
- Tweaks to improve the player's appearance.
- Box collisions work now. You can collide with everything.
- Tile's now have 4 solid states: None, Platform, (Vertical) HalfBlock and Solid.
- Sepperated rendering cycles from physics cycles.
- Physics redone entirely. It is now virtually infallibe.
- Sepperated debug related functions from regular ones, thus introducing debug mode.
- Added the ability to step through all past (up to 4096) physics frames.
- Another tile drawn, it kind of looks like a treetrunk.
- Added a rudimentry Menu with placeholder graphics and intro animation.
- Began punctuating changelog changes.

Progression through simplification

2011-01-17T18:38:00.008+01:00

Since my last post I've been working on CubeWars whenever I had the time to spare. It's a really fun little project that's shaping up to be quite a cool game whenever a release will be made. I have found that working on something that's easy to progress is a lot more fun then shaping unwieldy projects with a lot of aspects that one would need to be concerned about.

I think, so far, that this project is going really well. We'll see within what time frame I manage a release and use that, along with the quality of said release, as a benchmark for the effectivity of using the simplification of a project as a tool to reach milestones. I'll even do a retrospective look once the game is all done and I can't think of anything to add or take away from it any more. Perhaps we can learn a thing or 2 about motivations and work flow management.

As long as I keep at this, I'll do a weekly update on things, which should probably be monday evening, so right around now. Feel free to check back then. Now here's the changelog I kept since the last post, and another screenshot.

See you next week!

CubeWars
by: Nino v.d. Mark

v 0.3 (unreleased)
- Tweaks to improve the player's appearance
- Box collisions work now. You can collide with everything.
- Lots of fixes to the box collisions to make it infallible.
- Tile's now have 4 solid states: None, Platform, (Vertical) HalfBlock and Solid
- Another tile drawn, it kind of looks like a treetrunk.

V 0.2 (unreleased)
- Improved physics accuracy on platforms
- Releasing the jump button early now properly reduces maximum jump height
- General physics behaviour tweaks
- Object facing added, loaded from secondary fobjects.bmp file
- Levels are now loaded from RCF files
- Level tile array size now depends on need as indicated by level file
- Fixed collision state properly reporting on Debug HUD

V 0.1 (undated)
- Basic player, simple physics and interaction with level tiles

The familiar circus

2011-01-13T21:16:00.003+01:00

It's been over half a year since I last posted something on this blog. I tentatively mentioned an unannounced project but that's been buried under design issues for the time being. All this time I've been thinking about what I wanted to do with Backyard Interactive, but more importantly, what I wanted to do with programming. I think we've established that I'm not too good with some aspects of doing a project. Scope is a great way to screw yourself over by going to big too fast. Consistency is not one of my qualities when it comes to working on any of my pet projects and I lose interest quickly if things aren't going my way. Getting bogged down with stuff that doesn't work the way you want to is just a real hit in the gonads of motivation.

So I've been trying something new with that mindset. I thought it could be good practise to take on a project that's relatively easy to make, is something that I wanted to do at some point anyway and to do this project with the focus on getting shit done.

So I present to you, a first look at this new project, called CubeWars.

CubeWars is a simple 2D Platformer game featuring deliberately simple drawn characters. The gameplay will combine basic platformer action with some shooting and puzzling mixed in. Nothing ground breaking, nothing particularly noteworthy except that I intend to do the premise well.

I already have basic movement and gravity, and in not too long I'll have actual box collisions (currently only standing on objects works) and I can start on things like simple frame animations, maybe a level editor, some baddies and other such things. The design of the code is simply, or even ugly, to allow me to easily add on and see results of that work almost immediately.

We'll see what obstacles I'll run into with this project that's almost destined to be finished, in one shape or another, in the not-too-distant future.

Stuff

2010-04-18T02:29:00.002+02:00

Just thought I'd post to let everyone (optimistic, I know) know that I'm doing something new. I don't want to get anyone's hopes up, including mine, but I'll reveal more as it gets closer to a release. It's my attempt at something simple that *works* so we'll see how that ends up.

SDLRogue 2.0 source liberated

2009-11-02T17:13:00.003+01:00

The source to, what was intended as the improved version of SDLRogue, has been released. I got in touch with Thomas and he said he would have no problems with it being freely available. It may not be as functional as the original code, but it's a heck of a lot cleaner.

Check it out at SDL's Sourceforge page.

SDLRogue source code liberated

2009-11-01T17:10:00.002+01:00

I've been considering this for a while and decided to go through with it. As of today, the SDLRogue source code is made public, under the BSD License. Feel free to grab a copy at the sourceforge project page here.

I figured that this wasn't going to go anywhere in my hands, and I hope someone else will pick it up, or learn some lessons from it. It's been a great learning tool for me over the past year or 2, working on it and developing not only the program, but also my own abilities.

So have a look see. I made available a forum to discuss it, and other Backyard Interactive topics, here.

It's been quite a journey, but it had to come to an end. Too bad it had to be this soon.

The engine that could... be worked on.

2009-08-25T15:25:00.008+02:00

Lots of things happened in the last week. I got a ton of code done, managed to track down a memory leak that's probably related to the crash described in this old post. It might still be an SDL bug, but we won't know unless we've dug deeper on this issue.

Below is a small list of the things I did on SDL-Rogue in the past week. Most of it is code. It may give you a slight insight on what we're doing at the moment.

* Code Bugfix: Combat system now properly progresses to the next phase
* Code Rewrite: Added Quibox call, referenced all current QuickUI drawing there
* Code Addition: New variable for Quibox call. Now allows you to set custom width.
* Code Addition: Created the 'Action' Combat UI, taking advantage of this new var.
* Code Addition: Combat UI now parses input and moves the selector around.
* Code Bugfix: Pressing the 'X' while in the Combat UI now quits the game properly.
* Code Documentation: Documented combqui() modes and return codes
* Code Rewrite: Restructuring of the battle cycle
* Code Addition: New default Player name. For now it's "MANDUDE GUY"
* Code Addition: Basic combat menus added
* Code Rewrite: Engine optimalization. Reduced memory footprint by 1/3rd

* Art Addition: Replaced the 'this is not a combat zone' graphic with a better one.

We'll bring you more, in due time!

Back to business

2009-08-18T12:24:00.001+02:00

Vacation time is over. I sure had a blast, and now it's time to get back to work.

A few things have happened since the last update. For one, we put the engine rewrite on hold for now. Thomas was in charge of that but real-life was getting in the way and the project was getting close to a standstill. Because of all that we decided to continue building on the original engine so we would be progressing at very least.

The engine rewrite is still on our to-do list but finishing the first 'release' is of a higher priority right now.

Since that all happened I am now back on the code team, so to speak. The codebase we're working on now was what I originally wrote so I'm already familiar with the way it works and can easily extend on it. This should all be a pretty good impulse of productivity for SDL-Rogue.

We'll be working diligently and report on whatever happens in due time.

Vacational

2009-06-29T02:18:00.004+02:00

So Thomas went on vacation for a few weeks so code will be on hold until he returns. I've done a bit of storyverse building for the (eventual) campaign that will be included with SDL-Rogue. It's coming along nicely and should provide fertile grounds for all kinds of wacky antics.

You might have noticed that updates aren't weekly anymore and that's because, now that I don't work directly with the code (which is more or less the main focus atm) I just don't have that much to report on.

Anyway, until next time!

Yup, we're still alive!

2009-06-09T14:22:00.001+02:00

Just letting everyone know we're still alive. Work is progressing and all that jazz.

Ever onwards

2009-05-26T00:09:00.001+02:00

A small update for this week.

Work continues steadily. The data structures are pretty much all in place and the file loading works with the new code base! Also a small change was made regarding how objects are handled. The way a level-based object works and how it looks are now separate. You can have your doors/buttons look like any other tile now... this will probably allow for some more creative level design upon it's first release.

More to be revealed next week!

Seeing is knowing that it rocks

2009-05-19T01:19:00.000+02:00

Well I have a proper update for today! Huzzah. Thomas sent over the current state of the code base this weekend and I had some time to look over it since then. It's a real nice job! A lot better and more structured then my own, nooblet code. There's no real estimate on when it'll be ready but rest assured that it's going well and what we have is looking good.

In addition to the code I've been working on realizing some design documents. Being out of the loop on how the code comes together left me a little 'dazed' in the project but I managed to pick that up and started putting the ideas and concepts for the game that are inside my cranium into a more tangible form so I'm no longer the only one who knows how it's going to end up.

This is an ongoing process but it's going well and each step of the way I feel more confident that this'll be a fun game that can stand on it's own in the big bad indy scene.

Until next week!

Oh Boy...

2009-05-11T15:00:00.000+02:00

I've been neglecting the devlog a little lately, this mostly because I'm not in charge of code at the moment.

I'll try to find something to update on next time. This just to let everyone know it's still coming along.

Working...

2009-04-21T01:31:00.000+02:00

Just dropped by to let everyone know we're still working diligently. I'm also working on a little sideproject in the spare time of my spare time but I'll report on that when there's something to report. Don't expect much there, that way we get to surprise you!

That's all for now!

Surprise!

2009-04-13T15:24:00.000+02:00

As I mentioned a little while back, this past week marks the 1 year anniversary of Backyard Interactive!

And as a surprise to all of you, I have done...

...

... Nothing at all!

That's right, it's only a year and it's not like there's any kind of a release already, so I suppose our gift is that we're making headway. I didn't get any congratulatary e-mails either so I suppose it serves you right!

On a more serious note;

The rewrite is going on, nothing new to report there. I've got the editor figured out. I decided to think of how the entire thing works before I work on it, I may just get stuff done faster and end up with a more efficient program. So I'll start on the code of that soon!

See you folks next week!

Progress on schedule

2009-04-06T21:20:00.000+02:00

Work is slowly progressing. There's still a lot to do in rewriting the current codebase and Thomas (the coder I mentioned in my previous post) is steadily working on the overhaul. There's still a lot to do so don't expect any miracles soon.

Also, I've started the design process on the level editor this week. Right now I'm trying to find an interface that's going to provide a good work flow with the way files are handled. The result should be a very manageable editor and very small level files.

In addition to all that, we've also decided on a timetable for the project up until the first release (which will be 0.10). I'll keep the exact times under wraps in case they change, which they might, but if all goes well you should be seeing something more tangible somewhere this summer.

In the mean time, we'll keep hammering away at this puppy. See you next week!

Reinforcements have arrived!

2009-03-31T02:42:00.000+02:00

I was really getting fed up with some of the code and how I was struggling to get simple stuff implemented. I had been thinking about getting someone else for the project for the past 2 weeks already, just so the project would go on, and I'd be able to spend the time I reserve (cough cough) for the project on more productive, and more interesting things.

So I was talking to a friend of mine who also does a bit of game development himself, and he told me how he struggled to get his project somewhere as well. In a moment of unadulterated bawl I ask him to come to the code for my project instead, and to my surprise he agreed!

And now there are 2! I've sent him over the current codebase and he said he'd start out restructuring the current code to be more... I think I'd say "proper". Put stuff in classes, get rid of global variables, that sort of things.

In the mean time, I'll start work on a preliminary level editor and get some actual content going so there'll be a world to walk in, stuff to find and baddies to fight, maybe even update the tileset again and get all those unspoken ideas out on paper so they can eventually find their way into the game!

I'm really excited about things right now!

Also, since I'm no longer the prime coder for this project (though I'll keep my eye on it ofcourse. It's hard to let go of your 'baby'...) the updates on the site may be less specific than they where and more geared towards design rather than coding.

Maybe I'll ask him to write up a bit on what he's done the past week. Who knows!

Anyway, see you next week!

Crawl

2009-03-23T21:54:00.000+01:00

Not a lot was done this week. There's still the possible API bug, and that's probably what's the leading cause of me not getting to it. I did do some graphical things for the combat system, so it's not a complete standstill at least.

More on this next week.

API Casts Bug of the Unknown

2009-03-16T20:47:00.000+01:00

I did some more work on the combat routine. I'm about to start heaving parts over from the QuickUI to the Combat menu, which will appear and work in a similar fashion.

There is a small problem I ran into that might be related to SDL (or something along those lines) because I ran into an unexpected crash when the game screen loses focus. I've been spending some time already trying to figure out where the problem lies and how to fix it, along with some of the folks from the SDL IRC channel. Once this is fixed I'll continue working on the combat routine.

Short and sweet! See you next week!

Productivity and half-promises

2009-03-09T20:17:00.000+01:00

So this week has been very productive!

Lots more work done on the combat, I moved a bunch of structure related things from the idea pile to actual functional code. A lot of time was spent on making boring code it seems... or rather... purely functional code.

Most of the systemworks are now worked out completely and I'm currently spending most of my time just making them. Some more concrete formulas joined the mix and I spent a while updating the documentation today as a direct result of finding that the reading of AI moves was already in the code but not in the documentation, and since I use my own docs for reference that had to be done.

I am also glad to report that I have the first actual moving images from the combat sequence! I worked out how to make it so the combat's drawing calls wouldn't cause odd jerky movement and you can now watch both player's endurance points increase (all smooth) when you enter combat.

During a break I took I was looking through some of my old posts here and I noticed that, this April, Backyard Interactive (in it's current form) will celebrate it's first anniversary! My immediate thought was "I wonder if I can have combat done by then..." and I'm not entirely sure... considering my track record... but there's a slight chance that I might.

Maybe I'll do something fun, for the heck of it, and maybe I'll be to busy doing the actual work, but you'll just have to wait for that.

In the mean time, I'll just keep at it. See you next week!

Structure and Design

2009-03-02T18:30:00.000+01:00

Things are speeding up a little again.

A lot of design this past week. Getting more of the formula's nailed down as well as structuring. LOTS of Structuring. I've got the basics for the combat cycle done (partly on paper)... I've been thinking a lot about certain combat mechanics and how I'm going to have them interact... as well as how I'm going to implement all of this without redoing the framework I've been building over the course of this project.

Some of this stuff is really interesting, and some of it is tedious and minute.

I've also found out that Design is a lot more work than I initially expected. I've always been more of a designer than a programmer (but it's pretty hard to do one without the other... if you're working solo...) and I always took it as more of the "let's figure this stuff out, and make up some cool things" work. There's a lot of getting those cool ideas down to a level where you can work with them. It's interesting and I've learned a lot about that... and about working with myself, in the process!

I've also been toying with the idea of a forum. I probably won't make it 'Live' until after I've made some sort of a release though. Not much to talk about otherwise.

Anyway, more next week!

Back: Game Development

2009-02-23T20:06:00.000+01:00

Well that was an active little week.

So active that by the end I was literally sick and had to sleep around the clock to feel semi-human again. Working with those 2 guys was really fun and we got a bunch of stuff done but I can't really talk about it too much yet. Stuff may happen, and stuff may not happen, if anything does happen expect some linkage here.

Not a lot done on SDL-Rogue this past week. I did look at the combat mechanics some more, realizing a lot was still up-in-the-air design wise I decided to nail some stuff down. It wasn't much, but it was something.

Let's see how the next week goes!

Away: Game Development

2009-02-17T17:16:00.000+01:00

I'm currently a few hundred kilometres from home working with 2 friends on a small game development company. Because of this I haven't had the time to work on my usual projects.

See you next week with hopefully more in either situation!

Of file formats and black triangles

2009-02-09T23:21:00.000+01:00

So here I present to you another screenshot of the game in progress!

It doesn't look it, but there's a lot of things going on behind this simple 'level with weird red/yellow crap over it'.

The Red/yellow tiles are indicative of where the battle zone ends. I figured that you should be limited to a small 12x12 'arena' while doing combat instead of being able to run around the entire room, and possible the entire level. While the idea sounds interesting, it would cause the program to become too complicated and it would be too much work for the potential benefits you'd gain from it. So I left it out.

Now, as I mentioned already, the monsters get created properly and everything and what you see here is actually the 'in combat' rendering at work. I can pretty much start doing the actual combat system now. Woohoo! I hope it comes along in the next few weeks!

--

Now I said I'd talk a bit about my file format, and I decided to keep things short, because it really isn't all that.

I wanted a file format to store basically anything in. Something that would be fit for savegames, but also monster prototypes and attacks, levels and even the configuration file for the game itself (with video settings and whatnot). Also, it had to be readable in a normal text editor and it should be easy to write a parser for.

The direct result is the RCF file format. RCF stands for 'Readable Comma-seperated Filetype' and it's just that. I can yap on about it, but I think I'd better show a snippet to clarify.

** SDLRogue Monster and AI Attack database **
,1
,0,20,0,2,2,2,2,5,1,2,1,-1,30,1,15,2,1,3,-1,35,4,-1,Wolf
,0,25,0,2,1,1,4,5,1,2,1,-1,30,1,15,2,1,3,-1,35,4,-1,Undead Wolf
,-1
,0,0,1,4,3,0,95,0,1,2,1,0,0,0,Slash
,0,0,2,5,6,0,90,0,1,1,1,0,0,0,Maul
,-1
,

Looks easy no? With the game comes a readme that explains each variation in great detail so if this looks confusing, don't worry. Also if the game turns out to be played by anyone but me and my closest friends/relatives I'll probably create an editor for it as well. But we'll see how turn out.

So the next few weeks will be the combat system and the GUI for that. Should be interesting/aggrivating.

See you next week!

And... we're moved!!

2009-02-05T12:10:00.000+01:00

Woo! I'm officially moved in now! And I got my internet connection!

I tell ya, life without internet is really weird... I didn't realize how important it is to me until I had to do without for a week.

In any event, I've done some work on SDL-Rogue, unlike my expectations, and I glad to say that I finished most, if not all, of the preliminary work. The 'encounter' now triggers creation of a monster somewhere in the area where you can encounter them (which I refer to as encounter zones). The monster is then created by the specifications in it's prototype, which is loaded from a separate data file.

Depending on what level the monster is, it is given different attributes, though this won't be implemented until I've done the player's leveling math. I'll be using that as a reference because some monsters are meant to level on par with the player and others faster or slower, so I'll need the player's leveling code to base the monsters' off. It's no big deal anyway, because when the player doesn't level, the monsters don't need to.

So the next few weeks will be spent on the combat procedure. I've already done some minor work there but there's still a lot to be done, and with my track record of underestimating these tasks... it could take a while.

I'm glad to be able to update on mondays again, and I'll talk about the data file format I've created next week, so you'll have at least that to look forward to.

Until then!

Moving around

2009-01-20T03:04:00.000+01:00

Well I'll be moving to my new pad this week, so nothing new done so far, maybe not even by next week, but we'll see how that turns out.

Talked with someone into game development this week. That was cool. We're both doing similar things and it's nice to share experiences about this sort of thing.

Well anyway, see you next week.

Just Truckin'

2009-01-12T19:55:00.000+01:00

Just a small update, to keep the habit and let you all know I'm still on this.

Battle is progressing slowly but surely. The ground work was, again, a little more then I anticipated, as I'm working with objects that are sure to be removed from the object array when I'm done, and this space will need to be allocated. This along with figuring out placement was what kept me busy the last week.

Work is expected to continue steadily this week, so I'll see you next Monday.

Happy New Year!

2009-01-06T02:13:00.000+01:00

Happy new years to everyone!

It's a bit late, I know, but I suppose it's better than nothing.

I've actually done some considerable progress on SDL-Rogue. I've rewritten the rendering engine, making it a lot faster and more efficient, and in the process some HUD related things where modified which should allow me to do a lot of HUD manipulation very easily, in the future.

The work on the combat system has started, I'm currently in the initial phase of setting everything up, thinking it through (and writing all that down) and getting myself hyped for the (no doubt tedious) work this will be.

I'll be updating, when I feel like it, but always before thuesdays, so check back weekly!

Good 2009!!

Nothing... nothing at all

2008-10-27T23:57:00.001+01:00

Just that. I had my vacation this week, so nothing happened. Maybe this week? We'll see! I'll be updating regularly again from this point, so there's at least that to look forward to.

Until next week!

Math, Compilers and Expansive Tilesets!

2008-10-13T21:22:00.000+02:00

It's been a busy week!

Me and a friend of mine, Demian, decided to have a look at the Sin, Cos, Tan story this week. He's a pretty math-savvy guy so it didn't take us long to have the correct formula. Strange thing was, the result the formula returned wasn't anything like it should've been. We checked with a separate calculator and either I screwed up somewhere bigtime or these functions aren't as accurate as they need to be. A little test with a different program later proved this when a simple call to the Sin function gave compiler trouble.

So for now, that's the voyage... to see if we borked, or if we crossed a compiler/library bug.

Aside from all of that, I finished the interface. The clicking works, I'm displaying some debug information on the screen, got the planets suspended in 90 degree intervals (that much works) and I've made the initial pass on the 'on planet' tilesets as well as some touchups to the graphic work. It may be minor, but I prefer getting the 'art-style' accurate from the start.

I've fixed a bunch of bugs, tweaked a few things for performance and added the same logging that is present in SDL-Rogue.

All in all... a very productive week!

Also, It's my birthday tomorrow, so I'll take congratulations and absurdly-large presents at the door, as well as in my inbox ;)

See you next week!

They took my blood... but I'm still not giving in to math!!

2008-10-06T22:34:00.000+02:00

Decided to have a bloodtest done. Lots of signs that I'm sick, but my temperature's normal. Should have the results back tomorrow, I'm not expecting anything bad though... probably got to pay more attention to what I eat. :)

I did a mayor performance upgrade this week. I changed the rendering engine around so now I have SICK framerates when browsing the galaxy view (where you see all the stars). I also wrote the mouse interface, and managed to get it as fast as the rendering procedure. I'm really getting the hang of this performance conscious programming. It's fun to do too!

So the program registers when you mouse over a star now, and shows a little indicator that tells you which star is in focus. All I have to do now is drop in the 'onclick' command to take you to the star view and we have an interface.

Then I'll have to give in to the math... or move on to the next stage: Planet maps... hmm... I'm afraid that's a pretty easy decision right there...

Until next time!

Onwards! To math!

2008-09-29T19:42:00.000+02:00

I keep moving the 'getting into math' part of my schedule ahead of me... I think I'm going to have to face the music sooner or later... but for now 'later' sounds pretty good!

The galaxy generator is done now. It's also scalable so if I increase the size of my galaxy I shouldn't run into any weird issues. I'm currently working on the 'system rendering' and the interface bit which should get you to the star you want to see. The rendering itself, in a basic form, exists but the interface needs to be done still and I still need to do the math bit so the solar system looks like a solar system, rather then a list of planets.

I also decided to link SDL_TTF so I can paste freefont text on the screen. It's amusing how much easier that's going every time I do it.

Well, I'm not quite 'healthy' just yet... I thought I was... but I guess I was wrong, so I hope I get proper well now so I can spend some more significant time on this.

Oh, and anyone who can find me an easy to understand tutorial on the mathematical functions Sin, Cos and Tan will become my idol for the next month. I'd really appreciate some input there :)

Until next time!

Down with the sickness

2008-09-22T18:00:00.000+02:00

What is it with me getting sick in the middle of an interesting project?

Anyway, the past week I've been mostly fixing bugs on the galaxy generation code... and I'm not quite done with it yet. For now it's just going to be a flat/random galaxy until I decide a better algorithm is needed. After I'm done with all that I'm going to start on the starview, which is where you can see what planets are within a star. They're all going to be orbiting as well so I'm going to have to get reacquainted with my old nemeses, Sin, Cos and Tan.

Oh boy...

Until next week!

Dots, Dots, Dots...

2008-09-15T23:51:00.000+02:00

De datastructures are set now. It's a fine piece of work, if I do say so myself, and I'm confident I won't have to change it much over the course of this project.

What I'm working on for Project: Space is something I like to call: UniBrowse!

It's a program that creates a universe, consisting of a few thousand stars. Each stars will have planets orbitting it and all should be viewable from a simple mouse-driven interface. Right now I have the program generating a random universe on startup, and although there are a few minor bugs with the system, I should have that all wrapped up by next week.

The universe that gets generated now is a bit random still... I'm trying to get it look a little like a galaxy-shape but that may take a little while as my math is still a little rusty.

So that's been this week, I'll talk to you guys next monday!

And now for something completely different!

2008-09-09T20:02:00.000+02:00

Hmm, I guess I forgot another update last week... whattaya know?

In any event, I decided to do a new project. SDL-Rogue was becoming somewhat boring and I had been busy with this other idea for a game for the last few weeks. The original idea is by my uncle and the plan was to create this thing together. He's a very busy guy however, so I took it upon myself to get some things up and running already, in the hope of motivating him as well.

Don't worry about SDL-Rogue, it won't get a lower priority then it has had for the past few months ;) - I definately want to get a first release out and I will. The timeframe has just shifted a little.

I'll be posting about this new topic under the name of "Project: SPACE". The people that know me personally probably know what I'm talking about, but for you that don't... it's kind of a secret. I'll let you know more as time progresses.

So I've got some preliminary's set up, the basic data structure figured out and the idea is to create a program that can setup, and look at, the game world. The next step after that will be to output it to XML so our actual game can handle it... whenever that gets made!

See you next week!

Coding sickness?

2008-08-25T18:40:00.000+02:00

So I was sick last week... or rather... I was sick the week before that and completely forgot to update last week. I've been getting back to my code though and I'll probably be going at full steam by next weekend... this mostly because my most current codebase is elsewhere.

In the mean time, I've uploaded a screenshot of the most current build, showing off the full GUI as it is now. This to appease anyone getting sick of the little progress so far.

Another update next week!

Back To Regulation!

2008-08-11T20:27:00.000+02:00

Well so far for my vacation. I had a blast! Wacken was awesome, and so was New Wine but it's time to get back to my code now.

It still looks to be a bit tricky though, I just got me a dayjob, as mentioned before, and I'm spending a lot of time on that. Add to that the fact that my current codework is a pretty hefty implementation of the combat system, which requires me to recreate the way monsters are made, stored and handled, requires several big alterations of current workings and is, overal, not something I can do bit by bit just by looking at the code. I'll need my reference material, my own scribbles on combat mechanics (courtesy of having a notepad on vacation) and I need to just sit down and do this in 1 or 2 sittings. I fear that this will be 2 or 3 hour sittings so I hope I can get it done the next week... or at least do part this week.

I'll keep you posted!

Irregular update #2

2008-07-28T22:22:00.000+02:00

My vacation is pretty relaxing, that's good! Playing with the (new) band... gaming... going to conventions and festivals... it's all good!

Got me a job as well... don't know how that will affect my coding yet, but I think it's going to be positive. The less time you have, the more worthwhile you'll want to spend it... but we'll see how that turns out.

See you next monday!

Irregular update #1

2008-07-16T14:06:00.000+02:00

It's vacation, as I mentioned in my previous post, which means no regular updates and a lot less coding, and that's fine.

From August 11th, there will be regular updates again, until then... who knows!

Stop, Think, Don't delete your stuff.

2008-06-30T15:56:00.000+02:00

When I travel I get the most of my coding done. You sit in a train and you just know you've got a half-hour to waste. Add the laptop, subtract the internet, and you've got a pretty good motivation to do coding. Ofcourse, I also code at home so before I work on my code at home I copy the code from my laptop over here. When I leave the house for more then a day, I copy my code from my PC to my laptop.

Bulletproof system? Think again! Apparently somewhere after an unscheduled travel, in which I did a bunch of work on my code, I forgot to copy my code to my PC. So I get ready for the weekend, copy my code from my PC to my laptop and... "Hmm I thought I did a lot more work already" Very stupid indeed. Guess I'll check timestamps in the future.

In any event, I finished the error handling routine and I'm now replacing old error code with the new, much more efficient, way of error handling. I'm also implementing the log entries throughout the program. It's not that much work but it tends to get a little tedious every now and then. I should probably have everything moved and upgraded by the end of this week, or by Monday.

Additionally, my vacation has officially started, so the next 6 weeks may be light on code. Not to worry though, I'll get back to it afterwards. I will try to update bi-weekly to 'keep the habit' so to speak.

Peeking under the hood

2008-06-23T22:45:00.000+02:00

Unlike what you might think by now I've been quite busy, both with real life and to a (surprisingly good) degree with my code.

I've got the Arena loading pretty much nailed, save a few finishing touches, and I'm almost ready to move on to the next bit. I have decided that this will be error handling. Currently I'm just pasting crap to the error log that SDL generates automatically, but I keep finding this approach inappropriate and very unprofessional... not to mention it's making my code look all cluttered.

"A code snippet of what will soon be a memory of bad error handling"

So I've decided to write a procedure dedicated to error handling. Not only will this save this considerable amounts of code but it will also allow me to easily output everything uniformly so it's easier to browse through the error log. I've also decided to output a general program log that keeps track of routine stuff, non-routine stuff and debug information for errors. Although I may just report the error in the program log and stuff the debug information in the error log... I haven't decided yet... though, now that I think about it, I think I prefer the latter approach.

Also, I'm changing my update day to monday as that's more convenient and increases the odds I will actually post an update. (...like I should! Bad demotivated Rider! Bad!!!)

Zap-a-Bug!

2008-06-08T22:07:00.000+02:00

So I've been zapping bugs the past week(end) and I've finally finished up the monster database loading routine. I'm now writing documentation on the usage of the monster file as I already did the same for the level format. I'm hoping this will aid in getting people motivated to make their own content one day. If something's easy... that just means less standing in between an end-user and their potential new mod/total conversion/whatever!!

But I'm glad that's over with... freaking bugs where driving me bonkers... apparently I wrote a format that's pretty picky about the 'end of line' character... I'll have to include that in the readme somewhere.

The next thing I'm going to do is create the 'attack file format' which will hold all the AI usable attacks. After that's done, I'll find out a way to generate an arena which will be used for combat and once that is done... I can actually generate a monster when an 'encounter' happens, place him and you in the battle zone and start the battle procedures!

I'm so close I can taste it!

See you next weekend then :)

Your mom's an inner workings!

2008-06-01T22:29:00.000+02:00

Not a great deal of progress since the last post here. The whole encounter thing works like a charm now and I started the next required component for combat encounters... the monsters! So far the data structure is in place that will hold the monster prototypes (from which the actual monsters are to be generated) and I'm nearly done with the part where they're loaded from a separate file.

Which reminds me...

I was thinking about how the game's root folder was getting sort of full and starting sorting stuff, dumping it neatly in folders like "bmp" and "levels" when I figured that it would be SO easy to just create an alternate version of these folders and thus allowing users to easily mod the game to include new levels, different monsters and new tilesets. So I dumped all those neat folders in a base folder and decided to include full-on mod support. It should just be a matter of making the parameters, the one indicating where to find the files, slighly more dynamic by adding a 'base folder name' part which can be changed to any value thus changing from which "mod" folder the contents are being loaded.

A brilliantly simple solution.

So I just got to figure out how the player will swap between mods (menu, command prompt) and how the program logic will fit in that picture (will it preread the folders content and offer each folder as a possible mod?) and we've got mod support!

The whole monster/encounter bit is still main priority, but when I get enough of boring procedure writing I can always alternate between that and exciting new feature coding! Woo!

Get back to work, you slacker!

2008-05-26T22:12:00.000+02:00

Alrighty, it's time to get back to it!

So I've got the "encounter areas" implemented and loading from the level file and I was thinking about how I was going to calculate whether the player is in one of the zones available to each room... and I came to the conclusion that calculating that on the fly using the encounter layer as a reference tool isn't really efficient. So in addition to the normal camera bounds calculation that I do on entering a room (to keep the camera inside the level at all times) I draw a little 'encounter tile layer' for the current room as well. So now checking to see if the player is in an encounter area (and which one it is) is a simple one line procedure!

Now I just gotta get the whole thing properly debugged... 'cause somewhere along the line I must've made a wee mistake since the whole thing doesn't do jack right now... so far for hard work I guess...

The theory is pretty sound still... just gotta work out the kinks :)

Anyway, I'll go back to weekend updates again from this point, so stay tuned!

Files and datastructures

2008-05-10T00:40:00.000+02:00

He's coming up on the goal... he shoots... he scores!

SDLRogue now succesfully loads config data (& performance regulatory variables), tileset data (collidability only at the moment) and all level related data (tiles, objects and all that) from individual files. That means that I now have a level format! In the near future I'll probably create a level editor so I can make all my content with an easy to use utility. I might also release the level editor prior to the game itself to see if any of the people interested in this project can come up with neat level designs... oh and for bug testing... ofcourse...

I also adjusted my tileset/object/etc. datastructures. In the past they used an X and Y coordinate to indicate in which room they where, but since I use 'teleporters' to transport the player from one room to another, this method is bound to limit level builders and potentially make stuff a LOT more complicated then it needs to be. So now it's a single-coordinate array that indicates the room number.

So I suppose I should get some combat working now right? Well I guess... since you insist... I can't really give you an estimate on when it'll be done but I promise to get on it the coming week.

Updates will henceforth be posted in the weekends (with sunday as the latest possible day to do so). So be sure to check back weekly for the lowdown on progress!

Vacation kicks asscheeks!

2008-05-03T12:33:00.000+02:00

Just thought I'd let everyone know I'm still alive and haven't forgotten about this blog (and associated projects) yet.

I've been enjoying my vacation a lot. I really enjoy all the free time I have on my hands now... so much so that I'm sporadically doing work even! It's a scary thing... anyway... I've done a few things in the past week that I thought I would share here. I made some minor improvements to the control scheme for one. You now use a single button for all your ingame actions (versus having separate buttons for "use" and "choose menu option") which have been statically mapped to the control buttons.

You can also now toggle full-screen mode while in the game. And to be honest, I like fullscreen mode a lot more now that I can do that!

I also shifted some priorities around. I'll be implementing the "loading stuff from a file" system first before I move on to monster and combat. This so I don't do a lot of double work with the monsters and their attacks later on. I've been pushing this thing ahead of me for too long anyway.

So that's that. Now if you'll excuse me... I have freedom to celebrate!

Small progress is progress too!

2008-04-28T17:03:00.000+02:00

Here's a list of code changes I did since the last post

Created a Monster class
Changed a variable playername

This Monster class is nearly identical to the Player class and will hold all the information about any monster you're currently fighting.

So not a lot of changes code-wise. I have however already thought out every other element needed to set up a battle scene. I've figured out what I need for the monster data structure, the AI attack data structure, the spell data structure, the weapon data structure and the move data structure. (A move is choosen in conjuction with a spell or weapon to produce varying effects with strategic advantages and disadvantages)

In short, I've figured out what I need to make and how I need to make it. Now all that remains is making it.

This week and next week are vacation weeks for me, and I might or might not do anything then (with the likelyhood of second week productivity being higher) but I'll make sure to at least post something here at the end of my vacation with a schedule and/or new deadline.

See you then!

Fail due to gaming

2008-04-24T12:06:00.000+02:00

Alright, so Wednesday passed without notice. I did think of updating with the current state of affairs yesterday, but wouldn't you know it... the moment I decided to do that is the moment blogspot/blogger decides to update and disable the creation of new posts.

I missed this time's deadline. I realize, after the fact, that it may have been a bit too optimistic to think I could have some basic encounters ready already, mostly because the following needs to be in place before an encounter can be had (this taking into account the order of things in which I choose to do them to avoid too much rewriting of code due to bad design choices):

There need to be monsters (I don't even have a monster class yet)
Encounter areas need to be defined (Location, which monsters you can find there)
Encounter areas need to trigger encounters on set intervals (or random intervals, haven't decided yet)
The encounter needs to trigger the new battlegrounds to be made (and trigger random monster creation)

All this is probably a good indicator for me to think through my deadlines better. Now I could attribute my failing to that entirely (and you wouldn't be the wiser) but I admit that there was something else that kept me from my work... that being Trackmania. This litte (well...little...) game is just too addicting... and I don't even LIKE racegames...

So the coming days will be geared towards setting up the monster class and trying to get an encounter going on. I won't be having a deadline this time around, but I'll be sure to post a progress update around the weekend to keep you informed, and myself motivated to keep this all up.

Until then!

Deadline met!

2008-04-21T13:50:00.000+02:00

Woohoo! I made my own deadline!

The Sidebar is now complete as it shows the players current stats, keys, cash and all that crap. I made it so that you can specify which 'section' of the sidebar needs to be redrawn and everything else will remain as it is. This will hopefully have a positive inpact on performance as the sidebar doesn't need to be drawn every time the screen has to... and when one of your stats changes, only the relevant piece will be redrawn.

I hope I won't get such a boring task in the near future... because this hasn't exactly been the most exciting portion to write.

So my next step is: Combat!

I've been doing some thinking about how I want to do combat and I think I'm going to do something that combines Final Fantasy's "real-time turn-based" system with the whole "walk around on the battlefield" bit from Megaman battle network. I think I can come up with something that depends partly on your characters skills and traits but also requires a degree of strategy and forethought. I want to avoid a "encounter, instant-kill, rinse, repeat" method of playing so that combat won't become a bore as you become more and more powerful.

The levelling system has also been planned out now (although you can probably make out something already from the screenshot in my last post) and from here on in it's just a desiging and building process. I'm not quite sure how long this'll take, but I intend to have the "encounter a monster, get battlefield" done by Wednesday and a bit of actual combat by Monday of next week.

Progress is well, and I intend to keep that up! :)

Progress Report for SDL-Rogue

2008-04-17T22:53:00.000+02:00

Well, I said I would have the HUD done by thursday, and it's thursday so logically that would mean the HUD work is done right? Well... not exactly. I've made significant progress in setting everything up and writing all the procedures, but it's a lot more time-consuming then I figured it would be... not to mention the fact that it's BORING AS FUCK!

I'm not sure if that's the reason for my killer head-ache or some other, currently unidentified, reason, but whatever the case may be... I'm done for today.

I took the liberty of uploading a screenshot of SDL-Rogue to imageshack for your amusement... and to show that I have indeed been doing the work I say I've been doing... to clarify... that sidebar was pitch black at the time of my previous posting, and all the things you see in it now reflect the players actual stats (which are new as well)

So work will proceed on this and my current goal for getting the HUD done has been set for thuesday. That way, if my weekend ends up being surprisingly fun, I still have a whole day to work on it and get it done at the last minute.

I take these "deadlines" pretty seriously... so until then!

Oh, and check out this screenshot of the work in progress.

Current progress on "SDL-Rogue"

2008-04-15T22:42:00.000+02:00

This is simply a repost of my own "Roadmap" that I have with the source code. Essentially it's my current achievements and goals document... if it isn't in here, I don't intend to implement it. Naturally I might decide to add stuff as I go along, but I usually plan them somewhere I feel it makes sense.

Anyway, the details.

Accomplished:

Tile rendering
Player rendering
Player movement (+ smooth movement)
Player collision
Camera implementation (+ border limiting)
Teleports (= visible or invisible staircases)
Upper layer (purely aesthetic drawing layer on top of player)
Performance increase + FPS Limiting
Doors
Popup Menu allowing player to "open door" and "unlock door"
Keys (with which locked doors can be opened)

To do:

Add stats to the player, render them in the sidebar
- Name
- HP & MP
- STR, INT, DEX, CON, CHA, LUC
- Keys
- Money
Add Combat (with basic hardcoded weapon)
Add "Level up" functionality (stats change dynamically as you level)
*Not sure how to do this yet, don't want to stick to generic experience/levelling system
Add carryable items
Add 'treasure chests'
Add item usability
Add carryable weapons (replacing the hardcoded one)
Add Spells
Have the following load from a file (instead of being hardcoded)
> Specific objects (object[#][#])
> The level (all the rooms)
> Which tiles are collidable
> Performance Optimization variables
Create a Main Menu, functioning as the program 'home'
Add Save/Load Functionality
Add ingame Config editting for major functions
Create "Random Level" routine to make it a true Roguelike game
Create a sepperate level editor to create rooms/levels/worlds
Create conversation system
Build a Singleplayer campaign

Obviously, there are a few things missing from this list... for instance... I have no idea where I will stick the 'different types of monsters' yet, I'm not even sure how I want to do that (computer generated, hardcoded, from a file) so that, among other things, is something I'll decide on when I feel it becomes necessary.

Everything else just outlines some things I want to do with this game, like a sense of direction. I want to have a singleplayer campaign at some point (because it's cool, and I get to show off my 'comedic conversation making') as well as being able to load a lot of crap from files instead of having that reside inside the program executable.

So it's by no means a complete list of all the things I'm going to do, and in what order I will do them, but it's a decent indication... especially when I'm going "Well... what should I add next?!?"

That's enough for today. I hope to have the stats rendering done by thursday, so that's what I'll be aiming for... now here's to hoping I can motivate myself to get off my ass and go and do that!

Until then!

Game Development, here I come!

2008-04-15T10:48:00.000+02:00

So I figured that, in order to motivate myself, I should probably talk about my progress in developing games and all that, so here is the Blog associated with my own personal game developer company thing; Backyard Interactive.

This was originally going to be the name under which I and a few others would create a First Person Shooter as sort of a tribute to the Duke Nukem series... but that all got canned and since I still had the logo (and the name hasn't been taken by anyone else yet) I figured I might as well call it that.

So henceforth, you'll find updates on my developing for Backyard Interactive here.

--

Now let's talk games!

I'm currently working on a top-down 2D RPG game using C++ and SDL. The original purpose of this was to show how I can do this as well... but then after 3 weeks I wasn't quite there (features features features), so I figured I might as well toss the time table out the window and do a proper game with everything I'd want to see in it.

So at the moment, I have something that's probably more akin to a tech demo than an actual game, but I'll be hammering away at it trying to make it into something fun and (hopefully) entertaining to play.

I will post up a list of features implemented as well as features planned soon... it's been a few weeks since I worked on it and I need to review the featurelist again. I'll post about it under the name of "SDL-Rogue" as that's what the project name is at the moment :D

So, see you next time!