Finding out about it mid Saturday, I’ve spent 8 hours of the game jam making it, and I’m pretty happy with the result. The biggest issue being a lack of planning – probably on the basis of “it’s only a quick game, I can get away without —”; clearly a mistake to fall into.
Anyway, you can either download the game from this link, as a flash projector.exe file (requires no flash player to play – but is windows only).
Or you can play it below: http://www.glorioustrainwrecks.com/node/2727
Not that I assume anybody would, but feel free to distribute it and do what you wish with it. Hopefully you’ll find it fun, and leave me a comment about what you liked/disliked in it, as it’s my first “proper” game:
(Separate page as music/animation plays when page loads)
I’ve not posted since the start of the Holidays really, so I felt it was about time.
Anyway, I was playing around in Flash; and found to my dismay that unlike C++; there’s no support for Enums. After looking around for a bit and seeing some different implementations, ranging from grossly complicated to lacking in even type-safety; I thought I’d have a go at writing my own. Hopefully with us all doing Flash in Media Production for Games now – it’ll either help somebody out, or somebody else will show some improvements to make or a better way to do it.The three things I wanted to achieve were:
Type Safety, otherwise it’s useless as an Enum
Easy Creation of different Enums
Easy access to an int value and a string representation if wanted.
So, here’s the code for the base Enum class, from which you can make your specific Enums. Hopefully the code isn’t too badly written, but if it is just shout at me and tell me how to improve it:
That should work just copy pasted. From there it’s extremely easy to actually make use of. Just make a new class, with whatever name you want the Enum to be (Such as HungerState from the old CyberPet game). You’ll then want to write something that is similar to this. The string part is entirely optional, and you can obviously put whatever values you want on your Enums – the default is like C++, if you put the starting number on the first one, the rest increment to take the next number and so on.
The names of your different values (Such as Hungry, Famished, Ravenous etc) are simply the constants at the top. Just add or remove as many as you want and you’re good to go.
You can then make use of it in your main class, or whatever else; by simply making a variable of that Enum as it’s type. Such as ” var state:HungerState;”, which can be accessed as “state = HungerState.HUNGRY” for example.
Here is the code for making an Enum type, extended from the Enum base class above:
For my Computer and Graphics Architecture class; where we are working on the Gameboy Advance – we’ve been given an assignment to write a report about an influential game and then implement one of it’s features on the GBA.
My report is on Wolfenstein 3D; being one of the games to popularise the first-person genre, and so lead on to me wondering how possible it would be for me to implement the basics of the 3D into the GBA. After a few days work on this, and a lot of frustration – I’ve finally got something to show.
It’s very basic, and lacks any proper culling – but the projections are now in place; which for me was the hard part. Unlike most 3D projetions, this works on line intersections so that it can avoid using trig too often – which is rather slow on GBA hardware. Any comments or idea on how to take it further would be really appreciated:
As you can see, it renders triangular polygons to flat triangle shapes, and then renders those to the screen (which currently means drawing the edges as I’ve not finished the triangle drawing code). It’s unlikely that I’ll have any kind of texturing on the end result; but rough one-directional lighting is still a possibility.
After getting Devkit Pro working in order to do some homebrew GBA development, using the VBA emulator and Notepad++ editor, I felt it was time to get it working using a proper IDE. For me, that means VS2010 (MS do treat students rather well), which unfortunately also meant spending most of an evening looking for how to set this up; to no avail. However, I do feel I’ve now figured out what needs done, in very general steps – so hopefully you’ll get yours working from this too.
First of all, I’d just like to point a thanks towards console-dev.de as yet again, they’re provided some great resources that helped me understand this. If you get stuck reading this (as well as shouting at me), it’d be a good idea to read that guide – although it does use VS2008, and refers to Nintendo DS development, not the GBA development (small differences here and there).
Also, if you haven’t actually got devkitPro installed – please make sure to read the previous guide on getting that setup. It’s also wise to run the RunMake.bat file once as it kindly sets your Paths in Windows for you – to save you the hastle later.
Setting up VS2010
Preface
Because this is just utilising the VS IDE; there are no downloads. You should have everything on your PC that you’ll need to do this.
In order to do this, it’s best to start a new project – I’ll be running through this as if you’ve not got any source files created already. It’s likely you’ve got some c++ files you want to import into the project; but you can easily do this afterwards using “Add existing file”, instead of “Add new file” when you right-click the source folders in VS2010′s left hand pane.
Create a New Project
Create a new project using the “File->New -> Project” menu. This should bring up a dialogue box of different project types.
Select “Makefile Project” and give it the relevant name in the box below. The reason for it being a Makefile project, is to tell VS 2010 that you’re not wanting it to try and compile the source – you want it to send the source to Devkit Pro so it can compile it for the GBA for you.
You should now have a Makefile Project wizard infront of you. This lets you specify what actions it should take when you try to build the C++ source file. Click “next“.
In the boxes, put the following information (this should ring a bell with what you did in Notepad++):
Build command line: make run(when you try the VS “build” command, it will tell Devkit Pro to “make” it, then “run” the game)
Clean commands: clean (when you try the VS “clean” command, it will tell Devkit Pro to “clean” it)
Rebuild command line: make clean
Preprocessor definitions: ARM7 (tells DevkitPro that you’re developing for a ARM7 processor, so it knows how to handle your code before compiling it)
nclude search path: <the path to your devkitPro>\devkitPro\libgba\include (tells VS where to look for the GBAheaders, it makes your life a hell of a lot easier)
Click “next“
Make sure the box on this screen is ticked to re-use the settings from the Debugging page. This saves you re-entering identical settings.
Click “finish“
You should now have an empty project, with nothing more than a ReadMe.txt file (You can read it if you want, but it’s nothing important).
Adding Source Files
To get your project going quickly, you’ll want to add yourself some source files so that you can actually do stuff. For the purpose of this, it will just be a single .cpp file, but the method applies for everything after this too.
Right click the “Source Files” folder on the left hand side of Visual Studio 2010. Select “Add -> New Item”
For this, you’ll just want a standard .cpp file, which can be called whatever you want.
Important:, add “source/” to the end of the “Location” in order to separate the source files (and make it easier to write the MakeFile). This will put your new file in a folder named “source” within your project folder (it’s not particularly exiting, it’s just important).
It’s up to you what you write there. For now, I’d recommend just writing the main() function as an empty function and leaving it there.
Important: You must have a main() function somewhere – otherwise the Makefile will give an error later on.
(As a tip, if you add the #include, at the top, then press CTRL+SPACE, you’ll initiate VS2010 Intellisense – it should come up with a list of gba header files you might want to use. This can also be used during the rest of your code for selecting member functions of an object – it’s one of the reasons VS costs so much).
Creating the MakeFile
Now that you’ve got the basic source file in the right place, you can create the Makefile. This can be a rather tricky thing to do at first, as there’s a lot of information in it, and a lot to learn. However, luckily for you Devkit Pro comes with a wide selection of examples – including GBA Makefile examples.
To get the example GBA Makefile, go into where you installed Devkit Pro. Find the “examples” folder and then go into “GBA” (It’s almost as if you didn’t need to be told how to do this).
Go into the “template” folder, as this has the best – non specific MakeFile for you to use.
(You’ll also notice there is a template source file – if you’re looking for inspiration – these appear quite useful.)
Copy the MakeFile that is there and paste it into your VS project folder.
You should now have a MakeFile in the main project folder (the folder that also contains a /source/ folder).
Editing the MakeFile
You’ll want to now get that GBA Makefile into VS 2010 and edit it. This isn’t too difficult, but it can lead to a few errors here and there that are less than descriptive of what you’ve actually done wrong.
In Visual Studio, right click on the “Sources” folder and select “Add -> Existing Item“.
In the dialogue that pops up, select the Makefile from the project folder that you just pasted in. If a “what kind of file do you want” box appears – you clicked “New Item” by mistake.
You can now open this file within Visual Studio by double clicking it. It should be fairly hard to work out what’s going on, but I’ll explain the parts you need to edit. There’s also a lot of documentation of Makefile formats as they are a standard way of telling things how to build files. Generally Linux forums seem to be a good place to look if you’re looking for new things you can do with it – or just look at the Devkit Pro examples folder again.
Some of these changes are for my preference – not functionality, but it can’t hurt to explain them anyway:
Find the line starting with “TARGET :=” near the top of the file. Add “dist/” before the “$(shell basename $(CURDIR))_mb”. Also remove the “_mb” from the end.
The TARGET tells Devkit Pro where to put the files once they are finished.
The “dist/” tells it that it wants to be put in a folder called “dist” (for distribution); making it easy to find the files you can actually run/send to your friends.
You will need to make the “dist” folder if you use it. It should be in the same directory as the Makefile itself. The Makefile will not make the folder for you, it will cause an error if it doesn’t exist.
The “_mb” tells DevkitPro to make this a multiboot file. That’s not needed; you’re only running it on an emulator.
Find the line starting with “BUILD:=” the folder listed here is here non-finished files will be put while they’re made. You should make this folder manually before running as well – just to be safe. You can also change this to something else, although “build” is a standard place to put it.
The “SOURCES:=” line is already correct, because of where you put your file earlier. In future, you might have source spread over many different folders – you can add a list, separated by spaces here to let it know every folder that contains source-code.
You also don’t have any “GRAPHICS:=” so you can remove the “gfx” that’s been specified altogether.
Adding a “Run” statement
Technically the Makefile is working now. If you press F7 to build in Visual Studio 2010, you’ll get a little ouput at the bottom saying it’s worked (Although you won’t, because it will tell you it doesn’t know the run command you specified earlier. Really I just lied). However, this Makefile only creates the file, it doesn’t actually run the file after creation – meaning you’d have to open VBA.exe every time and then find and open your file. In order to make it run instantly, like the original Makefile does that Adam (the lecturer) handed out at the computer labs – you’ll need to tag this onto the end of your Makefile:
This tells Devkit Pro to open the VBA emulator (virtual boy advance), and then run the .gba file you’ve just created. The reason there is no “.exe” on “vba” is that it’s running a command (Yes it is possible to set this up to run the vba command from anywhere on your PC, instead of putting the whole path each time).
Make sure that the emuVBA folder is the correct folder in your Devkit pro setup. If you followed the previous guide it should be, but different versions of devkit and different guides point you to make folders in different places.
Success!
To run it, you’ll now just hit the F7 key (F5 will try to run the file using Visual Studio – it’s not what you want), and it should make your .gba file from the source code, and instantly start up VBA.exe with a copy of it.
There’s a lot you can customise with Visual Studio and a lot you can change in the Makefiles. I’m not going to run through it all; because I only really needed to get this working to the stage it is. However, the same method should apply to almost any other Makefile you create – whether it’s for the DevkitPro GBA, DS or Wii emulators; or even a different toolchain altogether.
I hope it’s been useful, and you’ll always be able to get in touch with me here by comments, or by these methods – whether you have any problems, or just want to show off something you’ve made:
From the fun time spent on the Computer and Graphics Architecture labs this week – using the GBA HAM development tool chain – I felt it would be beneficial to get it working on a home PC.
This is just a quick run through of how to setup your HAM development kit on your Home PC – as I’ve found through messing about with it. It’s not necessarily the best way, and I can’t guarantee it won’t cause problems later – but for those of you who’re like me and just wanted to get fired in; this gives you a quick approach to doing what we did in the labs.
Also, before I go into detail on this – my method is for a Windows PC; specifically, I use Windows 7 – if you run a Mac there are a nice big list of different steps you need to take, that you’ll find on the devkitPro website. (The windows version has a one-click installer of devkitPro; other OS’s have manual installation steps).
Downloads
In order to follow the steps; you’ll need to download the following:
As a note, my instructions will be using my paths to give you an idea of how things link together. If you have different paths (you will) then you’ll need to use some common sense about what to type where. My current install path is: C:\Users\Gordon\Documents\University\Computer_Graphics_Architecture\dev\devkitPro\ (where I will consider “\Computer_Graphics_Architecture\” as the “root” folder)
Installing DevkitPro
Once you’ve downloaded the appropriate files; you’ll want to get devkitPro setup. There is little different about this setup, than any other program – except that it has a rather useless default path.
Run the installer you downloaded from SourceForge
Select all features (around 300MB)
Set an install path that keeps your files together (For example, my install leads into /#myunifolders#/dev/devkitPro/ which means I can get away with minimal edits to the original batch files. It will also not install into any folders with invalid characters (spaces etc))
Sit back and allow it to install (it does a minimal amount of downloading; so the install time will rely on your network)
Setting up the file paths
Now that devkitPro is installed properly, you can go about moving the files into the right directories, and editing them.
Move the RunMake batch files into the “root” directory for your GBA development files.
Open the RunMake.bat file in your favourite editor (read:you will use Notepad++ whether you like it or not).
Remove lines 14 to 19 (the “if EXIST” down to before ” : ok”). On a home PC, devkit is installed locally, you don’t need the LabSetup file; this line just checks that file exists (i.e. that g:\ had been mapped).
Edit line 18 (“set ROOTDEV= g:\dev\devkitPro”) to be your /devkitPro/ file path (such as C:\Users\Gordon\Documents\University\Computer_Graphics_Architecture\dev\devkitPro\)
Create a new folder /emuVBA/ in the /devkitPro/ folder; move and rename your visual boy emulator there (rename it vba.exe) (Alternatively, you can change the PATH variables in the RunMake file, but this is a lot more simple to do, and a lot less error-prone).
NB: If you downloaded Visual Boy Advance from the link above – you need to extract the .exe from the .zip file. (I do hope nobody needed me to say that)
Creating the projects
You’ve now got it all setup and in a running state. You just need to make a project and run it now. Which shouldn’t be difficult:
Create a new projects folder somewhere that you’ll remember (such as /dev/projects/ but maybe that’s just too obvious and logical).
Download the projects files from the University website; especially the MakeFile; and add them into the new projects directory.
Open your main.c file from the projects directory; as in the lab – goto the “Run” menu, and then “Run”.
Edit this line to match your “root” directory: \the_path\to_your\root\goes_here\RunMake “$(CURRENT_DIRECTORY)” run
Throw the line into the run command as you did in the labs; it should work fine from there – opening vba.exe by itself.
If you find it runs, but has an error about running vba; it means you’ve messed something up in the PATHS, either fix the error – or open vba.exe manually and File>Open>[find your main.gba file]
I hope you’ve found this useful, as I say – it’s a bit of a botch, as we’re effectively using the existing batch files with some quick edits to get this working. I’m sure it won’t take long for somebody to make a quick post of how to do it all properly – but in the meantime, this is a way you can get some development done at home; without much hastle. I’d also remind anybody to check the module resources regularly, as Adam updates the files there each lab. I’ve also now written a new guide on getting DevkitPro working in Visual Studio 2010.
Thanks for reading,
Feel free to email me at gordon.mckendrick@gmail.com if you have any questions, or catch me on Facebook.
As always, passing this article on to anybody else wanting to do this, is appreciated.
Useful Websites
While getting this to work, there are a few websites that you might find handy. They have some decent information and are generally just good for finding solutions to errors you have in your code; or ideas:
coranac TONC: http://www.coranac.com/tonc/text/toc.htm (A good website of resources for GBA development, including how to set up Devkit Pro, in case this confused you)
As some of you may know, my first real route into programming was by making a “plugin” for the game Minecraft (a small server-side mod, that can be easily swapped in and out using the “Bukkit” server mod platform).
What was LDQuest?
The plugin was LDQuest – a solution to the lack of complex questing plugins that existed at the time. It aimed to fill the gap in the plugins; which had been left by other quest plugins who were more simplistic in their aims – with linear task systems (of which the most complex allowed a few linear tasks in a row). LDQuest did this through it’s Requirements system (a giant “can you do this” system of logic) – which allowed you to have branching of quests in various ways, including being able to limit choices based on previous actions, including those in previous quests.
It was also designed to be relatively easy to use; while accepting that it would never meet the simplicity of the other plugins; due to what could be done within it. This was achieved to some extent, through a YAML file system, that allowed people to quick write their own quest files by hand. This would then allow people to easily add or remove quests by dropping them into the server folder.
However, what resulted was a working, but hellish piece of bad code that was confusing to maintain, impossible to extend and left users in a real confusion as to how to make the quests they wanted. The reasons for this were many,but mainly stemmed from the basic issue of not enough planning. The initial design was not thought through; both in terms of features that needed implemented and in terms of the implementation of these features. It meant that hile things worked and most things worked well – there were features left impossible to add in, and features that should have worked a lot better.
Moving On
While it might have been possible to keep working on LDQuest, after taking a break from it – there was clearly one smart option – to rewrite it. Obviously, this comes with it’s own issues – the problems that existed originally, need to be solved before re-writing, otherwise it’ll end up in the same mess. Beyond that, there’s a real problem with trying to get everything done that wasn’t done originally – a temptation that I’m now trying to battle by designing from the bottom up. Only features that I see as necessary and as fulfilling a user’s needs (not wants) are being added. For example; there is not reason to implement 100 types of rewards; where I can implement an API which allows other plugins to handle these.
So, with that in mind, I’m not working my way through various methods of design; from MindMaps (as encouraged by my University) and simply sketches in a book. The hope is that I’ll be able to plan this out much better than before – having a good idea of what I’m programming before a single line gets written. That way, there should also be less time spent looking aimlessly at the screen and more time productively creating the plugin I’d hoped to originally.
I’ll be keeping people up to date as best I can, with code snippets and anything I find interesting. If you want to contact me, I do read the comments – so feel free just to post and I’ll do my best to respond. Alternatively, look for me on the Lodainn Minecraft server: 91.204.209.130, or message me on steam: wmckendr