Messages

Sure you can add or modify it for whatever you want. I'd appreciate it if you left my name on it and certainly feel free to update the Title screen with your name (or spacefractal) crediting you for adding GameInput API support.

However, please grab the source from my website first because I fixed another tiny bug right after I submitted it to the Showcase.

I think this should be the last little issue. When I overhauled that Main method earlier today I should have play-tested it more but was in a rush to wrap it up.

Anyway, the latest source is on the NOTE: I UPDATED THIS POST TO REMOVE THE LINK BECAUSE I HAVEN'T HAD MY OLD WEBSITE FOR SEVERAL YEARS NOW.

But yeah go ahead. In fact, anyone can feel free to update it to add a high score screen or whatever anyone wants to add. It's basically just an example game project. Kind of a template or starter kit for making a side scrolling arcade game. I needed something for my experiment and thought it might be helpful for new people interested in learning GLBasic.

Thanks! 

If you dont mind; fix the error, and put it in our showroom too since its open source?
Thatll give you a second copy on the web for backup

Did you use this game for any competitions? How did that go for ya?

Okay, it is done: http://www.glbasic.com/showroom.php?lang=en&game=marsexplorer

I also went ahead and updated the Title screen real quick to include the controls.

I just spent 2 minutes making a couple tiny updates to the StatusBarControl and PlayfieldManager classes.

Geesh. I thought hey why not finally play this game and see how it is. And noticed when I did my code clean up I introduced a bug with the rocks not resetting!

And I noticed a compiler warning about creating a public variable because I left a "self." off the front a variable name.

Sorry about that.

If you pull the source down again these issues will be resolved. Also earlier I updated the download page to have the controls for the game.

Decelerate (brake) — Left Arrow or A
Accelerate —————- Right Arrow or D
Jump ———————— Up Arrow, X or Right Shift
Fire ————————— C, Space or Enter (Return)
Pause/Resume ——— P

Alright, now I am going to blast some aliens, jump over holes and rocks and maybe blast a few of them too. lol

Then probably go play some retro games and forget about programming for a bit.

[Windows executable version available for download]

Hey there GLBasic Community!

Some of you know I have been working on NOTE: I UPDATED THIS POST TO REMOVE THE LINK BECAUSE I HAVEN'T HAD MY OLD WEBSITE FOR SEVERAL YEARS NOW.

Mars Explorer is inspired by the old Moon Patrol. This game has only 2 stages in it because it was created just to (a) test GLBasic for 2D game development and (b) create a simple game project I can use to test Unity, Monkey X and HaxeFlixel.

There is a Windows executable version available for download.

Also, the full project source code is available for download.

If you are interested you can get them from my NOTE: I UPDATED THIS POST TO REMOVE THE LINK BECAUSE I HAVEN'T HAD MY OLD WEBSITE FOR SEVERAL YEARS NOW.

Hope someone enjoys this little game or at least finds the code useful!

Now, I am going to take a break for a day or two and start on the MX, HF and U implementations.

[RetroVGS]

Amos was a nice language for Amiga computers. Im have done one game with it, and that game got turned into Genius Greedy Mouse.

About dev speed, Im have not bother with that, but more im have do more thinking how much a game might take to create. CatchOut was property that game, that took shortest time. Greedy Mouse and Karma Miwa took quite long time. Im property sure im will not done a Greedy Mouse and Karma Miwa length again, but want to do smaller games in this language (like CatchOut and Spot Race).

PS. The final game seens to been very great and do the job. The only issue is the music can been annoying after a while. But its a prototype :-).

AMOS was very good. It made it easy to access the capabilities of the Amiga and was the first programming language I used on the Amiga. Then I switched to Blitz Basic for its increased speed and a couple other things. Then switched to C & Gamesmith and dabbled in 68000 Assembler.

Have you heard about the new RetroVGS system? I hope this one finally makes it. It would be awesome if all of the retro gamers & developers supported one console such as this. Currently, I feel the market is way too fragmented across the GPX2, Caanoo, UzeBox, GCW-Zero, Dingoo, WIZ, Zodiac and others. Plus the desktop retro games. Mobile retro games. Even the latest gen consoles have some retro style games. Anyway, I hope it does well.

Greedy Mouse looks very cool. The clay-based graphics reminds me of the BB game Platypus. I imagine your Greedy Mouse did take a lot of effort and time. Game dev in general just takes a lot of time which is a good reason for people to team up on such projects, find the fastest thing to use for developing them and build up a library of code, dev tools and perhaps even assets that can be reused.

Since you are approaching those packages on a code level, I suppose they all benefit from recycling code and functions for future games, and thus save more time, is that the case?
Within those packages, did you ever experienced newer versions that rendered those code/functions useless by changing/updating its core functions?

I see you did some AMOS back in the days, did you use to visit amos factory?

I try to stick to the same basic structure regardless of what I am developing in so I can rely on past experience. At the same time I am always dabbling trying to improve the way I approach game development.

Basically, I use the same patterns in everything and try to improve on them each time. Mainly just to get a cleaner "better" structure that is easier to maintain and build on.

So, in that sense sure it saves time because no matter what I am developing in I just take a look at what I have to work with and how I can apply it to my development style. And like with the GLBasic version of Mars Explorer much of that should easily map over to Unity, Monkey X and HaxeFlixel.

What determines the increased or decreased speed as far as programming time basically comes down to the kind of support the game-oriented API offers. I try to minimize those requirements greatly by basically only using the fundamentals: loading assets, drawing images, playing sounds, managing frame-rate those kind of things. I don't use any built-in stuff for physics and so forth. I just don't see the need for such things anyway and don't want to get "locked" into any one game dev environment by relying on such things. Because we never know how long they will be around such as AMOS and XNA for example. This also makes it so updates to those APIs almost never affect me because I am not using any of that higher level stuff anyway.

I heard of AMOS Factory many times but never knew what it actually was. I did a search for AMOS one day a few months ago (just out of curiosity if there were any sites around covering it still) and found a site mentioning AMOS Factory. There was actually a new cross platform version of AMOS being developed a few years ago that I found on a forum there: http://www.ultimateamiga.co.uk/index.php/topic,9499.msg44951.html

[For a programmer, what is the fastest "kit" available to make 2D games? Let's find out!]

Just like Ian said, but on an extra note, I see that you are comparing for "fast" and "easy" within your own knowledge. Wouldn´t that be a very subjective thing for others to understand? It does help that you described your background and prior experience though.

It definitely is primarily just what ends up best for me. However, it should also apply to other programmer code-oriented people as well. My signature on the Unity forums says this: For a programmer, what is the fastest "kit" available to make 2D games? Let's find out! and that leads to my main page doing the comparison and includes my background and so forth.

I might not be a good example to quote but I have been doing games from the time you could only draw with letters so I´m not impressed with super gfx when the game itself is crap. The art of making computer games (hypermedia) is strictly in the hands of the coder, he is the artist here, the rest just plugs along.edit: and yeah, being on ok artist myself, I know gfx take a monstrous amount of time...the reason my next couple games will be low res and B/W.

I am the same way. Been programming a long time and playing games a long time. While I can ooh and ahh over superb graphics and definitely appreciate them when it comes to games I do not need that stuff to enjoy the game. In fact, I'd say that when people play games they only notice the graphics in the very beginning. When playing a game your mind is in that feedback loop mode where you are reacting to the messages the game sends to you and watching how the game reacts to your actions. Graphics and sounds are simple the means the game uses to communicate with the player. At its core that is it.

A very good blog, but it really would be unfair to base any language on the speed it takes to write the same game in. As you said, you did a lot of the hard work while using GLB that will probably save a lot time in other languages. I do hope your comparison between each language willl be based on their positive and negative aspects rather than the time used to create something.

It'll be interesting to see your other blogs - do keep us posted.

Yeah I definitely realize I already worked out the game framework, systems and so forth, design and even art assets in the GLBasic version. I intentionally noted that on the blog as a reason I expect the other versions will not take as long.

On the dev speed thing... that is the whole reason for me doing the experiment. I can do 2D games in Unity yet I've had a nagging question in the back of my mind for a long time now wondering if Unity is making dev harder and slower or easier and quicker.

While prototyping my latest Unity game project to make a "better" shmup...

...I finally just stopped work on it deciding to see what alternatives are available and then test each one.

For me personally all I care about is development speed. Their positive aspects will likely have a positive effect on dev speed and their negative aspects will likely have a negative aspect on dev speed.

Development speed is so important to me because the faster I can develop the more (and better still the more ambitious larger scope) games I can develop. I only do this stuff very part-time generally averaging about 90 minutes per night. If it takes 3 hours less time in one framework than it does to make this simple 2-stage game than it does in the others well... that is 2 days of additional time I have to spend. Whether I spend it polishing the game or starting a new one. It is all about time. If I had an extra 8 hours per day that would help too.

I suppose people might think if I only care about development speed... getting things done... why not just use GameMaker or something like PlayMaker? Because that kind of stuff just doesn't click with me. I am a programmer. I am used to just designing and coding everything. The GUI stuff is what I am trying to get away from. All of my Unity work I spend as little time in the Editor as possible and just code everything up. I use that approach no matter what I am using. Unity however just has certain requirements to go into the Editor for certain things such as sprite slicing, creating prefabs and so forth.

...and then, a super feature just creep in mind and it has to be implemented, and another...
Looking nice, I specially enjoyed the particles on the enemy´s explosions.

Ha ha. Isn't that the truth. These things can drag on forever because there is always something else to add or an existing something that could be improved! Just have to say enough is enough and call it done at some point.

And...

NOTE: I UPDATED THIS POST TO REMOVE THE LINK BECAUSE I HAVEN'T HAD MY OLD WEBSITE FOR SEVERAL YEARS NOW.

Of course, it only has two stages and that was my goal. At this point it'd be easy to increase it to 5 to 6 levels and even add in a new enemy or two. But I am not going to do that.

Before this I spent 3 hours in GLBasic developing the TiledMapLoader and TileMapRenderer.
Then I spent 25 hours in GLBasic programming this game and 3 hours on graphics and an hour designing the stages.
I don't consider the TileMap stuff as really part of it because that is something that was just needed and is needed in about all 2D games.
That kind of thing should just "be there" I think which is why I threw my source out on the forum.

Anyway, man it is good to have it done!

I will put a download up for the game sometime within the next few days.

Still going... 20 hours now... didn't complete it this past weekend but I am getting closer all the time.

I am sure by the time this weekend comes and goes I will have it wrapped up.

Anyway, latest video is at the bottom of the NOTE: I UPDATED THIS POST TO REMOVE THE LINK BECAUSE I HAVEN'T HAD MY OLD WEBSITE FOR SEVERAL YEARS NOW.

48 hour Compo goes til Sunday night. 72 hour Jam goes til Monday night.

I passed on it again. Seem to always have a project I am already working on. This time it is the GLBasic implementation of the Mars Explorer game which is just one piece of the overall much larger experiment comparing multiple frameworks.

I guess what I will do is be sure to not have any project going on the next time LD comes around. Or else just do some other jams like the 1 Hour Game Jam.

Or maybe just do experiments on my blog because I basically approach all of my game development like I am in a game jam anyway. Always trying to get things done asap.

What are the prices on that pro version?

The best way to go is the subscription. $75 per month gets you everything except ability to deploy to mobile. So $900 per year.

iPhone is $75 per month. Android is $75 per month. I have no idea why they charge for each of these two mobile platforms (other mobile is included in the base $75 per month).

If you wanted to be able to target everything the cost is $225 per month. $2,700 per year.

Honestly, I never paid any attention to the prices because they really do not even matter to me. If I was working on building a games business and reached $100k per year income from the games then spending $900 per year in subscription fees (I have no interest in developing for Android or iPhone) would be a very reasonable and tax deductible business expense. I think their prices are easier than Unreal which also charge you a % of royalties on top of the flat fee amount.

off topic apart, are you going to push the moon lander into the ludum dare?

Oh no. That would be completely against the rules and spirit of the LD challenge. At this point I already have 14.5 hours into the GLBasic development of the Mars Explorer project. About 18 hours of total development time with the tile map and graphics work. That would be a huge unfair advantage in a 48-hour event.

I am actually debating participating in it though. Always wanted to and just never do because I generally never spend more than 2 to 3 hours working on game development in any one day. Especially on a weekend when I am free from work and can get out of the house and do other stuff.

It would be fun though! At the same time I am thinking I can probably wrap up this Mars Explorer GLBasic version this weekend if I stay focused on it.

Unity has free versions and paid versions.
The Unity 4.x versions have the free versions with missing features.
Starting with Unity 5.0 Personal Edition (the free one) includes all of the stuff the paid version includes.
The paid version now is simply for added services not added features to the Unity game engine.

The whole industry is kind of going that way. Unreal is also free. As are many of the others. Godot. And so forth.

With Unity you do still need to upgrade to the Pro version as soon as you are making $100k per year from your game projects.
I think that is reasonable though and something most people won't ever need to worry about.

For 3D Unity is probably the best way to go.

[LD33]

So yeah... LD33 starts tomorrow. Might be a good way for this community to increase awareness of GLBasic.

Anyone plan on participating?

@Slydog

That is about exactly the same approach I use In Unity. The only GOs in the scene are managers. Everything else is a prefab. The main issue I have with it is the workflows for 2D assets. I greatly dislike messing around in the Editor loading and slicing spritesheets (with the bugged sprite editor) and then assigning the images to prefabs (or animations) because it is a very tedious workflow.I know you  can load from the Resources folder and have not tried it that way. Mainly because I feel like if I am going to continually do things in the non-Unity standard why then why am I even using it? lol

I think if they focused more on providing a solid API to work with the assets that would do a lot to help programmer-oriented people like me. Generally in any other 2D dev framework I have used there are commands available to easily load not only a single image but also a file containing multiple images and easily slice the images out during the load. If I had made that 2D Collider auto-gen system I'd have linked the colliders to the actual images or sprites as Unity calls them. Then as the SpriteRenderer displays different images the colliders would automatically change to reference the appropriate collider associated with the current image.

It is these kind of fundamental aspects of working with 2D that Unity seems to be lacking. The stuff you'd expect would just be there and not even be anything to consider. Having the colliders and collision system is good and at the same time it is flawed in its current implementation because they are associated with a game object not the actual images themselves. Of course, each person has their own preferred way. I'm just saying their current implementation is not very logical in my opinion.