For detailed changes click here.
I am pleased to say, my map editor is almost 100% complete. I’d judge it at about 85% considering I can’t add the actual “Game Entities” yet until I’ve actually programmed them. But I’m also happy because when it does come to implementing them it should be a piece of cake, I am really starting love my GUI system now for ease of use. It’s basically a onetime set up and it handles itself! The only thing that is a bit annoying is all the call-back functions, even though they normally 1 – 3 lines of code, they are many. One for every element anyway. I don’t like them because they are a pain to name nicely, and they seem messy. But I guess that is just how it has to be. (I just watched the video and found some more bugs, you will probably see them, guess that is what I get for opening my mouth :P).
Since my last post where I listed the changes I had made within the GUI I thought it would be a good idea to keep a sort of “change log.txt” for every post. I won’t fill out every post with it, instead I have made a quick post before this one which I will keep updating with every new post I make. The log will indicate what I have gotten done from one post to the next. For some reason it also helps me come up with what I should be doing next which is only a good thing! There is a link on the right to the change log, but I will also put it at the top of every post just so I don’t have to point it out all the time.
I’m not going to go into any great detail in this post because my last lot have been way to long, but take a look at the video below and you can see how far it has come in just a day, or two, I can’t remember if I posted yesterday or the day before now... Anyway, to the eye candy!
Because I haven’t talked much, if at all about what type of game I’m making you might wonder why I only have 6 different cell sprites. Eventually, probably by the end of next week, each sprite will hold a lot of different types of the same sprite that the editor will choose randomly. Obviously I’m not going to keep them one colour, but they represent what they are meant to be, grass, mountain, water, tree etc... I’m going to use the editor to do the work for me when it comes to mapping as I’m too lazy to fill in all the corners of a forest, or make the mountain flow... Hope you get what I mean, I can’t really explain it without a picture or a video of it, but imagine Advance Wars map editor, when you lay down grass there it automatically fills in the edges for water, sand, trees etc...
Another thing I need to add is the selection of different size of maps. Earlier today I had 2 text boxes which let you set them yourself, but since my game won’t need that attention to detail, I’m going to add buttons for a small\medium\large map when creating a new one which will suffice.
God this is getting long again, well until next time, if you can’t be good, don’t be.
Saturday, February 27, 2010
Change Log
Log is kept in sync with my posting and indicates all the work I have done. I try to put most of it anyway. The boring things I leave out.
v0.0.06 - Post: 02-03-10
````````````````````````````````````````````````````````````````````````````````````````````````````
+ Created TextBox class [BaseObj, AnimObj] - Behaves much like any RPG message box.
- Supports any dimensions (height generated from text, and number of lines required. Box will
scale down if the num lines required is less than it needs to display)
- Supports <html tag> like symbols within the text string itself to denote certain colours and
fonts for different characters witihn the string
- Text cannot be skipped until the required number of lines has been shown, however it can be
sped up a lot by holding down choosen button
- If no title is supplied it is assumed the "per character drawing" is not needed as speech and
prints whole line straight away.
* Added TextBox to GameState class, it is assumed most\if not all will need to display one
v0.0.05 - Post: 27-01-10
````````````````````````````````````````````````````````````````````````````````````````````````````
* Added GuiObj support via vector in GameState class (moved from just the MapEditor as it is deemed
all classes will need some sort of GUI).
- GameState clean_up() also responsible for removing any memory inside this vector during
derived class's clean_up()
- Add individual functions for calls to the GuiObj input, logc, draw routines. Due to the fact
all the code will be identical for each derived game state. (The extra code, other than
calling those GuiObj functions is just so we can keep track of the active menu and make
sure it's drawn last, it's input is taken first (even when it's above another menu).
* Added font support inside the GameState class through an array. Named at the moment Main Font,
Header Font, Gui Font. Can always add more support later. Clean up of fonts done in GameState.
- Also added load_font(int font_id, std::string font_name) for convinience when checking if
a font loaded, and so I dont have to type the path for the font all the time. If function
fails, initialisation for that state fails, as font is considered "Primary Resource".
+ Text class created - Wrapper for Allegro equiv draw_text\f functions with some helpful additions
like colour, transparency etc...
* Replaced header guards with #pragman once since it's sexier.
* Changed filename format from lower_case.cpp to SexyStyle.cpp (49 of them >.<)
* Added transparency support to Sprite class.
+ Label class create [GuiElement] - Like a text box, but the value inside cannot be updated via
input, but rather it's callback function.
* Windows can now be locked in place
* Added "reset position" button inside Window title bars (optional)
* Added GuiObj Menus to MapEditor
* Implemented New\Save\Load map functions - (still need to get those dialog boxes in a new thread)
* Can now "paint" map with selected sprite and type
* Added support for buttons to call their callback function just on one "click\press" or while their
"held\pressed"
v0.0.04 and below & Complete Class Listing (Anything bulleted with a + is after 0.0.04)
````````````````````````````````````````````````````````````````````````````````````````````````````
* Console class created - For debug purposes, can be written to and viewed in-game
* Text File class created - Handles the opening\saving\writing to
* System class created - Responsible for setting up allegro, installing addons, creating display
* Keyboard class created - Handles all keyboard input through Allegro event system (global)
* Mouse class created - Handles all mouse input through Allegro event system (global)
* Engine class created - Responsible for main game loop, handling game states and events
* GameState class created - Base class for all game states, has all the stuff a typical gamestate
might need
* BaseObj class created - For all objects to derive from who have an x,y,width,height
* AnimObj class created - For any class who wants animation support (graphical or not)
* Sprite class created [BaseObj, AnimObj] - For any "graphical" obj to derive from. Handles
rotation\scaling\transparency etc...
* Image class created - Loads an image from disk, stores its name and path
* ImageManager class created - For the GameState class, takes care of making sure we only load one
image of the same name. Responsible for loading\unloading images. Has a vector of Image class
* MapCell class created [Sprite] - A single cell which as a group makes up a map
* Map class created [BaseObj] - Has a vector of MapCells for dynamic maps, responsible for drawing
the map, scrolling (built in camera functions)
* GuiElement class created [Sprite] - A single GUI element responsible for its own input, drawing
(through base sprite class), and logic (Pure Virtual class)
* GuiObj class created [BaseObj] - Stores GUI elements inside a vector. Responsible for group action
via input logic and drawing for these vector members.
* Button class created [GuiElement] - Simple button element, calls callback function on mouse click
or keyboard input (1 + Created TextBox class [BaseObj, AnimObj] - Behaves much like any RPG message box.key)
* TextField class created [GuiElement] - Takes input from keyboard, returns value in requested
format
* Window class created [GuiObj] - Adds functionality to the basic GuiObj in that it behaves much
like any window you've seen before... kind of
* MainMenu class created [GameState] - Main menu for game (empty at the moment), use F keys for
debug, swap state)
* Game class created [GameState] - State for the main game (empty at the moment)
* MapEditor class created [GameState] - As the name suggests. Used for mainly test purposes at the
moment.
+ Text class - Wrapper for Allegro equiv draw_text\f functions with some helpful additions
like colour, transparency etc...
+ Label class create [GuiElement] - Like a text box, but the value inside cannot be updated via
input, but rather it's callback function.
+ Created TextBox class [BaseObj, AnimObj] - Behaves much like any RPG message box.
v0.0.06 - Post: 02-03-10
````````````````````````````````````````````````````````````````````````````````````````````````````
+ Created TextBox class [BaseObj, AnimObj] - Behaves much like any RPG message box.
- Supports any dimensions (height generated from text, and number of lines required. Box will
scale down if the num lines required is less than it needs to display)
- Supports <html tag> like symbols within the text string itself to denote certain colours and
fonts for different characters witihn the string
- Text cannot be skipped until the required number of lines has been shown, however it can be
sped up a lot by holding down choosen button
- If no title is supplied it is assumed the "per character drawing" is not needed as speech and
prints whole line straight away.
* Added TextBox to GameState class, it is assumed most\if not all will need to display one
v0.0.05 - Post: 27-01-10
````````````````````````````````````````````````````````````````````````````````````````````````````
* Added GuiObj support via vector in GameState class (moved from just the MapEditor as it is deemed
all classes will need some sort of GUI).
- GameState clean_up() also responsible for removing any memory inside this vector during
derived class's clean_up()
- Add individual functions for calls to the GuiObj input, logc, draw routines. Due to the fact
all the code will be identical for each derived game state. (The extra code, other than
calling those GuiObj functions is just so we can keep track of the active menu and make
sure it's drawn last, it's input is taken first (even when it's above another menu).
* Added font support inside the GameState class through an array. Named at the moment Main Font,
Header Font, Gui Font. Can always add more support later. Clean up of fonts done in GameState.
- Also added load_font(int font_id, std::string font_name) for convinience when checking if
a font loaded, and so I dont have to type the path for the font all the time. If function
fails, initialisation for that state fails, as font is considered "Primary Resource".
+ Text class created - Wrapper for Allegro equiv draw_text\f functions with some helpful additions
like colour, transparency etc...
* Replaced header guards with #pragman once since it's sexier.
* Changed filename format from lower_case.cpp to SexyStyle.cpp (49 of them >.<)
* Added transparency support to Sprite class.
+ Label class create [GuiElement] - Like a text box, but the value inside cannot be updated via
input, but rather it's callback function.
* Windows can now be locked in place
* Added "reset position" button inside Window title bars (optional)
* Added GuiObj Menus to MapEditor
* Implemented New\Save\Load map functions - (still need to get those dialog boxes in a new thread)
* Can now "paint" map with selected sprite and type
* Added support for buttons to call their callback function just on one "click\press" or while their
"held\pressed"
v0.0.04 and below & Complete Class Listing (Anything bulleted with a + is after 0.0.04)
````````````````````````````````````````````````````````````````````````````````````````````````````
* Console class created - For debug purposes, can be written to and viewed in-game
* Text File class created - Handles the opening\saving\writing to
* System class created - Responsible for setting up allegro, installing addons, creating display
* Keyboard class created - Handles all keyboard input through Allegro event system (global)
* Mouse class created - Handles all mouse input through Allegro event system (global)
* Engine class created - Responsible for main game loop, handling game states and events
* GameState class created - Base class for all game states, has all the stuff a typical gamestate
might need
* BaseObj class created - For all objects to derive from who have an x,y,width,height
* AnimObj class created - For any class who wants animation support (graphical or not)
* Sprite class created [BaseObj, AnimObj] - For any "graphical" obj to derive from. Handles
rotation\scaling\transparency etc...
* Image class created - Loads an image from disk, stores its name and path
* ImageManager class created - For the GameState class, takes care of making sure we only load one
image of the same name. Responsible for loading\unloading images. Has a vector of Image class
* MapCell class created [Sprite] - A single cell which as a group makes up a map
* Map class created [BaseObj] - Has a vector of MapCells for dynamic maps, responsible for drawing
the map, scrolling (built in camera functions)
* GuiElement class created [Sprite] - A single GUI element responsible for its own input, drawing
(through base sprite class), and logic (Pure Virtual class)
* GuiObj class created [BaseObj] - Stores GUI elements inside a vector. Responsible for group action
via input logic and drawing for these vector members.
* Button class created [GuiElement] - Simple button element, calls callback function on mouse click
or keyboard input (1 + Created TextBox class [BaseObj, AnimObj] - Behaves much like any RPG message box.key)
* TextField class created [GuiElement] - Takes input from keyboard, returns value in requested
format
* Window class created [GuiObj] - Adds functionality to the basic GuiObj in that it behaves much
like any window you've seen before... kind of
* MainMenu class created [GameState] - Main menu for game (empty at the moment), use F keys for
debug, swap state)
* Game class created [GameState] - State for the main game (empty at the moment)
* MapEditor class created [GameState] - As the name suggests. Used for mainly test purposes at the
moment.
+ Text class - Wrapper for Allegro equiv draw_text\f functions with some helpful additions
like colour, transparency etc...
+ Label class create [GuiElement] - Like a text box, but the value inside cannot be updated via
input, but rather it's callback function.
+ Created TextBox class [BaseObj, AnimObj] - Behaves much like any RPG message box.
Thursday, February 25, 2010
GUI Fun
I know my last post was only yesterday, which doesn't mean I don't have a life, although that may be correct... But anyway I believe I have enough of an update on the GUI to show you a little more. I also found some really nice site which lets me highlight my C++ code just using css and html so I am able to share some snippets with you to help explain what I mean. In the future I may even write some tutorials depending on how confident I am the way I do things is something I can pass on to you without feeling a little guilty =p
(Skip to the bottom for a summary of the GUI features so far, I know I ramble on...)
And now you've seen the video let me explain what the heck is going on! I know it would be easier if I was actually talking over it, but (1) My voice is really boring (2) I don't have a mic (3) I probably won't do it anyway cause I'm to shy, or don't want to sound like a retard... maybe that's the same thing, I dunno. Anyway, as you can see I've done away with those horrible icons I was using last time and decided to go for a "default" button kind of feel made using Allegro's primitives. They really are just place holders at the moment until I do get some decent graphical buttons done. The buttons are made from 3 sections, a background rect, a border rect, and 2 highlight lines (ok that’s 4 but whatever), and during this process I had to choose colours for them, so I thought why not add in 3 types of colour every GuiElement can use? That way they can be changed at a later date. The function for changing the colour schemes for all of the objects within a GuiObj looks like the one below. Except the one below is from the derived window class, notice how it doesn't use the same colours as your using for the elements, but changes them slightly.
If you know of a better method to make this process better please let me know, it was just a quick hack to get it in code, I didn't really put any thought into it. The other change you might have noticed me badly demonstrating was Textbox support, or "Textfields" as I like to call them. Now I remember trying to make a similar thing in Allegro 4.2 and it was a pain in the arse, but with the way the event system works in A5 it was a piece of cake! Although I did bump into one issue whereby in the future I want certain elements linked to hot keys on the keyboard. This obviously proves a problem if the user is trying to type and pressing all these keys which might be opening menus, moving the play etc... So I had to work out a way to lock the input when a text field is active, but keep it open to the text field. I managed it by adding a void *pointer inside the keyboard class which I used much like a bool in that if it's NULL the keyboard input is NOT locked. An object wanting to lock the input needs to provide a pointer to itself in way of a form of ID when it comes to checking who wants to unlock it. This was necessary because one text field was fine, but when I added a second, because only one was active at a time the other kept unlocking the input. The other nice thing about the textboxes is that I can choose what input I want to allow, and also the fact you call their call-back functions by pressing enter (which is handy for when to know when to grab what's inside). Well there are a lot of features for my GUI system now, and way to much to go into in detail in a single post. But the summary below should give you an idea.
Gui Element
• Able to customise the colour through (background, border & highlight). Each derived element decides itself how to utilise them.
• Supports a single call-back function. Again the derived element decides when this is triggered, either through it's logic, or input function.
• Tab Index number, used in conjunction with the GuiObj it sits inside. Lets the element know when it is active.
• Can be enabled\disabled
• Has a label (std::string), which has a lot of alignment options (above, below, out-left, out-right, top, middle, bottom, left, right, centre etc..) Again this is optional whether to draw this, per element need.
• Returns a "value" of the derived elements choosing in the correct format, string, int, float etc...
Text Field
• Limits input to what I want it to accept
• Locks all other input while its being used (except for input which ignores the block)
• Has a flashing line to indicate it's active!
• Auto sets it's height for the font in use
• Only accepts as much characters as it's width will allow (might change this, but will eventually add a text box which will be multiline)
Button
• Uses its call-back when either the left mouse button is clicked on it, or the "select" key is pressed on the keyboard (see GuiObj for what that is)
• err... Accepts only single clicks\presses
GuiObj
• Stores Gui Elements inside a vector
• Supports keyboard\mouse input and the changing of how they are used to manipulate it (for example, the "next element" keyboard keys default is TAB, and its default "select" key is "Enter"
• Keeps track of the active element by TabIndex and mouse position
• Elements position relative to the location of the GuiObj
• Has nice "helper" functions for adding elements (see below)
Window
• Has a background, border, title colour attribute which tries to match the colour scheme of its elements
• Can be moved by mouse dragging
• Most of the time stays on top of other windows (need to sort this)
• Need to add “window buttons” (lock back to default position, lock in place, close etc...)
And wow wasn’t that long winded, feels longer for me since that “C++ to HTML” was giving me a headache using the blogger editor, it kept trying to change it! Anyway hope you weren’t bored to much, if you have any questions feel free to ask.
I’m hoping to move on from the GUI pretty soon, I think I have enough to get started with on the editor. Hmm, actually I need to create an element that can store pictures or something and scroll through them for the map tiles. *sigh* Stupid GUI.
(Skip to the bottom for a summary of the GUI features so far, I know I ramble on...)
And now you've seen the video let me explain what the heck is going on! I know it would be easier if I was actually talking over it, but (1) My voice is really boring (2) I don't have a mic (3) I probably won't do it anyway cause I'm to shy, or don't want to sound like a retard... maybe that's the same thing, I dunno. Anyway, as you can see I've done away with those horrible icons I was using last time and decided to go for a "default" button kind of feel made using Allegro's primitives. They really are just place holders at the moment until I do get some decent graphical buttons done. The buttons are made from 3 sections, a background rect, a border rect, and 2 highlight lines (ok that’s 4 but whatever), and during this process I had to choose colours for them, so I thought why not add in 3 types of colour every GuiElement can use? That way they can be changed at a later date. The function for changing the colour schemes for all of the objects within a GuiObj looks like the one below. Except the one below is from the derived window class, notice how it doesn't use the same colours as your using for the elements, but changes them slightly.
If you know of a better method to make this process better please let me know, it was just a quick hack to get it in code, I didn't really put any thought into it. The other change you might have noticed me badly demonstrating was Textbox support, or "Textfields" as I like to call them. Now I remember trying to make a similar thing in Allegro 4.2 and it was a pain in the arse, but with the way the event system works in A5 it was a piece of cake! Although I did bump into one issue whereby in the future I want certain elements linked to hot keys on the keyboard. This obviously proves a problem if the user is trying to type and pressing all these keys which might be opening menus, moving the play etc... So I had to work out a way to lock the input when a text field is active, but keep it open to the text field. I managed it by adding a void *pointer inside the keyboard class which I used much like a bool in that if it's NULL the keyboard input is NOT locked. An object wanting to lock the input needs to provide a pointer to itself in way of a form of ID when it comes to checking who wants to unlock it. This was necessary because one text field was fine, but when I added a second, because only one was active at a time the other kept unlocking the input. The other nice thing about the textboxes is that I can choose what input I want to allow, and also the fact you call their call-back functions by pressing enter (which is handy for when to know when to grab what's inside). Well there are a lot of features for my GUI system now, and way to much to go into in detail in a single post. But the summary below should give you an idea.
Gui Element
• Able to customise the colour through (background, border & highlight). Each derived element decides itself how to utilise them.
• Supports a single call-back function. Again the derived element decides when this is triggered, either through it's logic, or input function.
• Tab Index number, used in conjunction with the GuiObj it sits inside. Lets the element know when it is active.
• Can be enabled\disabled
• Has a label (std::string), which has a lot of alignment options (above, below, out-left, out-right, top, middle, bottom, left, right, centre etc..) Again this is optional whether to draw this, per element need.
• Returns a "value" of the derived elements choosing in the correct format, string, int, float etc...
Text Field
• Limits input to what I want it to accept
• Locks all other input while its being used (except for input which ignores the block)
• Has a flashing line to indicate it's active!
• Auto sets it's height for the font in use
• Only accepts as much characters as it's width will allow (might change this, but will eventually add a text box which will be multiline)
Button
• Uses its call-back when either the left mouse button is clicked on it, or the "select" key is pressed on the keyboard (see GuiObj for what that is)
• err... Accepts only single clicks\presses
GuiObj
• Stores Gui Elements inside a vector
• Supports keyboard\mouse input and the changing of how they are used to manipulate it (for example, the "next element" keyboard keys default is TAB, and its default "select" key is "Enter"
• Keeps track of the active element by TabIndex and mouse position
• Elements position relative to the location of the GuiObj
• Has nice "helper" functions for adding elements (see below)
Window
• Has a background, border, title colour attribute which tries to match the colour scheme of its elements
• Can be moved by mouse dragging
• Most of the time stays on top of other windows (need to sort this)
• Need to add “window buttons” (lock back to default position, lock in place, close etc...)
And wow wasn’t that long winded, feels longer for me since that “C++ to HTML” was giving me a headache using the blogger editor, it kept trying to change it! Anyway hope you weren’t bored to much, if you have any questions feel free to ask.
I’m hoping to move on from the GUI pretty soon, I think I have enough to get started with on the editor. Hmm, actually I need to create an element that can store pictures or something and scroll through them for the map tiles. *sigh* Stupid GUI.
Wednesday, February 24, 2010
GUI & Map Editor - A Match Made In Heaven?
Now I don't no if you have ever tried to make a game using Allegro & C++, but if you have it probably starts something like this:
The video above shows some of the progress I've made, but doesn't really do it justice. Most of the important things are in the code. As you can see things are very far from being finished let alone polished so forgive the rubbish graphics and let me explain a little bit about how the GUI works, I'll use the moveable GUI Window in the video as an example.
The GUI Window is derived from a GUI Object. The only addition the Window has (you might have guessed), is that it's drawn with a background and title bar and can be moved around. The GUI Object itself has a vector of GUI Elements which it looks after by calling their respective input, logic and drawing routines. When each GUI Element is added to the GUI Object it's given a callback function which is triggered (depending on its own conditions, for example the "Buttons" you see in the video is a mouse click) within either the elements logic or input functions. This keeps everything nice and encapsualted so all the engine has to worry about is calling the GUI Objects input,logic,draw functions. I hope at least some of that made sense, it felt like a right mouthful.
The main aim of the GUI system is so that elements add specialised functionality through the way their callback functions are triggered, and the objects themselves (which handle the elements) can use these to create more complicated GUI Objects. I will have some examples of these in my next update, most likely the scrollbar, which will be made up of 2 GUI Elements, the 2 buttons at either end. I will add functionality for the drawing of the bar and position within the object itself (or atleast that's what I think in my head anyway).
I won't go on about the map just yet, because that's still way to incomplete, but you might have noticed I have the save and load functions working correctly (even if it is only the map name you see changing).
So until the next time, if you can't be good, be careful!
- Great idea!
- Some sort of very rough mental planning
- Sit down to code
- Realise you need something to make the levels with because your levels are going cool storing them in a text file just wont cut it
- Now you realise you need to program some sort of GUI interface because hard coding everything is ugly and a pain in the arse to edit
- Get bored and realise your game wasn't so great after all
The video above shows some of the progress I've made, but doesn't really do it justice. Most of the important things are in the code. As you can see things are very far from being finished let alone polished so forgive the rubbish graphics and let me explain a little bit about how the GUI works, I'll use the moveable GUI Window in the video as an example.
The GUI Window is derived from a GUI Object. The only addition the Window has (you might have guessed), is that it's drawn with a background and title bar and can be moved around. The GUI Object itself has a vector of GUI Elements which it looks after by calling their respective input, logic and drawing routines. When each GUI Element is added to the GUI Object it's given a callback function which is triggered (depending on its own conditions, for example the "Buttons" you see in the video is a mouse click) within either the elements logic or input functions. This keeps everything nice and encapsualted so all the engine has to worry about is calling the GUI Objects input,logic,draw functions. I hope at least some of that made sense, it felt like a right mouthful.
The main aim of the GUI system is so that elements add specialised functionality through the way their callback functions are triggered, and the objects themselves (which handle the elements) can use these to create more complicated GUI Objects. I will have some examples of these in my next update, most likely the scrollbar, which will be made up of 2 GUI Elements, the 2 buttons at either end. I will add functionality for the drawing of the bar and position within the object itself (or atleast that's what I think in my head anyway).
I won't go on about the map just yet, because that's still way to incomplete, but you might have noticed I have the save and load functions working correctly (even if it is only the map name you see changing).
So until the next time, if you can't be good, be careful!
Thursday, February 18, 2010
First Footage
Since my last rather strange (looking back now) post, I thought I would share with you something a little more normal. Like what my game is currently looking like. Bare in mind I scrapped what I had of the time of my last post (which is near enough what I have now) and re-wrote all of the code. Since starting again I have actually learnt how to use extern correctly! God knows what I was doing without it before! Things seem a lot tidier now that I don't have to pass pointers through functions all the time. Don't get me wrong I'm not "externing" everything, in fact only my special console class and the keyboard\mouse class's. The console is actually a drop down box which displays text, which any class I feel needs to can write to it. This is mainly for debugging purposes while the game is running. It also saves a nice text file when the program closes in case anyone wishes to see what was happening.
Apart from that amazing discovery, I've managed to get a nice little sprite class going. Below is a brief video of some of the stuff it supports thus far.
To make the game I'm using C++ and Allegro. You can find links on the right if you wish to find out more about both. But as you can see I'm taking full advantage of Allegro's drawing routines to have maximum flexibility with my sprites (it looks jerky because cam studio is only capturing frames every 5ms). So far my sprites support scaling, rotation and flipping as far as image manipulation goes, and also animation.
I'm quite happy with the way the animation is working out so far, but you might have seen it still has a few bugs (the green square!). The way the maximum frames and number of animations is worked out is actually pretty sweet, once the bugs are ironed out I think I will write a tutorial on it.
Also another revelation this time round (I mean me programming again, I usually have around a 2 year gap) is the way my game states are handled. Someone posted a link to a tutorial on A.cc forums, which lead me to this tutorial. I mucked about with the code a bit and shoved it into my "engine" and so far it's working like a dream. I'm a sucker for keeping things organised and I believe this approach is perfect for it.
Well I think that's enough for today, until next time.
Apart from that amazing discovery, I've managed to get a nice little sprite class going. Below is a brief video of some of the stuff it supports thus far.
To make the game I'm using C++ and Allegro. You can find links on the right if you wish to find out more about both. But as you can see I'm taking full advantage of Allegro's drawing routines to have maximum flexibility with my sprites (it looks jerky because cam studio is only capturing frames every 5ms). So far my sprites support scaling, rotation and flipping as far as image manipulation goes, and also animation.
I'm quite happy with the way the animation is working out so far, but you might have seen it still has a few bugs (the green square!). The way the maximum frames and number of animations is worked out is actually pretty sweet, once the bugs are ironed out I think I will write a tutorial on it.
Also another revelation this time round (I mean me programming again, I usually have around a 2 year gap) is the way my game states are handled. Someone posted a link to a tutorial on A.cc forums, which lead me to this tutorial. I mucked about with the code a bit and shoved it into my "engine" and so far it's working like a dream. I'm a sucker for keeping things organised and I believe this approach is perfect for it.
Well I think that's enough for today, until next time.
Monday, February 15, 2010
Important Questions & First Post Ramblings
Why am I here? No. Not a question I expect you to be asking yourself with regards to this blog, but instead a question I asked myself. I spent what seemed like a life time starring into nothingness. You know the type of nothingness that looks like a wall with a light switch on it and sometimes has a door? No? Well its irrelevant anyway. The point is I wasn't spending my time idly while in this state of “zen", but in fact wondering what I could possibly write that anyone would want to read. To cut a long story short I fell asleep. I don't really remember dreaming, which is unusual for me, since the night time adventures in my mind are usually vivid. I did however awake with an idea for my first post. So here I am at this unsociable hour putting my thoughts to screen because I couldn't risk forgetting it. Well now you know my idea and how it came about (and I believe it's important to know the why of anything), I shall begin.
So, why am I here? First let me define here. I mean the here as in being, as in human being. Why is anyone here? Well I'm not going to go into some philosophical discussion about the ins and outs and the meaning of life, I could go on to explain my theories\facts (depending on how you look at it) but I won’t. In fact I'm going to be totally selfish and talk about me, after all it is my first ever post in my first ever blog*.
So to get to the point of answering that damn question, when I small I had a dream (not the night time type), a dream that would stay with me right up until now, and most likely until the very day I die (assuming before then the dream is not realised, in which case it wouldn't really be a dream anymore). "What is it?" I hear you saying (I almost really do, and for some reason you sound genuinely interested), well, *ahem* well, the dream is simple - I want to make video games! There I said it. No wait! Don't snicker and walk away in disgust. Let me elaborate on the why, remember, it's always important to know the why of anything. I'll try to keep this short, as I understand this post is getting pretty damn long, and if have got this far and you already read the blog description, I apologise for dragging out what that essentially says in little more than 50 words.
To the why "I want to make video games" then. We're getting close to the heart of the post now, very soon you will be able to witness it beating in all its glory. *Remembers mental note about keeping it short*
I've played games all my life, and like many thousands of others I enjoy them. But to me games are more than just a toy or an object of fun. For me games represent so much more. Games have some sort of magical power much like a film or a book has power. Not all games posses this. In fact to few do, But those that do, can make you weep, cry with laughter, weep again, break something in frustration etc... The point I'm trying to make is games can influence your emotions, much like anything can, but at the same time unlike anything else can. It's that emotional tie to the player games have I am interested in recreating in my own. I still remember waking up in a ruined Hyrule in Zelda: Ocarina of Time and being full or despair at the mess it was in, the immense feeling of revenge I felt when I watched Hazuki Sensei (my fictional father of which the first name escapes me, I think it begins with 'I') be killed right in front of me in Shenmue, or the time I completed Phantasy Star Online with 3 other people around the world which ended in an epic boss battle with music to make your eyes water at the heroicness of it. I could extend the list with endless examples (Aeries dying in Final Fantasy VII for example) but maybe I'll do that another day. But it's moments like that in games that have imprinted a memory inside of me I likely won’t ever forget. This is the why of my dream. The why I want to make games. Not just because I enjoy playing them, but because I want someone to list one of my games in the one I made above, someone to remember, like I have, but about one of my games. If by this time you're thinking I've lost the plot completely, I like to think of it as passion, not madness (and I know your thinking only a mad person would have to say something like that!).
And on a final note, I guess I better include what you can expect to find in this blog in future posts. Actually thinking about it now maybe that should have been my first post, and that alone...
Anyway I'll be using this blog as a place to keep written progress on the game I'm currently working on (as a way to keep myself motivated into finishing the damn thing!), as well as anything else that pops into my mind regarding game development in general. My next post will be shorter I... No I won’t promise, just in case.
I'm in two minds now whether I need to thank you for reading? Thanking you would mean this post isn't actually for the benefit of myself, but of you, the reader, and by that account I would then have to be disappointed if no one ever read it. On the other hand I could not thank you and believe these posts will only ever be for my benefit. Who am I trying to fool? Of course I want this damn post read, I didn't just sit here for an hour writing it! Thanks for reading then!
Someone who thinks too much,
Tomoso
* For the sake of accuracy this is actually my second blog, but I'm ignoring my previous blog for the simple fact I only ever made one post in it.
So, why am I here? First let me define here. I mean the here as in being, as in human being. Why is anyone here? Well I'm not going to go into some philosophical discussion about the ins and outs and the meaning of life, I could go on to explain my theories\facts (depending on how you look at it) but I won’t. In fact I'm going to be totally selfish and talk about me, after all it is my first ever post in my first ever blog*.
So to get to the point of answering that damn question, when I small I had a dream (not the night time type), a dream that would stay with me right up until now, and most likely until the very day I die (assuming before then the dream is not realised, in which case it wouldn't really be a dream anymore). "What is it?" I hear you saying (I almost really do, and for some reason you sound genuinely interested), well, *ahem* well, the dream is simple - I want to make video games! There I said it. No wait! Don't snicker and walk away in disgust. Let me elaborate on the why, remember, it's always important to know the why of anything. I'll try to keep this short, as I understand this post is getting pretty damn long, and if have got this far and you already read the blog description, I apologise for dragging out what that essentially says in little more than 50 words.
To the why "I want to make video games" then. We're getting close to the heart of the post now, very soon you will be able to witness it beating in all its glory. *Remembers mental note about keeping it short*
I've played games all my life, and like many thousands of others I enjoy them. But to me games are more than just a toy or an object of fun. For me games represent so much more. Games have some sort of magical power much like a film or a book has power. Not all games posses this. In fact to few do, But those that do, can make you weep, cry with laughter, weep again, break something in frustration etc... The point I'm trying to make is games can influence your emotions, much like anything can, but at the same time unlike anything else can. It's that emotional tie to the player games have I am interested in recreating in my own. I still remember waking up in a ruined Hyrule in Zelda: Ocarina of Time and being full or despair at the mess it was in, the immense feeling of revenge I felt when I watched Hazuki Sensei (my fictional father of which the first name escapes me, I think it begins with 'I') be killed right in front of me in Shenmue, or the time I completed Phantasy Star Online with 3 other people around the world which ended in an epic boss battle with music to make your eyes water at the heroicness of it. I could extend the list with endless examples (Aeries dying in Final Fantasy VII for example) but maybe I'll do that another day. But it's moments like that in games that have imprinted a memory inside of me I likely won’t ever forget. This is the why of my dream. The why I want to make games. Not just because I enjoy playing them, but because I want someone to list one of my games in the one I made above, someone to remember, like I have, but about one of my games. If by this time you're thinking I've lost the plot completely, I like to think of it as passion, not madness (and I know your thinking only a mad person would have to say something like that!).
And on a final note, I guess I better include what you can expect to find in this blog in future posts. Actually thinking about it now maybe that should have been my first post, and that alone...
Anyway I'll be using this blog as a place to keep written progress on the game I'm currently working on (as a way to keep myself motivated into finishing the damn thing!), as well as anything else that pops into my mind regarding game development in general. My next post will be shorter I... No I won’t promise, just in case.
I'm in two minds now whether I need to thank you for reading? Thanking you would mean this post isn't actually for the benefit of myself, but of you, the reader, and by that account I would then have to be disappointed if no one ever read it. On the other hand I could not thank you and believe these posts will only ever be for my benefit. Who am I trying to fool? Of course I want this damn post read, I didn't just sit here for an hour writing it! Thanks for reading then!
Someone who thinks too much,
Tomoso
* For the sake of accuracy this is actually my second blog, but I'm ignoring my previous blog for the simple fact I only ever made one post in it.
Subscribe to:
Posts (Atom)
Posts
