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!

All my designs

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

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

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

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

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

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

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

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

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

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

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

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.