Results and changelogs

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!

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

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...

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

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

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

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!